Home / why you keep failing the live coding round

Live coding round

Why you keep failing the live coding round

If you know the material but keep getting rejected after the live round, the problem is usually behavior under observation, not knowledge. These are the patterns that cause the rejection and how to break them.

The behaviors that fail you

The most common one is going quiet: the interviewer cannot score reasoning they cannot hear. Others are jumping to code without clarifying the requirement, over-engineering a simple task, freezing instead of narrating a recovery, ignoring edge cases, and never verifying the result. Each reads as a lack of the composure expected at senior level.

How to fix them

Practice narrating on every rep until it is automatic, and rehearse a scripted first five minutes so clarifying and planning happen without thinking. Build the smallest correct version first, then improve it out loud. Treat a stall as a chance to show recovery, not a failure, and always leave a minute to test.

What the rejection email is not telling you

We decided not to move forward almost never means your code was wrong. In the debriefs behind those emails, the phrases I have actually heard are: hard to follow, needed a lot of steering, did not check their work, got defensive on the pushback. Every one of those is a process observation, not a knowledge gap. This matters because it changes what you practice. Another hundred algorithm reps will not fix hard to follow. Recording yourself solving one Codable task while narrating, then listening back, will. Most engineers who keep failing this round have never once heard what they sound like under observation. The gap is usually audible within two minutes of the recording.

The 5 failure patterns, with the moment they happen

Each of these has a specific trigger moment. Knowing the moment is how you catch yourself live.

• Going silent. Trigger: the first unexpected compiler error. You dive in to fix it privately and surface three minutes later with a lost interviewer.
• Skipping clarification. Trigger: recognizing the task. You have parsed JSON a hundred times, so you skip the questions and miss that this payload has malformed elements on purpose.
• Over-engineering. Trigger: wanting to look senior. The protocol and generics arrive before the working function does, and time runs out mid abstraction.
• Fighting the hint. Trigger: the interviewer nudges you toward a different approach. You defend yours for four minutes. The nudge was the test.
• No verification. Trigger: relief at compiling. It builds, so you declare it done without running the empty input case that was the entire point of the task.

The trap behind the hint

The fourth pattern deserves its own section because it is the least understood. When an interviewer says have you considered doing this with an actor, or what if the array is empty, they are not making conversation. They are handing you points. In the rounds I run, the hint is scripted, and the scorecard has a line for how the candidate uses feedback. The obvious response, explaining why your current approach is fine, walks directly into that line. The response that scores: that would handle the race I have not dealt with, let me take it. Ten seconds, and the feedback line flips from negative to positive. Candidates who keep failing usually treat every hint as a criticism to survive rather than a gift to accept.

A two week repair plan

Week one is diagnosis. Do three timed reps of standard tasks, a Codable decode with bad data, an async fetch with caching, a debounced search, and record every one. Listen for the five patterns above and write down which ones are yours. Most people have two. Week two is targeted repair. If you go silent, practice narrating fixes for deliberately broken code. If you skip clarification, script your opening questions and read them from a card until they are automatic. If you never verify, end every rep by writing one XCTest before you are allowed to stop. Then do two full mock rounds with another engineer providing the interruption. This is boring, mechanical work. It is also the difference between knowing the material and passing the round, which your rejection history has already shown are separate skills.

One more constraint for the mocks: have your partner interrupt with a scripted requirement change at the 20 minute mark, every time. The interruption is the part of the real round you cannot rehearse alone, and it is the moment where two of the five patterns, fighting the hint and going silent, most often fire. Practicing the absorb, restate, and adjust sequence until it is boring is the highest leverage rep in the whole plan.