Mock interviews are useful, but they're not training. They're the test. The training is the skills the test measures.
This is a common mistake: candidates run 20 mock interviews in a week, score gradually higher, and assume they got better at interviewing. They didn't. They got better at that mock. The score doesn't transfer to the real interview because the real interview is testing the same underlying skills with different surface questions.
What actually transfers
- Trade-off vocabulary — naming what you're giving up, in plain words, without being prompted.
- Constraint pivots — when the interviewer changes a number, your answer changes too.
- Recovery patterns — when you hit a question you can't answer, you know what move to make next.
None of those are mock-interview-specific. They show up in code review, in design docs, in arguments with PMs. Practising them outside the interview context is what makes them robust inside it.
The Cruto loop
This is why each Cruto mock is followed by a debrief that names the underlying skill, not just the score. "You stalled on idempotency" is the symptom. "Your trade-off vocabulary collapses under technical pressure" is the cause. The cause is the thing to work on between mocks. The next mock is just the test of whether the work compounded.