Overview
Mock interviews simulate the real conditions of a technical interview: a stranger, a timer, an unfamiliar problem, and the need to think out loud. Solving problems alone builds knowledge; mocks build performance under observation, which is a separate skill.
Effective practice follows a loop: do a timed mock, get specific feedback on a rubric (problem solving, coding, communication, testing), review the problem afterward, and turn weaknesses into targeted drills. Tracking results over time, as your repo's progress sheet does, shows which patterns still need work.
Actors know their lines long before opening night, yet they still rehearse in costume, on stage, with lights and an audience. The rehearsal exposes problems that never appear when reading the script alone.
When to use it
- Two to six weeks before interviews, once core patterns are familiar.
- When you solve problems alone but struggle in real interviews.
- To practice communication, pacing, and handling hints.
- After a failed interview, to rehearse the weak area.
Problem patterns it solves
Recognize it when: one problem per major pattern to find gaps.
- Arrays / hashing
- Two pointers / sliding window
- Trees / graphs
- DP
- Backtracking
- Heaps / intervals
Recognize it when: easy problems solved while explaining every decision.
- 1. Two Sum
- 20. Valid Parentheses
- 104. Maximum Depth of Binary Tree
Recognize it when: practice getting partial credit and using hints.
- 42. Trapping Rain Water
- 23. Merge k Sorted Lists
- 76. Minimum Window Substring
Where it is used in real software
Companies score candidates on consistent rubrics: problem solving, coding quality, communication, and verification. Mocks let you practice against the same criteria.
Engineers rehearse design reviews with peers to anticipate questions, the same principle as mock interviews.
Research on expertise shows improvement comes from focused practice on weaknesses with immediate feedback, not repetition of what you already do well.
Key terms
- Rubric
- The criteria interviewers score: problem solving, coding, communication, testing.
- Thinking out loud
- Narrating your reasoning so the interviewer can follow and help.
- Hint handling
- Recognizing and building on the interviewer's nudges.
- Error log
- A record of mistakes and patterns missed, reviewed regularly.
The practice loop
- 1Schedule
Two to three mocks per week with peers or platforms; alternate interviewer and candidate roles.
- 2Simulate realistically
45 minutes, a new problem, camera on, a plain editor, talking the whole time.
- 3Score with a rubric
Rate clarification, approach, coding, testing, and communication from 1 to 4 each.
- 4Review the same day
Re-solve the problem cleanly, study the optimal solution, and note the insight you missed.
- 5Drill the weakest area
If DP scored low, do five DP problems before the next mock.
Sample mock scorecard
Problem: 739. Daily Temperatures, 45 minutes
| Area | Score (1-4) | Evidence | Next action |
|---|---|---|---|
| Clarification | 3 | Asked about size and output; missed empty input | Use the edge-case checklist |
| Approach | 2 | Found O(n^2), needed a hint for the monotonic stack | Drill 5 monotonic stack problems |
| Coding | 4 | Clean, correct on first run | Keep templates fresh |
| Testing | 2 | Only ran the given example | Always trace 3 edge cases |
| Communication | 3 | Clear, but long silences while coding | Narrate intent before each block |
NOWArea: Clarification | Score (1-4): 3 | Evidence: Asked about size and output; missed empty input | Next action: Use the edge-case checklist
Specific scores and next actions turn a vague feeling ('it went badly') into a concrete plan. Over several weeks, the lowest row should move up.
Implementation
// A tiny progress tracker: log each practice session and find weak patternsconst sessions = [ { date: "2026-09-01", pattern: "Sliding window", solvedAlone: true, minutes: 18 }, { date: "2026-09-02", pattern: "Dynamic programming", solvedAlone: false, minutes: 40 }, { date: "2026-09-03", pattern: "Monotonic stack", solvedAlone: false, minutes: 35 }, { date: "2026-09-05", pattern: "Dynamic programming", solvedAlone: true, minutes: 30 },]; function weakestPatterns(log) { const stats = new Map(); for (const s of log) { const entry = stats.get(s.pattern) ?? { attempts: 0, solved: 0, minutes: 0 }; entry.attempts++; entry.solved += s.solvedAlone ? 1 : 0; entry.minutes += s.minutes; stats.set(s.pattern, entry); } return [...stats.entries()] .map(([pattern, e]) => ({ pattern, solveRate: e.solved / e.attempts, avgMinutes: e.minutes / e.attempts })) .sort((a, b) => a.solveRate - b.solveRate || b.avgMinutes - a.avgMinutes);} console.table(weakestPatterns(sessions)); // practice the top rows nextComplexity and performance
In the final month before interviews.
Plus 15 min feedback.
Re-solve and log the insight.
Trade-offs
Peer mocks are free and let you practice both roles; paid or experienced interviewers give more calibrated feedback.
Solving 500 problems without review builds less skill than 150 problems reviewed carefully with an error log.
Variants and related techniques
Practice STAR-format stories about conflict, failure, and impact alongside coding.
Same loop with design rubrics: requirements, high-level design, deep dives, trade-offs.
Record yourself solving and explaining, then watch it back to spot silences and unclear explanations.
Common mistakes
- Only practicing problems you already know.
Fix: Use unseen problems; familiarity hides real weaknesses.
- No feedback or vague feedback.
Fix: Use a written rubric and ask for one specific thing to improve.
- Skipping the review.
Fix: The review is where learning happens; always re-solve the problem cleanly afterward.
Interview questions
How should you use hints in an interview?
Acknowledge the hint, restate how it changes your approach, and continue. Interviewers expect to give hints; building on them well is a positive signal.
What do interviewers evaluate besides the final code?
How you clarify, the reasoning from brute force to optimal, code quality, testing, and communication. A correct answer with no explanation scores lower than a well-reasoned one.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| One mock per pattern over three weeks | Medium | Coverage and gaps. |
| Swap roles with a peer | Easy | Learn what interviewers notice. |
| Record and review a solo session | Easy | Communication habits. |
| Keep an error log for 30 problems | Medium | Turn mistakes into drills. |