I asked four people to run a mock interview with me before a system design round. Two said yes. One rescheduled twice and then stopped replying. The fourth ran it, was extremely encouraging, and told me everything was great. I bombed the real one nine days later.
The encouraging friend was the worst of the four outcomes. Being told you're fine is more damaging than getting no practice at all, because it removes the thing that would have made you prepare harder.
So I started practising alone. Badly, at first.
Why solo practice usually fails
The failure mode isn't lack of discipline. It's grading.
When you answer a question in your head, you grade the version you meant. When you say it out loud to another person, they grade the version that came out of your mouth. Those are different answers. The gap between them is roughly the whole difficulty of interviewing.
My first month of solo prep was reading questions and thinking "yeah, I know that one." Every single time, I did know it. And every single time, I'd have taken forty seconds too long to get to the point, buried the answer in setup, or forgotten to say the one thing the interviewer was listening for.
Knowing something and being able to say it under mild social pressure in under two minutes are unrelated skills. Reading questions trains the first one.
What the session data says about how people actually practise
I work on an interview tool, so I went and looked at our own numbers to check whether other people practise the way I did.
Across 1,393 interview sessions configured on LastRound AI between January 2025 and July 2026, the difficulty selector broke down like this: 1,374 people chose intermediate, 16 chose expert, and 3 chose beginner.
98.6% picked the middle option.
Two readings of that. The charitable one is that intermediate genuinely fits most candidates. The honest one is that the difficulty selector is close to useless, and people click the default because they don't know how to calibrate themselves. I lean towards the second, and it's an awkward thing to say about your own product.
The same data shows a near-even split between live sessions and mock practice: 721 live, 672 mock. I found that genuinely surprising. I expected practice to dominate, on the theory that people prepare more than they interview. They don't, or at least these ones don't.
I don't know whether that holds outside our user base. 1,393 sessions from one product skews towards people who already went looking for interview tooling, which is not a random sample of job seekers.
The method that fixed it for me
Four rules. Two of them are annoying and that's the point.
Say it out loud, standing up. Not muttered. Full voice, as if someone's listening. You will feel ridiculous. You will also immediately notice that your answer has no shape, because you can hear yourself running out of road at the ninety-second mark.
Record it and listen back the next day. Not the same day. The next day, when you've lost the memory of what you meant and can only hear what you said. This is the single highest-value thing on the list and almost nobody does it, because listening to your own recorded voice is genuinely unpleasant.
Start the timer before you start thinking. Real interviews don't give you a settling-in period. If you need thirty seconds of silence to structure an answer, that silence is part of your answer and it should be in the recording.
Write the grade before you listen. Predict your score, then listen, then score it properly. The gap between predicted and actual is your calibration error, and it's the number that actually improves over weeks.
That fourth one came from a friend who coaches debate, and it's the one that changed things fastest. My predictions were consistently a full point higher than reality for about three weeks. Then they converged. Once they converged I could trust my own judgement mid-interview, which is what you actually need on the day.
Where a tool helps and where it doesn't
The recording-and-reviewing loop is tedious enough that I stopped doing it properly after about two weeks. That's the real problem with solo practice: it works, and you won't keep it up.
What kept me honest was moving the loop into something that ran it for me. I used AI Mock Interview for the voice sessions, mostly because it removed the two steps I kept skipping: it asks the follow-up I'd never have asked myself, and it scores the answer before I get a chance to grade myself generously.
What it doesn't replace is a senior person in your actual field telling you that your architecture answer was fine but you buried the tradeoff. If you have access to that person, use them. Most people asking this question don't, which is why they're asking.
The other limitation: automated feedback is good at structure and pace, weaker on domain judgement. It'll catch that you rambled. It's less reliable on whether your specific caching decision was defensible for that specific system. Treat the score as a signal about delivery, not a verdict on your engineering.
A practice week that actually fits around a job
Three sessions a week, forty minutes each. Not daily. Daily practice sounds committed and collapses by day five.
Monday: two behavioural questions, recorded, reviewed Tuesday. Wednesday: one technical question at full length. Saturday: review both recordings back to back and write down one thing to change.
One thing. Not a list. Lists don't survive contact with a real interview, and the point of the week is to change one habit at a time.
If you want to sanity-check which technologies are worth the technical slot, the Stack Overflow Developer Survey is a reasonable read on what's actually in use.
What I'd genuinely like to know from anyone else doing this: does the predict-then-listen thing work for you, or did you find a faster way to calibrate? Three weeks felt slow.
Top comments (0)