Inside HireQwik's Real-Time Voice AI Pipeline

A candidate finishes a sentence on a HireQwik screening call, and roughly a second later the AI is already asking a follow-up. Nothing about that pause looks unusual on the recording. What it hides is a full voice AI STT LLM TTS pipeline running end to end in that gap: audio turned into text, text reasoned over and turned into a reply, and that reply turned back into audio the candidate hears as a voice, not a beep-then-silence-then-response.

We get asked what’s “really” happening during a call more than almost any other product question, usually by an HR lead who’s used a chatbot before and assumes the voice version is the same thing with a text-to-speech layer bolted on top. It isn’t. Here’s the actual relay, and why the boring-sounding parts of it — turn-taking, latency, who speaks next — are harder to get right than the flashy parts.

The three-stage relay

Every HireQwik screening call runs the same three-stage handoff on each turn. Speech-to-text (STT) listens to the candidate’s audio and turns it into words as they’re speaking, not after they stop. That partial transcript feeds a large language model, which is where Azure OpenAI’s GPT-4o-mini does the actual reasoning: deciding whether the candidate answered the question, whether a knockout condition just triggered, and what to ask next based on the JD-derived screener-build document behind that specific role. The model’s text reply then goes to text-to-speech (TTS), which converts it back into audio the candidate hears.

That’s the pipeline architecture most production voice AI systems run today, and it’s not unique to screening calls — the same three-stage relay powers voice agents across customer support, sales, and scheduling. What’s specific to HireQwik is what the LLM stage is actually reasoning about: a per-JD rubric, a phase-0 knockout question that can end the call in the first minute or two if a disqualifier fires, and a live decision about what to probe next based on how the candidate just answered.

Why turn-taking is the actual hard problem

The interesting engineering problem in a voice pipeline isn’t any single stage — it’s deciding when the candidate has actually finished talking. Say it too early and the AI interrupts mid-sentence, which reads as rude and rattles the candidate. Wait too long and the call feels sluggish, like talking to someone on a bad phone line. Getting this right means the system has to process a partial transcript while the candidate is still speaking, not wait for a full stop, so it can start forming a reply on the first clause instead of the last one.

This matters more for a screening call than it does for, say, a customer support bot answering a simple question. A candidate explaining a project they worked on will pause mid-thought, restart a sentence, or trail off before picking the thread back up. A pipeline tuned only for short, clean utterances handles a real explanation badly — it either jumps in during a natural pause or leaves a long enough gap that the candidate assumes something broke.

Where the latency actually comes from

Human conversation has a natural response window of roughly 300-500 milliseconds before a pause starts to feel like a person, not a delay. Voice AI latency research breaks the budget down by stage: speech-to-text adds somewhere in the low hundreds of milliseconds, the language model’s response time varies widely depending on how much reasoning it needs to do, and text-to-speech adds a smaller chunk on top before the first word of audio reaches the candidate. Stack a slow version of each stage together and a call starts to feel like a walkie-talkie exchange instead of a conversation — which, for a candidate trying to make a good impression under enough pressure already, is its own source of a worse signal.

The practical fix most real-time systems use, and HireQwik’s pipeline is no exception, is streaming every stage instead of waiting for each one to fully finish before starting the next. The model starts producing a reply on partial input, and the audio starts playing as soon as the first chunk of speech is ready, rather than waiting for the whole sentence to render. None of that shows up to the candidate as a technical detail. It shows up as whether the call feels like talking to something that’s listening, or waiting for its turn.

Why real-world connections matter more than a demo

A three-stage pipeline running over a live phone or app connection has more ways to degrade than a chat interface ever will, and it’s worth being direct about why that matters here specifically. A candidate’s audio can thin out for a second on a weak mobile connection. Background noise in a hostel room or a busy household can make a word harder for the speech-to-text stage to catch cleanly. None of this is unique to HireQwik — it’s true of any real-time voice system running over a real network instead of a lab connection.

It’s also one of the reasons a voice pipeline can’t be judged purely on how it performs in a quiet office demo. Indian campus hiring runs candidates through this call from hostel Wi-Fi, shared mobile data, and building stairwells with patchy signal, not a fibre connection in a conference room. A pipeline whose turn-taking and latency only hold up under ideal conditions would quietly disadvantage candidates with worse connectivity — which correlates with geography and income in ways that have nothing to do with how well someone would have answered on a better line. Designing for the messy version of the network, not the clean one, is part of what “real time” has to mean here.

What actually rides on getting this right

HireQwik’s standard screening conversation runs 15-20 minutes, and the concurrency ceiling on a single campaign is 20 candidates per 15-minute slot — both numbers that only work if each individual call’s pipeline stays fast and reliable under load, not just in a one-candidate demo. HyperVerge’s July 2026 usage alone ran 1,074 AI interviews across 9 roles in a single month; that volume doesn’t survive a pipeline where turn-taking or latency degrades once a few dozen calls are running at once.

None of the pipeline mechanics change what gets scored — that’s still the two-evaluator layer reading what was said against how it was said. But a laggy or interruption-prone pipeline actively damages the signal that layer is trying to read, because a candidate who’s fighting the call’s timing isn’t giving you their real pace, real fillers, or real hesitation rate — they’re giving you their reaction to a bad connection. Getting the relay boring and invisible is what makes the rest of the scoring trustworthy.

If you want to hear what a full 15-20 minute call actually sounds like end to end, book a HireQwik pilot and run one on a real JD.