DEV Community: ANBMZ L

I Analyzed Real Mock Coding Interviews. Here's What Separates Hires from No Hires

ANBMZ L — Thu, 09 Apr 2026 20:08:59 +0000

We run AI mock coding interviews on intervu.dev. Each session is scored across five pillars (algorithms, coding, problem solving, verification, and communication) on a calibrated 1-10 rubric.

We looked at the anonymized, aggregate patterns across completed interviews: how candidates spend their time, how much code they write, and where they lose points.

Only 52% received a Hire or Strong Hire signal. The reason isn't what most candidates expect.

Verification Is the Silent Killer

Here are the average scores across all five pillars:

Pillar	Avg Score
Coding	6.94
Algorithms	6.77
Problem Solving	6.26
Communication	5.87
Verification	5.65

Verification (testing your own code, walking through examples, catching edge cases) is the weakest pillar across the board.

Most candidates write code that works and then stop. They don't trace through examples. They don't check boundary conditions. They don't walk through their logic before hitting "Run."

The good news? Verification is the easiest pillar to improve. You don't need to learn a new algorithm. Just build the habit of saying "Let me trace through this with a concrete example" before you call it done.

The Biggest Gap Between Hire and No Hire Isn't Coding

When we split the data by outcome, verification isn't just the weakest pillar. It has the widest gap:

Pillar	Hire Avg	No Hire Avg	Gap
Verification	7.06	4.36	2.70
Algorithms	8.12	5.82	2.30
Coding	8.12	6.27	1.85
Communication	6.94	5.18	1.76
Problem Solving	7.25	5.73	1.52

A 2.7-point gap on a 10-point scale. Candidates who get the Hire signal score nearly twice as high on verification.

The single biggest differentiator between a Hire and a No Hire is whether the candidate tests their own work.

Writing correct code is table stakes. Everyone studies LeetCode. Proactively tracing through your solution, spotting edge cases, and catching your own bugs before being asked? That's what most people skip.

No Hires Spend More Time Coding, Less Time Testing

We looked at how candidates actually spend their time during the interview:

Metric	Hire vs No Hire
Time spent coding	No Hires spend 2.4x more
Time spent testing	Hires spend 68% more

No Hire candidates spend 2.4x more time coding, and 40% less time testing.

The pattern is consistent: No Hire candidates jump into code, get stuck, iterate, get stuck again, and run out of time before testing. Hire candidates arrive at working code faster and spend that saved time on verification.

They're not faster coders. They plan better.

More Code ≠ Better Code

No Hire candidates consistently write ~15% more code than Hires. Longer solutions are messier, have more edge cases to miss, and are harder to trace through.

Clean, concise code is itself a form of verification. Less surface area, fewer bugs.

Finishing Is a Skill

A lot of candidates abandon interviews partway through. They get stuck, or the time pressure gets uncomfortable, and they quit.

Finishing a full interview is a skill that requires practice. If you regularly quit mock interviews midway, the interview itself, not just the algorithm, is what you need to work on.

Three Data-Backed Changes to Make

1. Practice the Dry Run

After writing your solution, trace through it with a specific input. Say the variable values out loud. Check the boundaries. This one habit is the biggest differentiator we found.

"Let me walk through this with [2, 7, 11, 15] and target 9..."

2. Design Before You Code

Hire candidates get to coding faster, not because they skip design, but because they're efficient about it. State your approach in 2-3 sentences, confirm the complexity, and start writing. Don't wait for the perfect plan.

3. Write Less, Not More

If your solution is getting long, step back. Long solutions have more bugs, take longer to debug, and are harder to verify. A clean 30-line Python solution is almost always better than a tangled 50-line one.

Methodology

All data is fully anonymized. No individual sessions, users, or identifying information were used. Analysis was performed on aggregate metrics only.

The thing that separates Hires from No Hires isn't algorithm knowledge or coding speed. It's whether you test your own work. And that's the easiest thing to practice.

If you want to try it yourself, intervu.dev runs AI mock interviews with signal-based feedback across all five pillars. You can start from the Grind 75 pathway or practice any LeetCode problem as a full mock interview.

Killing Voice AI Lag: The Pre-Warming Trick

ANBMZ L — Thu, 26 Mar 2026 00:03:24 +0000

When I was building intervu.dev, an AI mock coding interviewer that conducts full voice interviews in the browser, one of the most annoying problems I ran into was a noticeable gap between when the AI finished speaking and when the microphone actually went live for the candidate to respond.

The AI would finish its sentence, and then there'd be this dead pause of around 850ms before the mic activated. In a real interview, that kind of delay feels broken. It kills the conversational flow and makes the whole thing feel like a chatbot, not an interviewer.

