Mock Interviews: Why They Work and How to Run One
Here's an uncomfortable pattern coaches see weekly: a candidate who has solved four hundred practice problems freezes eight minutes into a real interview. Not because they don't know the material — because they've never performed it: out loud, under observation, with a clock running and a stranger deciding their future. Interviewing is a performance skill, and performance skills are built through rehearsal, not reading.
Why solo prep isn't enough
Solo preparation optimises for knowledge; interviews test retrieval under pressure. The differences that matter:
- Speaking ≠ thinking. Explaining an approach aloud while writing code is a split-attention task you have to train specifically — it's why capable engineers go silent for five minutes and lose the interviewer.
- No feedback loop. Practising alone, you can't see your own tics: the "we" stories that hide your contribution, the rambling STAR situations, the complexity claim you never justified. An observer catches in one session what you'd never self-diagnose.
- Pressure is trainable. Stress narrows working memory — but exposure widens it back. The tenth time someone watches you code, your heart rate simply doesn't spike the way it did the first time. That adaptation only comes from being watched.
What a good mock interview looks like
A mock is only as useful as it is realistic. The ingredients:
- Real conditions. Full length (45–60 min), camera on, shared editor or whiteboard, no pausing, no peeking at notes. If the real interview is on CoderPad, mock on CoderPad.
- An interviewer who can calibrate. A friend reading questions is better than nothing; someone who has run real loops — and knows what a passing L5 answer sounds like — is a different sport. They probe where real interviewers probe.
- The right question type. Match the target: coding, system design, behavioural, or company-specific rounds like Amazon's leadership principles or Google's Googleyness.
- Structured debrief, immediately after. Not "that was pretty good" — a pass through the actual rubric: communication, problem-solving process, correctness, and the specific minute things went sideways.
- A written action list. Two or three concrete fixes per session ("state complexity before coding", "cut Situation to two sentences"), carried into the next mock.
A cadence that works
- One diagnostic mock early — before heavy prep, to find out what actually needs work. Most people mis-guess their weakest round.
- Weekly mocks during prep, alternating round types, hardest type most often.
- Two dress rehearsals in the final week — same time of day as the real interview, full loop conditions, zero new material.
Three to five serious mocks with real feedback routinely outperform another hundred solo problems — the marginal rep of rehearsal is simply worth more than the marginal rep of content.
Being a good mock candidate
Extract full value from each session: treat it as real (no restarts), let yourself struggle before taking hints (the struggle is the training), ask for the harsh version of the feedback, and re-run the same question a week later to confirm the fix stuck. Keep every action list — the trend line across sessions tells you when you're ready.
Where coaches fit
The rarest ingredient above is the calibrated interviewer: someone who has sat on hiring committees, knows the bar at your target companies, and can tell you not just what went wrong but what it reads as from the other side of the table. That's precisely what our coaches do — many have run hundreds of real loops at the companies you're targeting, and a mock with one comes with the rubric-level debrief this post describes.
Ready to rehearse properly? Get matched with a coach for a mock interview with real-loop feedback — diagnostic first session, then a cadence tuned to your interview date.