Why Technical Interviews Keep Failing Qualified Candidates
A researcher at NC State and Microsoft ran a controlled study with 48 CS students in 2020. One group solved coding problems privately. The other went through standard whiteboard interviews, observed by an interviewer. The private group performed twice as well. Same problems. Same candidates. The only difference was the person watching.
I’ve been thinking about that study a lot. After going through roughly 40 technical interviews as a candidate and sitting on the other side of around 200 as an interviewer and hiring manager, I don’t think the result is surprising. I think it’s the thing the industry mostly pretends isn’t true.
Most people who fail technical interviews aren’t failing because they can’t code. They’re failing because they’ve never practiced performing under observation. Those are different skills. We conflate them constantly.
The panic response is the actual problem
Stress under observation compresses working memory. A candidate who has explained dynamic programming to a colleague a hundred times will blank on a DP problem the moment an interviewer is watching and a 45-minute timer is running. This isn’t a character flaw. It’s a fairly predictable human response to a situation that triggers social evaluation anxiety.
The NC State study found that every woman who took the public whiteboard interview failed, while every woman who took the private version passed. That’s a stark result. It suggests the format itself is screening for anxiety tolerance rather than programming ability. Whether the same pattern holds across larger samples is uncertain – the study had 48 participants – but the directional signal is hard to ignore.
The fix isn’t to calm down. The fix is repeated exposure. The same way pilots use simulators to practice emergency procedures before they ever face them in a real cockpit, candidates need to practice being watched and interrupted and asked to explain their thinking. Once. Then again. Then again until the physiological response dampens.
Solving in silence kills your signal
The second most common failure mode I’ve seen has nothing to do with the code itself. Candidates work silently, produce a solution, and then look up. The interviewer has spent the last 15 minutes watching someone type and has almost no data on how that person thinks.
What interviewers actually want is the internal monologue made external. Something like: “My first instinct is a hash map here for O(1) lookups, but I want to check whether we’d have memory constraints before I commit to that.” That sentence tells the interviewer you understand trade-offs, you think about constraints, and you’re aware there might be a better path. It takes about four seconds to say and it’s worth more than an elegant final solution delivered in silence.
Practice this specifically. Solve problems out loud, with someone in the room or on the other end of a call. The narration skill atrophies completely if you only practice solo.
The LeetCode grind problem (and the smarter alternative)
There’s a version of interview prep where a candidate grinds through 400 LeetCode problems in eight weeks by memorizing patterns. They know the two-pointer trick and the sliding window trick and the union-find trick. Then they hit a problem in an interview that’s 15% different from what they memorized and they freeze, because they never built the underlying understanding – they built a lookup table.
The more effective approach: 60 to 80 problems, worked deeply. For each one, after you solve it, explain why the solution works. Explain what would break if the constraints changed. Think about the problem class it belongs to, not just the specific answer. That takes longer per problem and feels slower, but the transfer to novel problems is dramatically better. I’d take a candidate who deeply understands 70 problems over one who’s pattern-matched their way through 450.
System design gets under-prepared almost universally. Candidates spend 90% of their prep time on algorithmic coding and show up to a system design round with vague ideas about caching and load balancers. The design round is often the deciding factor for mid-level and senior roles. It deserves proportionate preparation.
What the behavioral round is actually testing
The behavioral round is not a formality. I’ve seen technically excellent candidates not receive offers because of how they talked about a previous team – specifically, blaming colleagues for a project outcome without any acknowledgment of their own role. Interviewers know that behavior is a preview. If a candidate badmouths a past manager freely in an interview, the hiring team tends to assume they’ll do the same in a future performance review.
Six to eight concrete stories is the right preparation level. Cover: a time you navigated a technical disagreement, a project that failed and what you did after, a time you delivered feedback that was hard to give, a time you unblocked someone else. Keep each story to under two minutes. Interviewers who write scorecards often have to justify ratings with examples – give them the examples.
What actually changes outcomes
A June 2025 paper on AI-driven mock technical interviews (arXiv 2506.16542) found that 60% of participants reported reduced anxiety specifically because there was no human judgment in the loop. They also identified better articulation of their thought process as the main skill they built. That tracks with what I’ve observed: the candidates who improve fastest are the ones getting high volume of realistic reps, not the ones reading about interviews.
The pattern that produces better outcomes, based on what I’ve watched candidates do over several years of interviewing: simulate real conditions, not just review problems. Schedule mock sessions with someone who can interrupt you and ask clarifying questions. Force yourself to talk while you code. Get feedback specifically on communication, not just correctness.
A note from the LastRoundAI team
In sessions on LastRoundAI, we consistently see candidates freeze up in their first few mock interviews – not because the problems are too hard, but because talking while coding under observation is a skill nobody practices. By session four or five, that pattern usually reverses. The reps matter more than the prep material.
The one thing I’m less sure about: whether the specific interview format (whiteboard vs. take-home vs. pair-programming) actually predicts on-the-job performance better than the others. The research on this is thinner than you’d expect given how much money companies spend on hiring. My guess is that high-quality structured behavioral interviews probably have more predictive validity than algorithmic coding rounds, but I haven’t seen a study I fully trust on this for software roles specifically.
What I do know is that the candidates who pass at high rates aren’t usually the strongest coders in the room. They’re the ones who’ve made the discomfort of being watched feel familiar enough that it stops being the main obstacle.
Related reading: how to structure coding interview practice sessions and what interviewers actually look for in system design rounds.
