Quality over quantity matters more than hitting a specific number. That said, most successful candidates solve 150-300 problems with roughly 70% Medium and 30% Easy difficulty. After 100 problems, focus on areas where you're weak. Track your progress—if you're consistently missing tree problems, practice tree-specific patterns until you see them easily.

Both. On-site interviews often use whiteboards, so practice there to build muscle memory for writing code without auto-complete. However, running and testing code matters too—use computers for problems where debugging and verification are crucial. Most remote and on-site formats use CoderPad or a similar sandbox where you can run code. Practice both formats.

• Do not panic—it is normal to struggle. Take 30 seconds to breathe and reassess.
• State what you know: "I have tried brute force but that is O(n^2). Let me think about optimization."
• Ask for a hint: "Could you help me identify what pattern this resembles?"
• Work through examples manually to find the pattern.
• If you are truly stuck after 15+ minutes, acknowledge it and discuss potential approaches anyway.

• Communication: explaining your thought process out loud is as important as the solution itself.
• Time management: knowing when to move on from a stuck approach.
• Handling interruptions: staying calm when the interviewer asks questions mid-solution.
• Clarifying questions: before jumping to code, confirm inputs, outputs, and constraints.
• Testing: running through test cases before declaring done.

• Minimum: 3-5 mock interviews to build familiarity with the format.
• Recommended: 8-10 (spread over 2-3 weeks) for comfortable mastery.
• Quality over quantity—review each session and track improvement.
• If you can comfortably explain your approach and code under time pressure, you are ready.

• Within 24 hours: review the recording while it is fresh—note where you hesitated, went silent, or lost the thread.
• Identify patterns: did you consistently forget to state complexity? Rush through test cases? Miss clarifying questions?
• Rate each phase: score problem-solving (1-5), coding (1-5), communication (1-5), and testing (1-5).
• Fix one thing: pick the single most impactful weakness and drill it in the next practice session.
• Written reflection: jot down 3 things to do differently—re-reading this before each session keeps habits on track.

• Be honest: tell your partner if you are weak at dynamic programming or system design—they can tailor the problem.
• But simulate real conditions: do not ask for hints during the session; note what you wish you could ask and discuss after.
• Warm-up vs. focus sessions: use warm-ups to practice weak areas openly, then do a blind mock to gauge overall readiness.
• Mix it up: alternate between telling your partner your weak spot and doing a fully blind session.

• Dedicated sessions: block 30 minutes separate from coding practice for behavioral prep—use the STAR format (Situation, Task, Action, Result).
• Pair with coding: end every mock with 1 behavioral question—5 minutes for the question, 5 minutes for feedback.
• Reuse answers: develop 5-7 core stories (leadership, conflict, failure, success) that you can adapt to different prompts.
• Record and replay: audio-only works fine for behavioral—listen back to check you are not rambling or underselling your contributions.
• Company research: align behavioral stories with company values—FAANG questions differ from startup questions.

• Time-boxed practice: give yourself exactly 40 minutes—5 to clarify requirements, 15 for high-level design, 15 for deep dive, 5 for trade-offs.
• Partner plays interviewer: have your mock interviewer push back, ask follow-ups, and introduce constraints to see how you adapt.
• No looking things up: real system design interviews are open-book but you will not have internet—practice estimating numbers from memory.
• Critique your own design: after the session, list 3 things you would do differently. Weaknesses in trade-off discussion are the most common feedback.

• Exposure therapy: the cure for performance anxiety is repeated exposure—do 20+ mocks until the observation feels normal.
• Start with low-stakes observers: code in front of friends first, then peers, then experienced engineers—gradually raise the stakes.
• Reframe the pressure: an interviewer watching you is not judging you—they are looking for signals. Give them good signals by narrating your thinking.
• Physical grounding: if shaking is adrenaline-based, pause, take one deep breath, and write a comment or two before diving back into code.
• It is common: almost every candidate reports some nervousness. Interviewers are trained to look past it.

• Cross-validate: if three different mock interviewers give you the same note, believe it—that is a real pattern.
• Distinguish taste from skill: feedback like "your variable names could be cleaner" is opinion; "you did not test edge cases" is a skill gap.
• Track over time: if you fix a noted weakness and the next 3 mocks show improvement, the feedback was accurate.
• Expert over peer: peer feedback on algorithms is hit-or-miss; an experienced engineer giving specific technical feedback is worth 10 peer sessions.
• Be wary of vague praise: "You did great!" does not help—push for specifics and ask what one thing you should change.

• 45-minute format: skip lengthy introductions—get to the problem within 2 minutes. Plan for one primary problem with a possible follow-up. No time for extensive discussion of trade-offs at the end.
• 60-minute format: often includes two problems or one problem with a deep follow-up. Budget 5 minutes for introductions and 5-10 for behavioral. More room to showcase system design thinking or multiple approaches.
• Practice both: do mock sessions in both formats so you are adaptable. Some companies (like Google) use 45 minutes, others (like Meta) use 60.
• Signal awareness: in longer formats, interviewers expect you to drive the conversation more—do not just wait for questions.

