The mock interview process

The R-squared between how well you think you did in a technical interview and how well you actually did is 0.18. Imposter syndrome is roughly twice as common as overconfidence. That single statistic, drawn from interviewing.io's corpus of more than 100,000 logged sessions, is the case for mock interviews and the case against trusting your own self-assessment of one. You cannot grade yourself. You need a third party who has the data to be calibrated.

The same corpus carries a second number that takes the romance out of the first. Even strong candidates with a mean score of about 3.0 fail individual interviews around 22% of the time, and only about 25% of interviewees are statistically consistent across multiple sessions.^[1] One bad mock is no more diagnostic than one bad real interview. One great mock is no more reassuring. Mocks earn their value across a series, with a structured debrief, and only after the underlying patterns are reliable. This chapter is the operating manual for that series.

When am I ready for my first mock?#

Sooner than you think for a peer mock; later than you think for a paid expert.

The gating signal is solo identification rate. If you can read an unseen LeetCode medium and name the dominant pattern (variable window, two-pointer, BFS, monotonic stack, basic DP) in five minutes, on roughly two-thirds of attempts, you're ready.^[2] Below that, mocks return mostly noise: the session converts to the interviewer re-explaining mechanics that belong in solo study, and the candidate walks away with feedback they could have predicted.

In wall-clock terms, that's usually after 50 distinct LeetCode problems across at least five pattern families, which lands in week 8 or 9 of a 12-week ramp. Educative's 12-week plan starts mocks at week 9 for the same reason.^[3] Yangshun Tay's Tech Interview Handbook is more aggressive: book the first interviewing.io session as soon as you can solve one medium under a timer, because the point of the first mock is to discover what you sound like talking while coding, which solo practice cannot teach.^[4] Both views agree on the gating principle. Disagree on the threshold by a week or two.

The mirror failure is mocking too late. A candidate who solves 200 LeetCode problems alone, books a first mock the week before the loop, scores 2 of 4 on communication, and panics has structurally undertrained one of the three things the rubric grades.^[5] Mocks are training, not a final exam. Schedule one before you feel ready.

Which mock service should I use?#

There are three classes of mock partner, each doing a different job.

Pramp is the standard peer-platform entry point. It pairs strangers, swaps roles at the 30-minute mark, and bakes the interviewer-side experience into every session. The platform's own data point is that "you learn as much from interviewing others as you do from being interviewed,"^[6:1] which is the mechanism: playing interviewer forces you to internalize the rubric, and once internalized the rubric runs in your head during your own loops. Free is the right price for a session that compounds in both directions.

interviewing.io is the paid-expert standard. The interviewer pool is filtered to the top 5% of mock conductors by candidate-side rating, drawn from engineers at Meta, Google, Stripe, and frontier AI labs.^[1:2] You pay per session, in the $100 to $250 range as of mid-2026, and you get the only feedback that's been calibrated against hundreds of thousands of comparable sessions. Use one before a high-stakes loop. Don't use one as your weekly mock.

Hello Interview ran a third option until May 2026, when they wound down their 1:1 mock and mentorship program with the rationale that "1:1 work can only ever reach so many people," refocusing on async products like Guided Practice and AI-assisted tutoring.^[7:1] That decision is itself signal: live expert mocks remain high-leverage but supply-constrained, and the market is shifting toward async plus AI augmentation. Book live experts deliberately.

The class to avoid is "same friend, every week, forever." Two friends mocking each other drift toward "good job, you got it" because raising harder questions feels rude. Mutual feedback flatlines. Mix one repeating peer with one anonymous platform mock every two to three weeks and one paid expert in the final stretch.

How many mocks before a real interview?#

Five to ten total, across roughly the last four weeks before the loop. More if you're rusty; fewer if you've interviewed recently.

The cadence rule is one to two peer mocks per week for four to eight weeks, plus one paid expert mock every four to six weeks, with one or two paid sessions clustered in the final two weeks.^[8][3:1] In a 12-week ramp:

Why not more. Mocks are stress events. The recovery and review cycle, write up the gap, do solo work on it, re-test in the next session, takes two to three days. Daily mocks prevent the gap-closure loop from running.^[2:1] A candidate who books seven Pramp sessions in seven days has trained nothing they can name a week later and has burned the evenings the underlying pattern work needed.

