Forty-five minutes, a shared editor, a stranger watching every keystroke and a problem you've never seen before: reverse a linked list, find the subarray with the largest sum. No documentation, no search, sometimes not even autocomplete. And on top of that you're asked to "think out loud". That's live coding, and in many hiring processes it's still the moment that decides everything.
I'm against it. Not because it's hard, but because it measures the wrong thing. I've done interviews on both sides of the table, and in another article I wrote about how I'd change technical questions in the AI era. Here I'll get straight to the point: why classic live coding doesn't work, what I grant to those who defend it and what I'd do instead.
Which live coding I mean
A distinction first. I'm against the timed algorithm exercise, watched live, without tools, on a problem unrelated to the job, whose outcome alone decides whether you move on. I'm not against working together with a candidate on a realistic task, with documentation and tools at hand, to see how they reason. They look like the same thing, but they aren't: I'll come back to it at the end.
It measures stress, not skill
It's not just a feeling. In 2020, researchers from North Carolina State University and Microsoft published a controlled study with 48 computer science students: half solved a problem on a whiteboard in front of an interviewer, half alone, in a private room. Being watched cut performance by more than half. The authors point out that the format bears an uncanny resemblance to the Trier Social Stress Test, a protocol used in psychology precisely to induce stress.
The study is small and was done with students, so I don't take it as law. But it confirms what anyone who has been through an interview knows well: under observation, working memory shrinks, you lose the thread, you make trivial mistakes you would never make under normal conditions. The result doesn't answer the question "can they code?", but a different one: "how well do they code while someone judges them live?". And in real work that situation doesn't exist.
Real work looks nothing like live coding
| In live coding | In real work |
|---|---|
| 45 minutes for a problem you've never seen | Hours or days, with time to understand the problem |
| No documentation or search | Documentation, search and examples always open |
| AI assistant forbidden | AI assistant in the editor, every day |
| A stranger watching every keystroke | Focus, with the review coming afterwards |
| Textbook algorithms | Reading existing code, integrating APIs, fixing bugs |
| What counts is reaching a solution | What counts is readability, tests and long-term maintenance |
Whoever gets hired will spend their days reading code written by others, choosing a library, figuring out why a test fails only in CI. Judging them on their ability to implement an algorithm from memory, in half an hour and under someone's gaze, means measuring a skill they'll rarely use, in conditions they'll never work in.
It rewards people who train for the format, not people who work well
Algorithmic live coding has become a discipline of its own, with platforms, courses and hundreds of exercises to repeat until you recognize them at a glance. Those with weeks to spare for training arrive prepared. Those who work full time, have a family or simply spend their time building real software instead of solving puzzles start at a disadvantage. In the end, the interview mostly selects for interview preparation.
And it systematically penalizes some people: those who suffer from anxiety, those who are neurodivergent, those who interview in a language that isn't their own and have to think out loud while translating in their head. None of these things says anything about how that person will write code in a team.
It costs the company too
People usually talk about the candidate, much less about the company. Every false negative is a capable developer rejected because they froze for ten minutes. And experienced people with other options often avoid processes with live coding altogether: the company never even sees those candidates.
There's also a less visible effect. Watching someone under pressure, the interviewer ends up judging confidence more than substance: whoever talks fluently seems better than whoever stays quiet and thinks. It's a bias present in every interview, but this format amplifies it.
What I grant to those who defend it
- Checking that someone can really code is legitimate. A CV can be inflated, and today even a take-home exercise can be solved by an AI.
- Long take-home assignments have a real cost: hours of unpaid work, often out of proportion to the role.
- Live coding is cheap and uniform: the same exercise for everyone, one hour and done.
These are serious objections. But the answer to "we need to verify skills" can't be a format that measures them badly. What's needed is a format that checks the same thing without the part that distorts the result.
What I'd do instead
- A code review of real code. A plausible snippet, with a bug and a few questionable choices, to be reviewed as if it were a colleague's pull request. You immediately see who understands the code, and nobody has to write under dictation.
- The candidate's own project. A repository, a previous job, a side project: "walk me through this choice", "what would you change today?". A real experience holds up to five follow-up questions; a memorized story collapses at the second.
- A short take-home task, followed by a discussion. Two or three hours at most, paid if possible, then a conversation where the candidate explains and modifies their own solution. If an AI wrote it and they don't understand it, a few minutes of questions are enough to notice.
- Pair programming on a realistic task. If you really want to see someone write code: a small real repository, documentation and AI allowed, no stopwatch on the result. The interviewer works with the candidate instead of watching over them.
- A debugging session. A failing test and the time to understand why: it's the closest thing to a normal working day.
If live coding stays, at least do it this way
I understand that not every company will change its process overnight. If live coding stays, a few minimum rules make it less unfair:
- communicate the format, duration and language in advance;
- choose a problem related to the job, not a textbook brain teaser;
- allow documentation and search, as on any normal day;
- evaluate the reasoning, not just the final result;
- give the candidate a few minutes to read and think in silence before asking them to talk.
And if you're the candidate
You can politely ask for an alternative: a code review, a discussion of one of your projects, a short take-home task. Not every company will agree, but asking costs nothing. And the answer already tells you a lot about how they work: a company that can't explain why it uses a certain format has probably never asked itself.
In short
I'm against classic live coding because it measures how a person handles the stress of being watched, not how they work. It's a bad deal for the candidate and for the company too, which rejects capable people and selects those who trained for the format. Alternatives exist, and they check the same thing, whether a person can code, without distorting the result. I've collected more ideas on how to renew technical interviews in this article, and if you're preparing for an interview you'll find technical questions organized by level in the guide to the 25 frontend/Angular interview questions.