• Narrate as you type: start from day one of practice—every line gets a one-sentence explanation, like "Here I am initializing the hashmap to store frequencies."
• The elevator pitch test: after finishing, try to explain what the code does in exactly three sentences. If you cannot, your understanding is shallow.
• Trace a specific input: pick a concrete example and walk through the code step-by-step. Most interview explanations are just a trace on a small input.
• Rubber duck debugging: explain the problem to an inanimate object. If you get stuck explaining a line, that is the line you do not truly understand.
• Time it: aim to explain a clean 30-line solution in under 2 minutes. Practice efficiency of explanation, not just correctness.

• Time-box strictly: treat a take-home like an exam—set a fixed window (e.g., 3 hours) and work within it, not until it is "perfect."
• Write production-quality code: take-home gives you time to refactor, add comments, and handle edge cases. Clean code with tests beats messy optimized code.
• Include a README: explain your approach, trade-offs considered, and how to run the code. Interviewers read this before the code.
• Do not over-engineer: if the assignment says "read a file and print results," building a full CLI with error handling and logging is overkill. Match the scope.
• Practice scope control: the hardest part of take-homes is knowing when to stop. Set a hard time limit before you start.

• Online communities: subreddits like r/cscareerquestions and r/Interviewing have daily partner-up threads. Discord servers for specific companies also have matching channels.
• University groups: if you are a student, your CS department Slack or Discord likely has interview prep channels.
• Schedule recurring sessions: find 1-2 partners and commit to a weekly 90-minute slot. Consistency beats ad-hoc cramming.
• Structured rotation: each session, one person codes while one interviews, then switch. Keep a shared doc to track who needs practice in which area.
• Accountability partners: pair with someone at your same skill level but different strengths. One of you will be better at DP, the other at graphs.

• Be honest with your practice partner: they cannot give useful feedback if they do not know you are weak at, say, tree traversal—they will pick an array problem instead.
• Never mention weaknesses to an actual interviewer: "I am not great at dynamic programming" is not something to volunteer. Focus on what you can do.
• Use weaknesses strategically: in a mock, frame it as "I am working on this." Shows self-awareness and growth mindset without underselling yourself.
• Watch for overcompensation: if you claim to be weak at something, your partner will go easy on you. Do not use this as a crutch to avoid hard problems.

• Internalize the clock: after dozens of timed sessions, you will develop an internal sense of elapsed time. Until then, use a visible timer.
• Phase budgets: 5 min clarifying, 10 min approach, 20 min coding, 10 min testing and discussion. Move to the next phase even if the current one is not perfect.
• The 15-minute rule: if you are 15 minutes in and do not have a working approach, switch strategies. Brute force is better than nothing.
• Practice panic recovery: in mocks, deliberately get stuck at the 20-minute mark and practice pivoting to a simpler solution. This builds the muscle for real interviews.
• End regardless: always reserve 2 minutes before the hour to state your complexity analysis, even if the code is not fully polished.

• The confidence test: you feel ready. You can walk through your approach out loud without rehearsing it. You do not feel the need to explain away your weaknesses.
• Consistency across topics: you are not just good at arrays—you are good across the categories. If you have solved 10 sliding window problems but never tried trees, you are not ready.
• Feedback trend: your last 3 mock interviews showed improvement and no new major red flags. One isolated critical note is fine; three of the same note means keep practicing.
• Comfort with pressure: nerves are normal and do not mean you are unprepared. But if you are still going completely silent after 5+ mocks, do 3 more.
• The opportunity test: sometimes you schedule a real interview not when you are perfectly ready, but when you have an opportunity. Real interviews are also practice. Do not over-prepare and miss the window.

• Silent coding: going quiet for minutes while thinking is the most common and most damaging habit. Interviewers cannot evaluate thought process they cannot hear.
• Skipping the approach explanation: jumping straight to code without outlining the approach first signals disorganization. Always state the problem type, approach, and complexity before coding.
• Not testing their own code: writing code and calling it done without running at least one example manually. This is the single most reliable sign of rushed work.
• Overselling the brute force: diving into coding before mentioning there might be a better approach. Say "I can do a brute force solution in O(n^2), let me think if I can improve it."
• Forgetting the interviewer exists: treating the mock like a solo LeetCode session instead of a conversation. Ask clarifying questions, check in, and respond to interviewer cues.

• Do not pretend: if you recognize the problem immediately, it is okay to say you have seen a similar problem before. Interviewers respect honesty more than awkward over-performance.
• Still solve it properly: walk through the approach as if it is the first time. Explain why you are choosing this approach. Do not just dump the memorized answer.
• Ask for the variant: "I know the standard version—does this one have different constraints or follow-up questions?" This shows you are thinking about generalization.
• Use it as a speed benchmark: if you solve it in 15 minutes, that is useful data about your pattern recognition speed.
• Prepare a bank of known problems: if you have a running list of problems you have solved, practice explaining them without looking at your notes. The communication skill is different from problem-solving.