Where mock interview answers break: what our first 27 reports show

What this data is, and what it is not

This is early data, and we want to be plain about its size. It covers 27 completed mock interviews from 10 candidates, between 7 September and 2 October 2026:

• 11 technical discussion rounds
• 9 coding rounds
• 4 system design rounds
• 3 behavioural rounds

We counted only finished interviews with a fully scored report and a usable transcript, and left out staff, test and demo accounts. Everything below is an aggregate: no names, no quotes, nothing that identifies a candidate. Scores and verdicts come from the gap report, which is produced by an AI evaluator reading the transcript and any code or diagram from the round.

Ten people is not a study. Treat these as patterns worth checking in your own practice, not as facts about every candidate. Where a number rests on a handful of cases, we give the count rather than a percentage. We will update this post as the sample grows.

1. Coding rounds: nobody dry-ran their code

Across 7 coding problems where we tracked how candidates talked through their solution:

• 0 of 7 dry-ran the code on an example before calling it done.
• 3 of 7 explained their approach before they started coding.
• 3 of 7 stated the time complexity out loud.

The rubric scores line up with that. Each rubric row is scored out of 100, and the lowest coding average was edge cases, at 22, followed by code quality (31), correctness (33) and explaining the approach (35). Efficiency was the strongest area at 60. In other words, candidates often found a reasonably efficient idea, then lost marks on the parts that come after the idea: checking it, handling the awkward inputs, and saying what they were doing.

Of 26 coding questions asked, only 2 were rated strong, and 8 were left unanswered.

The cheapest fix in the whole dataset: before you say "done", trace one normal input and one edge case through your code out loud. It takes two minutes and it is the step no one took.

We wrote up a full routine for this in how to think aloud in a coding interview.

2. Technical rounds: answers stop at the surface

In technical discussion rounds, the report rates how deep each answer went on every topic the interviewer probed. Of 43 topics:

• 20 were answered at surface level — a definition, without how or why.
• 19 reached a working level — correct and usable, but no further.
• 4 went deep — tradeoffs, failure cases, or how it behaves at scale.

Concept depth averaged 39 out of 100, and of 51 questions asked in these rounds, only 7 were rated strong. A typical pattern: the candidate defines the term correctly, the follow-up asks when would you not use it or what happens when it fails, and the answer stops there.

The practical takeaway is to prepare every topic one level past the definition. For each concept on your list, have an answer ready for "why", "what does it cost", and "when does it break".

3. System design rounds: components and tradeoffs go missing

This is the smallest group — 4 rounds from 3 candidates — so read it as a signal, not a measurement. Still, the signal was consistent:

• Of 30 components the reports expected for the problems asked, 25 were never reached. Only 3 were drawn on the whiteboard and 2 more were discussed.
• 1 of 4 candidates stated scale assumptions — how many users, how many requests.
• 0 of 4 discussed the data model.
• Tradeoffs averaged 16 out of 100, and component coverage averaged 12.

When most of a design is never reached, time is usually the constraint: too long on one part leaves nothing for the rest. A fixed plan for the 45 minutes — requirements, estimates, API, data model, high-level design, then deep dives — prevents most of this. We lay that plan out in system design interview for freshers.

4. Delivery was not the main problem

It is easy to assume nervous speech is what sinks an answer. Across the 20 interviews where speech was measured directly, the numbers do not point that way:

• Median speaking pace was about 175 words per minute — on the quick side, but clear enough to follow.
• Median filler-word rate was under 1 per 100 words.
• The median longest uninterrupted answer was 26 seconds.
• Candidates typically paused about 5 seconds before starting an answer.

None of those numbers explains the low scores above, which come from what the answers contained, not how they sounded. Practising delivery on its own — cutting "umm", slowing down — will not fix that. Practising the follow-up will.

What to take from this

On average, each report flagged 1.7 moments where an answer weakened for every 1.0 moment it marked as strong. The patterns above come down to five habits:

1. Coding: dry-run your code on a normal case and an edge case before you finish.
2. Coding: say your approach and its complexity out loud, before and after.
3. Technical: prepare "why", "what it costs" and "when it breaks" for every topic.
4. System design: state scale and the data model early, and budget your time across the whole design.
5. Everywhere: expect the second question. The first answer is rarely where marks are lost.

None of these are things you can fix by reading. They are habits, and habits come from doing the round out loud with someone asking the follow-up — see our four-week mock interview plan for a way to build them.