Real-Time Interview Assistants: The Only Number That Matters

I expected coding sessions to run much longer than conversational ones. They don’t. Across LastRound sessions between 21 March and 1 August 2026, live conversational rounds had a median duration of 151 seconds across 449 sessions. Coding rounds came in at 152 seconds across 120 sessions.

One second apart. Behavioural rounds ran slightly longer at 181 seconds, from a much smaller sample of 13.

That surprised me enough to change how I’d describe what “real time” needs to mean for these tools.

Real time is a latency claim, not a duration claim

Because usage looks the same across round types, the thing that separates a useful assistant from a frustrating one isn’t how long it can run. It’s how quickly the first useful text appears.

Break that delay into its parts. Audio has to be captured. Speech has to become text. Text has to reach a model. The model has to generate. The result has to render on your screen. Vendors typically quote only the fourth step, which is the fastest one.

So a published figure like “116ms response time” is describing model latency, not the number you experience. The number you experience is usually two to four times larger, and it varies with your microphone setup and network more than with the vendor.

Median session duration by round type

The behavioural figure comes from 13 sessions, so I wouldn’t lean on it. The first two rows are solid.

What to test instead of reading spec sheets

Run one call with yourself before you run one that counts. Ask a question out loud, then start counting. If readable text appears before you reach four, the tool is fast enough. If it doesn’t, no feature list saves it.

Two things commonly cause a slow result that has nothing to do with the vendor. The first is capturing audio from the wrong device, so the tool hears your speakers rather than the call stream. The second is a browser tab throttling in the background, which browsers do aggressively to save power.

Both are fixable in a minute and invisible until you test.

Where the delay actually comes from

If you want to reason about latency rather than trust a number, it helps to know which part of the chain the browser controls.

Audio reaches a browser-based assistant through a capture API, and that API is scoped to what you granted. MDN’s documentation on the Screen Capture API sets out how a page receives a stream of a tab, window, or display, including its audio. If the assistant is attached to the wrong stream, it either hears nothing or hears your speakers with a room echo, and echo wrecks transcription accuracy far more than model quality does.

That’s the most common cause of an assistant that seems slow and stupid at the same time. It isn’t the model. It’s picking up degraded audio and doing its best with it.

Fixing it takes under a minute: select the call stream rather than the system microphone, and use headphones so your speakers aren’t feeding back into the capture.

Accuracy matters less than you’d think

Transcription accuracy is the metric vendors compete on, and it’s close to irrelevant above a threshold. Once a transcript is roughly 90% accurate, the suggested answer is usually right, because the model recovers meaning from context.

Where accuracy does bite is technical vocabulary. Product names, library names, and acronyms get mangled far more than ordinary speech, and those are exactly the words carrying the question’s meaning. If you’re interviewing in a domain full of jargon, test with your jargon rather than a generic sentence.

We don’t have clean numbers on transcript accuracy by domain, so that observation comes from watching sessions rather than from measurement. Take it as a hypothesis worth checking yourself.

Where a real-time assistant fits

Given median sessions of about two and a half minutes, the honest description is a tool for two or three moments in a call, not a companion for the whole thing.

That’s a smaller claim than the category usually makes, and it’s the one supported by data. Preparation still does the heavy lifting. If you want to build the underlying fluency rather than lean on live support, structured mock interviews do more for you, and the two work well together.

For a broader view of how interviewers are adapting to candidates using these tools, the Stack Overflow developer survey tracks AI adoption and trust as separate lines, and the growing gap between them is the most interesting thing in it.

Frequently asked questions

What is a real-time interview assistant?

Software that transcribes your interviewer’s questions as they’re spoken and displays a suggested answer within a few seconds, while the call is still running. The interviewer sees only you, subject to how you configure screen sharing.

How fast is “real time” in practice?

Useful tools put readable text on screen within about four seconds of the question ending. Published figures usually measure only model generation, which excludes audio capture and transcription, where most of the delay actually sits.

Is there a free real-time interview assistant?

Free tiers are common, but check whether they include screen-share hiding. Many reserve it for paid plans, which leaves you unable to verify the behaviour that matters most before a real interview.

Does it work for technical interviews?

Our coding sessions run about as long as conversational ones, so usage is similar. The constraint is screen sharing: coding rounds often require sharing a full desktop or a collaborative editor, which browser-based tools handle poorly.

Why does my assistant lag?

Usually one of two local causes. Either it’s capturing the wrong audio device and hearing your speakers instead of the call, or it’s running in a background browser tab that the browser has throttled. Both take a minute to fix.

The short version

Coding and conversation rounds use these tools identically, within one second of each other. Judge on time-to-first-text, and test it yourself, because that number is the only one that changes your experience.