Why not less. Below once a week, the next mock spends its first 20 minutes re-acclimating to interview pressure instead of training under it.

There is no published curve mapping mocks-completed to offer probability. interviewing.io publishes the LeetCode-volume version (around 500 problems is the diminishing-returns elbow^[9]); they do not publish the parallel curve for mocks. Anyone selling you "five mocks gives you a 30% lift" is fabricating. Use the cadence model, track outcomes per session, and trust the trend across five sessions over the score on any one.

What does a good mock look like?#

Five minutes of intro and goals. Thirty-five to forty minutes on the problem. Ten to fifteen minutes of structured debrief. Async written feedback and a recording afterwards. That structure traces to Hello Interview's pre-sunset session format and matches what paid platforms still use today.^[7:2]

The recording is the underappreciated half. Watching yourself back the next day surfaces filler words, hesitation, and explanation gaps you cannot see live.^[8:1] Most candidates skip this step and lose half the session's value.

The debrief is where the mock converts to signal. Without structure, both parties exchange "good job," and the candidate moves on with a 0.18-R² self-assessment of how it went. With structure, the session converts to two or three actions you can drill before the next mock. Use Keep / Stop / Start for routine sessions; use Situation-Behavior-Impact for issues that need a narrative.^[10]

Three rules for the debrief itself:

• Cap at two or three points. More overwhelms working memory and the candidate retains nothing.^[10:1]
• Specific, not vague. "You hedged with 'sort of' and 'I think' three times in your first 30 seconds" beats "you seemed nervous."
• Five to ten minutes of candidate self-reflection first. Before the interviewer talks. This reduces defensiveness and primes internalization.^[10:2]

After the session, log four fields: did I identify the pattern in under five minutes, where did I get stuck (identification, implementation, edge cases, time), did I trace mentally before running, did I finish in time. After 10 to 15 sessions the log surfaces the actual gap in your prep. Without the log, you have a stack of disconnected sessions and no longitudinal signal.^[2:2]

What feedback should I ignore?#

Two categories, hard rules.

Ignore vague affect feedback. "You seemed nervous" is unactionable. The candidate cannot drill nervousness; they can drill the specific behavior that made the interviewer say it. If your debrief partner offers "you seemed nervous," the follow-up question is "what did I do that read as nervous." If they cannot name it, drop the note.

Ignore feedback that contradicts the rubric. The Code-Solve-Communicate rubric, drawn from interviewing.io's analysis of 100,000 sessions, shows that a 4-4-2 score (strong code and problem-solving, weak communication) advances at about 96%, while a 3-3-4 score (mediocre code and solving, strong communication) advances roughly three times worse.^[5:1] If a debrief tells you to trade code or problem-solving quality for more performative narration, the data says don't. Communication is necessary, not load-bearing on its own.

Ignore one-mock outliers. A 22% individual-session failure rate at the pass threshold means a single bad mock means roughly nothing.^[1:3] Wait for a trend across five sessions before changing your prep plan.

What to weight heavily: specific behavioral feedback tied to a moment in the session ("at minute 18 I asked about edge cases and you went silent for 40 seconds"); rubric-aligned feedback from a calibrated paid expert; patterns that show up in three consecutive debriefs from different partners. That last one is almost always the real gap.

What to do this week#

If you've solved fewer than 50 problems and cannot reliably identify patterns under a 20-minute timer, do not book a mock. Open Pattern recognition, pick the two patterns from Parts 1 to 9 you're weakest on, and run solo high-fidelity practice with a hidden category and a fixed timer.

If you've crossed the 50-problem mark, create a Pramp account and book one peer mock for next week. Pick LC 1 (Two Sum) or LC 242 (Valid Anagram) for the first session; both are easy enough that the pressure, not the algorithm, is the training stimulus.

If your loop is in the next two weeks, book one paid expert session on interviewing.io with a request for the company's interview style. Do that today, not tomorrow; expert calendars fill within 48 hours.

Then read Communication during the interview, which is the chapter the debrief will keep sending you back to.

References#