Interview Copilot or Mock Practice? Both, For Different Jobs
Mock practice sessions on LastRound have a median duration of 72 seconds, across 138 completed AI mock interviews up to 1 August 2026. Live interview sessions run more than twice that, with a median of 151 seconds across 449 sessions.
Practice is shorter than the real thing. That’s backwards from what you’d expect, and it’s the most useful fact I can give you about how people actually split their time between preparing and getting live help.
Why practice sessions are so short
Because practice is iterative and live use isn’t. In a mock session you answer, decide it came out badly, stop, and start again. Six seventy-second attempts in one evening is a completely normal pattern.
A live session can’t work that way. The call runs at the interviewer’s pace and you don’t get to restart.
This is why the two tools feel so different despite doing superficially similar things. One is a rehearsal loop. The other is a single take.
Setup intent splits almost evenly
Across 1,393 interview setups created between 24 January 2025 and 30 July 2026, 721 were configured for live interviews and 672 for mock practice. That’s 52 to 48.
| Measure | Mock practice | Live interview |
|---|---|---|
| Setups configured | 672 | 721 |
| Median session duration | 72s | 151s |
| Restartable | Yes | No |
So people aren’t choosing one or the other. They’re doing both, in roughly equal measure.
What each one is genuinely for
Practice builds the thing you can’t fake: fluency. Saying an answer out loud is a different skill from knowing it, and the gap between those two is where most interviews are lost. You close that gap by repetition and there’s no shortcut.
A copilot covers a narrower case. It helps when you know something and can’t retrieve it under pressure, which happens to everyone and has nothing to do with ability. It also gives you a transcript when the connection is poor.
What a copilot can’t do is give you depth you don’t have. The interviewer’s second question will find that out within about thirty seconds.
If you only have a week
Spend most of it on practice, and specifically on speaking rather than reading.
Pick four projects from your CV and talk through each one for ten minutes: what the constraint was, what you chose, what went wrong, what you’d change. Record yourself once and listen back, which is uncomfortable and more useful than anything else on this list.
Then, if you want live support as a safety net, test it before the day rather than during it. Those two things are complementary. Our mock interviews and the live copilot run off the same setup, so a practice session doubles as a rehearsal of the tooling.
I don’t know how much of the improvement people report comes from the practice itself versus simply having said the words out loud once before. Both explanations fit the data we have.
A note on what interviewers are adjusting to
Interviewers are increasingly aware that candidates have live assistance available, and the common response has been to push harder on follow-ups rather than to ban tools outright. That shift rewards preparation and penalises reliance, which is worth knowing before you decide how to split your time.
The Stack Overflow developer survey tracks AI adoption and trust separately, and the widening gap between those two lines is a reasonable proxy for how hiring teams are thinking about this.
What to actually practise
Most people practise the wrong thing. They re-read notes, which feels productive and builds almost no fluency, because reading and speaking use different retrieval paths.
Practise producing the answer from nothing. Say it out loud with no notes visible, even if it comes out badly the first three times. The discomfort is the point: that’s the same retrieval you’ll need to do in the room.
Three things are worth rehearsing specifically. Your opening sixty seconds on each CV project, because that’s asked every time. One failure story with a real correction in it, because “tell me about something that went wrong” defeats people who haven’t thought about it. And your compensation answer, which is the one candidates most reliably fumble despite it being entirely predictable. Bands by level are published on levels.fyi, and going in without that number is how offers get anchored low.
Everything else is domain knowledge, and domain knowledge is what a copilot can partially cover. These three are not.
One caveat on the practice numbers. Our mock sessions skew short partly because the product makes restarting cheap, and a tool that charged more per attempt would probably show longer sessions and fewer of them. So read 72 seconds as a fact about how people behave when retrying is free, not as a recommendation about ideal length. The useful part is the ratio: many short attempts, not one long one.
Frequently asked questions
Should I use a mock interview tool or an interview copilot?
Both, for different jobs. Practice builds fluency you can’t get any other way. A copilot helps with recall under pressure during the real call. In our data usage splits almost evenly, 672 mock setups against 721 live.
How long should a practice session be?
Shorter than you’d think. Our median mock session is 72 seconds, because people answer, stop, and retry. Several short attempts beat one long uninterrupted run.
Can a copilot replace preparation?
No. It can supply an opening answer, but not the depth behind it. Follow-up questions expose that gap quickly, and follow-ups are where interviews are actually decided.
How many mock interviews should I do?
Enough that your four main CV stories come out cleanly without hesitation. For most people that’s somewhere between six and fifteen short attempts, not one long session.
Does practising with AI help for human interviews?
For fluency and structure, yes, because the skill being rehearsed is speaking your answer aloud. It won’t replicate interviewer pressure or unpredictable follow-ups, so treat it as a starting point.
If you take one thing
Practice sessions run half as long as live ones because you get to stop and try again. That’s the entire advantage of preparing, and it disappears the moment the real call starts.
Written by
Dhanush
Writes about the engineering behind real-time conversation tools and how they hold up in practice.