Here's what was causing it and how pre-warming the WebSocket connection during TTS playback got it down to under 400ms.

The problem

The turn-taking loop in intervu.dev works like this:

The AI generates a response and sends it to TTS
TTS audio streams back and plays in the browser
Once TTS finishes, the mic WebSocket connection is opened and the candidate can speak
Audio is streamed to the backend over that WebSocket, transcribed in real-time, and the turn continues

The issue was in step 3. Opening a fresh WebSocket connection after TTS finishes takes time. DNS resolution, TCP handshake, the WebSocket upgrade handshake. On a typical connection that overhead was sitting around 800-900ms. Most of the time it was fine in testing, but on slower connections or under load, it was noticeably bad.

The fix: pre-warm the connection during TTS playback

The insight is simple: TTS playback gives you a natural window of time where the user is listening and not yet expected to speak. That window is completely idle from a WebSocket perspective. Instead of waiting until TTS finishes to open the mic connection, you can open it during playback and have it ready to go the moment the AI stops speaking.

// When TTS playback starts, immediately begin opening the mic WebSocket
function onTTSPlaybackStart() {
  prewarmMicConnection();
}

function prewarmMicConnection() {
  // Open the connection early but don't activate the mic yet
  micSocket = new WebSocket(MIC_WEBSOCKET_URL);

  micSocket.onopen = () => {
    micConnectionReady = true;
  };

  micSocket.onerror = (err) => {
    // Fall back to opening it on-demand if pre-warm fails
    micConnectionReady = false;
  };
}

// When TTS finishes playing
function onTTSPlaybackEnd() {
  if (micConnectionReady && micSocket?.readyState === WebSocket.OPEN) {
    // Connection already open, activate mic immediately
    activateMicrophone(micSocket);
  } else {
    // Pre-warm didn't complete in time, open on-demand
    openMicConnectionAndActivate();
  }
}

The pre-warm happens in the background while audio is playing. By the time TTS finishes, even if the AI only speaks for a second or two, the WebSocket handshake is almost always done.

The numbers

Before: ~850ms gap between TTS end and mic activation, measured as time between the TTS ended event firing and the first audio chunk arriving at the backend.

After: under 400ms consistently, and closer to 50-80ms on good connections where the pre-warm had plenty of time to complete.

The 400ms worst case comes from the fallback path. If the AI says something very short (under about 1 second), TTS can finish before the pre-warm completes and we fall back to opening on-demand. For anything longer than a second of speech, the connection is reliably ready.

A few things worth knowing

Close the connection if the turn gets interrupted. If the user clicks stop or the interview ends mid-TTS, you need to close the pre-warmed socket cleanly. Leaving stale open connections is the obvious failure mode here.

One connection per turn. Don't reuse the pre-warmed connection across multiple turns. Open a fresh one each time TTS starts. This avoids state leakage and keeps the server-side logic simple.

Server-side idle timeout. Your backend will see a WebSocket connection open and then sit idle for a few seconds before the client sends any audio. Make sure your idle timeout is long enough to survive that window. I set mine to 30 seconds, which is comfortably longer than any realistic TTS utterance.

It degrades gracefully. The fallback to on-demand opening means users on very slow connections still get a working experience, just with slightly more latency. The pre-warm is purely an optimization, not a hard dependency.

Why this matters for voice AI apps

Any application that alternates between AI speech output and user speech input has this same dead-time window during playback. The pattern generalizes well: use the playback window to pre-warm whatever connection or resource you need for the next user action. In intervu.dev's case it's a WebSocket for audio streaming, but the same idea applies to pre-fetching context, warming up a transcription session, or pre-loading the next state in a conversational flow.

If you're building anything with voice turn-taking and you're seeing a gap at the handoff point, this is almost certainly part of what's causing it.

I'm building intervu.dev as a solo project, an AI that conducts real FAANG-style mock coding interviews in the browser, voice and all. If you're curious about the broader architecture (Docker-in-Docker for code sandboxing, LLM prompt state machines, real-time STT), I wrote about the full build here.

How I cut mic activation latency in half by pre-warming WebSocket connections during TTS playback

ANBMZ L — Wed, 25 Mar 2026 23:55:43 +0000

When I was building intervu.dev - an AI interviewing app - I found that the latency between the AI finishing speaking (TTS) and the mic activating to capture the user’s response was too high.

This was because the TTS and STT WebSocket connections were opened sequentially.

I cut this latency in half by opening the STT WebSocket connection as soon as the TTS WebSocket connection was established and the first audio chunk was received.

This “pre-warming” means the STT connection is ready to go the instant the TTS finishes.

I wrote about the full build here.