3 Hard Lessons from Building a Voice-Based AI Mock Interviewer

Jacob Zhang — Thu, 08 Oct 2026 04:38:30 +0000

I spent the last few months building a voice-based mock interview tool for ML engineers. The idea sounded simple: an AI interviewer that talks to you, asks follow-ups, and scores your answers.

The reality was harder than expected. Here are the three lessons that cost me the most time.

1. Latency is the whole product

In text chat, users forgive a 3-second reply. In voice, a 2-second pause kills the conversation. The interview feels broken.

I used the OpenAI Realtime API, which streams audio with low latency. But the API alone was not enough. I had to:

Start generating the reply while the user is still finishing their sentence (careful turn detection).
Keep the spoken replies short. Long answers sound robotic and make the user wait.
Handle interruptions. Real interviewers get interrupted. The system needs to stop talking and listen.

If you are building anything voice-first, budget half your engineering time for latency. It is not a detail. It is the product.

2. Scoring AI answers needs guardrails, or it lies to you

My first scoring version gave a 7/10 to a 5-second "I don't know." That is worse than no score at all — it teaches the user nothing and destroys trust.

What worked:

Hard gate: no score unless the user spoke substantively for at least 60 seconds.
A strict rubric: 5/10 is a solid average, 8+ is genuinely excellent. The prompt explicitly forbids inflating scores for vague answers.
Five separate dimensions (correctness, depth, clarity, structure, communication) instead of one number. A single score hides everything.

Honest scoring is a feature. Users can tell when they are being flattered.

3. Follow-up questions must come from the conversation, not a script

A fixed list of follow-ups feels like a quiz. A real interviewer listens and probes deeper into what you just said.

I generate follow-ups from the full conversation history. The interviewer tracks the candidate's reasoning and asks about the weakest point. This was the hardest part to get right — it needs enough context to be smart, but not so much that it rambles.

The test I use: if you removed the AI label, would this feel like a human interviewer? If yes, ship it.

These lessons come from building DeepOffer (https://getdeepoffer.com), a voice mock interview platform for MLE interviews. If you are preparing for interviews, the free question bank is a good place to practice. And if you are building voice AI yourself, I would love to compare notes in the comments.

I Collected 2026's Google Interview Reports. Here's What's Actually Getting Asked.

Jacob Zhang — Wed, 30 Sep 2026 06:11:23 +0000

Google's coding interviews have a reputation for being unpredictable. After going through publicly shared 2026 interview reports (Glassdoor, Blind, LeetCode Discuss, July–September), I'd say they're not random at all — the structure is actually pretty predictable. Here's what keeps showing up.

A quick note on honesty: dated first-hand reports from the last few months are scarce. Most of what's public is pattern-level, not exact questions. Below I separate confirmed sightings (a report explicitly named or clearly described the exact problem) from high-frequency patterns (the report described the shape; these are Google's classic favorites under that shape). Don't trust anyone selling you "the exact 2026 question list" — including me.

1. Graphs are the #1 topic this year

Island-counting problems (the LeetCode 200 family) keep appearing as round openers — but they're just the warm-up. The real test is the follow-up, where the interviewer adds dynamic constraints mid-round ("now land appears over time — track the island count as it changes").

Also showing up: grid traversal where your movement depends on where you came from (state is more than just coordinates), and ranking-from-pairwise-results problems, which are topological sort in disguise.

If you grind one chapter, make it graphs: 200, 695, 994, 417, 329, 207, 210, 269.

2. The DP → binary search arc

The most 2026 thing I saw: you start with a DP formulation, and the interviewer keeps pushing — find the bottleneck, optimize — until you land on a binary search solution. The textbook example is the "painter's partition" problem (LC 410): the DP is O(n²k), the expected answer is binary-search-the-answer plus a greedy check.

Train this as a template, not a trick: 410, 1011, 1482 are the same muscle. If your DP solution passes without a follow-up asking "can you do better," something went wrong.

3. Trie + HashMap combos

One August report described a medium-hard Trie problem combined with hash maps — and it earned a Strong Hire. The lesson: practice the two together, not in isolation. 208 (implement it cold), 212, 421.

4. Union-Find gets grilled on correctness

Interviewers aren't just checking that you use DSU — they're digging into path compression, union-by-rank, and whether you can argue correctness or offer alternative traversals. 684 until it's muscle memory, then 990, 128.

5. Streams and heaps

Moving averages and top-K over data streams keep appearing in both SWE and MLE rounds. 346 was a confirmed sighting; the two-heap median template (295) and Kth-largest (703, 215) round it out.

The confirmed-sighting shortlist

These eight were explicitly named or clearly described in 2026 reports, so they're the safest bets if you're short on time: 200, 416, 174, 410, 2188, 128, 346, 315.

I turned the full research into an 81-problem checklist, ranked by 2026 frequency — every problem labeled as confirmed vs. pattern-matched, each with its source and a prep tip. It's $19 on Gumroad if you want the whole thing: https://mleplaybook.gumroad.com/l/google-leetcode-interview-checklist-2026

Good luck out there. And if you've interviewed at Google recently, drop what you saw in the comments — I'll fold it into the next update.

DEV Community: Jacob Zhang