The live coding test hasn't changed much in fifteen years. An interviewer, a problem, a timer, a screen share, no external tools. The format was designed around a version of engineering work that made sense in 2012 and has quietly been replaced. Most interview processes haven't noticed.
A modern engineer in 2026 — the engineer you're probably hoping to hire — does almost none of their best work in the conditions a live coding test recreates. The mismatch is bigger than just "AI is allowed now." The shape of the job has shifted along several axes at once.
What modern engineering work actually looks like
A normal productive day for a working engineer now looks something like this. They read a ticket that's only partially specified. They spend 20 minutes figuring out what the real problem is, often by talking to someone on Slack or reading through previous discussion. They open an editor, pull up documentation in a side panel, and probably open an AI assistant. They write a first draft of the change in collaboration with that assistant — not by pasting prompts and accepting outputs, but by thinking through the problem with the tool in the room. They push a commit, get feedback, iterate. Much of this is asynchronous.
None of that resembles a 45-minute timed whiteboard problem.
The parts of the old format that worked in 2012 worked because the job itself was closer to the format. More of the daily work was solo coding against a problem the engineer fully understood, in a language they'd been writing in for years, on a machine that had about as many external resources as a locked-down interview laptop. That version of the job still exists in a few places. It's not the one most hiring teams are hiring into.
Where the mismatch actually hurts you
The mismatch wouldn't matter if it just produced awkwardness. It matters because it changes who passes.
A strong modern engineer spends most of their cognitive effort on framing, evaluation, and integration: framing the ambiguous problem, evaluating what the tools around them produce, integrating the result into the existing codebase. A live coding test removes all three. The problem is framed for them by the interviewer. Evaluation doesn't matter because the scoring rubric is binary. And there's no existing codebase to integrate into.
What's left is raw algorithmic recall and typing speed. The correlation between those skills and on-the-job performance was always thin, and it's thinner now. A senior engineer who's spent three years shipping production systems at a mid-sized company can genuinely struggle on a LeetCode-style live round, not because they've lost the ability to reason but because the muscles the format exercises have atrophied from disuse. Their engineering is fine; the format just isn't measuring engineering.
Meanwhile, candidates who are actively grinding interview practice problems will perform visibly better without necessarily being better hires. The format rewards interview preparation more than job readiness. That's been true for a while; in 2026 it's just become harder to defend.
The quiet self-selection problem
The part that's easy to overlook: some of the strongest modern engineers are quietly opting out of interview processes that lead with live coding. They read the job description, see a "live coding round with no external resources" in the steps, and decide the team hasn't updated its thinking. That isn't sour grapes — it's a reasonable inference about what the team believes the job requires.
You never see the applications you didn't get. The absence is the quietest failure mode in any hiring process, and live coding is one of the clearest triggers for it right now.
What replaces it
The format that holds up better is the one that lets the candidate work the way they'd actually work. Give them a realistic problem, enough time that framing and evaluation matter, and the tools they'd reach for on the job. Collect the artefact and the reasoning. Read it before the live round. Make the live round a conversation about the thinking, not a performance of typing under surveillance.
Live coding rewards composure more than it rewards engineering. Composure is a useful skill, but it's not the one you're supposedly testing for. Testing for the actual thing is both harder to design and easier to defend to candidates who can tell the difference.
At CriticCode we build the async part of this flow by default — a realistic challenge, AI in the room, structured prompts that catch reasoning, and a transcript for the follow-up. The live round doesn't go away; it gets better, because the interviewer walks in knowing what the candidate actually did.
The practical test
Run your current live coding round through this question: if this round were removed from the process, would the hires get worse? Most teams who try this exercise honestly find that the round adds noise, not signal — the hires they regret usually passed live coding and failed elsewhere. Dropping the round, or replacing it with a better-shaped async round, tends to produce the same hires and a shorter interview process. That's an unusual thing to be able to say about any part of hiring.