Most AI interview platforms are glorified chatbots with better questions. When I decided to build a spoken conversation system for candidate screening, that decision nearly killed the product before launch.
The Obvious Choice That Wasn't Obvious
When building an AI interview system, the safe play was text-based. Lower latency, fewer technical headaches, easier to parse and analyze. Every AI product manager I talked to said the same thing: "Start with chat. Voice is a nightmare."
They were right about the nightmare part.
But I kept coming back to one fact: 78% of recruiting happens over the phone. Not email. Not Slack. Phone calls. Because hiring managers want to hear how candidates think on their feet, how they structure explanations, whether they can articulate complex ideas clearly.
A text-based interview platform would be easier to build and completely miss the point.
So we went with voice. And immediately discovered why everyone warned us against it.
The Technical Debt You Don't See Coming
Speech recognition for interviews is different from speech recognition for everything else.
Siri and Alexa are optimized for short commands. Transcription tools like Otter are optimized for meetings with multiple speakers. Interview systems need something that can handle:
- 20-40 minute monologues about technical projects
- Industry jargon that doesn't exist in standard training data ("Kubernetes," "PostgreSQL," "JWT authentication")
- Non-native English speakers with varying accents
- Candidates who talk fast when nervous or slow when thinking
Off-the-shelf speech-to-text models fail spectacularly at this. In early testing, a 23% word error rate on technical terms was common. A candidate would say "I implemented Redis caching" and get transcribed as "I implemented ready's catching." Recruiters couldn't trust the output.
Fine-tuning Wav2Vec 2.0 on domain-specific data—transcripts from actual tech interviews, recordings of engineers explaining their work, podcasts about software development—can get the error rate down to around 6% for technical vocabulary.
But here's what's interesting: the remaining errors aren't random. They cluster around moments of hesitation, filler words, and self-corrections—exactly the moments that reveal how someone thinks under pressure.
These "errors" are actually features, not bugs.
The Conversational AI Problem Nobody Talks About
Building an AI that can conduct a natural interview conversation is way harder than building one that asks scripted questions.
The models are good at turn-taking now—knowing when the candidate has finished speaking, when to probe deeper, when to move on. But they're terrible at knowing why to do those things.
Early implementations often ask "Tell me about a time you faced a technical challenge" and then immediately jump to the next question, regardless of whether the candidate gave a three-sentence answer or a three-minute story. It feels robotic because it is robotic—no human interviewer would blow past a shallow answer without following up.
The solution requires a layer that analyzes response depth and triggers follow-ups. Not just keyword matching—actual semantic understanding of whether the candidate addressed the question or danced around it.
This typically means combining a large language model for conversation flow with a smaller, faster model for real-time classification. The large model decides what to ask, the small model decides if the answer was substantive enough to move forward. Running them in parallel achieves about 800ms latency between candidate finishing and AI responding.
That 800ms pause? It makes the conversation feel more natural. Humans don't respond instantly either.
The Bias Problem That Isn't What You Think
Everyone asks about bias in AI hiring. "How do you prevent discrimination against protected classes?"
Honest answer? You can't. Not completely.
But you can be transparent about where bias enters the system and give recruiters tools to catch it.
Effective approaches include:
- Standardized questions - Every candidate gets asked the same core questions in the same order. This eliminates the biggest source of interviewer bias: one person getting softball questions while another gets grilled.
- Anonymized analysis - The AI evaluation doesn't see candidate names, photos, or demographic data. It only sees the transcript and voice characteristics relevant to communication (clarity, pace, coherence—not accent or gender).
- Bias audit logs - Track which candidates get follow-up questions and why. If the AI is consistently probing deeper with one demographic group, that pattern should surface in analytics.
- Human override - Recruiters should see the full transcript alongside the AI summary. They can—and should—disagree with the AI's assessment.
The dirty secret of AI hiring tools is that removing human bias is impossible. What's possible is making bias visible and consistent. A human interviewer might grill technical candidates on Tuesdays because they're stressed, then lob softballs on Fridays when they're in a good mood. An AI applies the same standards at 2 PM and 2 AM.
That's not unbiased. It's consistently biased, which is actually useful if you design for it.
What Breaking Things Teaches You
A common early-stage bug: the AI asks a great opening question, then freezes for 14 seconds before asking it again. Candidates think the system crashed and hang up.
The cause? Conversation state management can't handle the candidate pausing to think. The silence triggers a "no response detected" error, which triggers a retry, which creates a race condition.
The fix involves adding a confidence threshold—the AI distinguishes between "finished talking" silence and "still thinking" silence based on speech patterns in the previous 3 seconds. Not perfect, but it can drop the false-positive rate from 18% to 2%.
The lesson: voice AI in high-stakes scenarios requires defensive design at every layer. Unlike a chatbot where someone can retype their message, you can't ask a candidate to "restart the interview" because your error handling failed.
Essential safeguards include:
- Automatic session recovery if connectivity drops
- Manual override for recruiters to flag bad transcriptions
- A "pause interview" button for candidates
- Playback of the actual audio alongside transcripts
The goal isn't perfection. It's resilience when things go wrong, because they will go wrong.
Key Lessons for AI Builders
If you're building AI for professional contexts—interviews, legal analysis, medical screening, financial advice—here are the hard-won lessons:
Voice is worth the complexity. The richness of verbal communication unlocks insights that text can't capture. But only if you're willing to solve the hard problems instead of shipping a minimum viable chatbot.
Domain-specific fine-tuning isn't optional. General-purpose models are amazing and terrible at the same time. They'll handle 90% of your use case brilliantly, then catastrophically fail on the 10% that matters most. Find that 10% early and train specifically for it.
Latency is a feature, not just a performance metric. Initial instinct is to optimize for sub-500ms response times. But instant responses feel uncanny in conversation. The sweet spot for conversational AI is 600-1000ms—fast enough to feel responsive, slow enough to feel natural.
Design for failure modes, not happy paths. Your AI will misunderstand accents, mishear technical terms, and ask nonsensical follow-ups. Design the system so humans can catch these failures gracefully instead of catastrophically.
The Uncomfortable Truth About AI Products
Building voice AI systems eventually leads to a realization: the AI isn't the product. The product is the workflow that the AI enables.
Candidates don't care about Wav2Vec 2.0 for transcription or which LLM handles conversation. They care that they can interview at midnight without scheduling emails. Recruiters don't care about evaluation algorithms. They care that they can review 10 candidates in an hour instead of spending all week on phone screens.
The AI is infrastructure. The value is in removing friction from a broken process.
This realization changes everything. Stop optimizing purely for model accuracy and start optimizing for user experience. Sometimes adding features like letting candidates preview questions before starting reduces anxiety and leads to better responses—even though it "breaks" the blind evaluation model you carefully designed.
A slightly worse AI that people actually use beats a perfect AI that sits unused because the UX is terrible.
The Regulatory Reality
The regulatory landscape for AI hiring tools is evolving rapidly. The EU AI Act classifies hiring tools as "high-risk AI systems." New York City requires bias audits for automated employment decision tools. This is appropriate—high-stakes AI should be regulated.
But it also means compliance must be built into products from day one, not bolted on later. Audit trails, explainability, human oversight—these aren't nice-to-haves. They're survival requirements.
For anyone building AI products in regulated industries, designing for compliance early is far easier than retrofitting later. The technical architecture decisions you make today will determine whether you can meet regulatory requirements tomorrow.
The hardest part of AI engineering isn't the models—it's everything else: error handling, latency optimization, bias mitigation, compliance, and UX. Voice AI for interviews taught me that production systems succeed or fail on these "everything else" details more than on algorithmic sophistication.