One career, self-reported.
A live round can't tell a weak engineer from one who freezes on camera.
Live coding looks like the fastest way to qualify a candidate, but it samples thinking under a clock and an observer, and it gives a confident verdict either way. An assignment followed by a design review sees the work and the reasons behind it. The unpaid hours are not the flaw in that trade. They are how both sides show they mean it.
- An easy sliding-window problem failed live, and the same pattern taken apart later
- A PHP console RPG with no framework, built from the autoloader up
- Why an LLM can write the submission but cannot defend it in the review call
- Four changes that qualify candidates fast and with fewer wrong answers
Live coding measures one hour of a candidate’s thinking. The wrong one.
I failed an easy sliding-window problem in a live coding round. On this site, I have taken the same pattern apart down to cycles per character.
Same person. Same kind of problem. Opposite verdicts.
The difference was not skill. In the live round I had a string problem I had seen thirty seconds earlier, a clock, and a stranger watching every keystroke. Two pointers, a moving window, nothing exotic. I could not get to the solution under that pressure. Given time and quiet, I wrote an article about it.1
If you recruit engineers, that gap is your problem, not only mine. The live round gave a confident answer. It was the wrong one.
One hour, one sample
The case for live coding is usually put in one sentence: it shows how a candidate really thinks. Take the sentence literally. It commits you to believing that the thinking the job needs happens in forty-five minutes, on a problem the candidate has never seen, with someone watching.
The job never asks for that. A real task arrives, you read it, you go away. You look at the data, sketch two approaches, throw one out. A day later you come back with a design and the reasons behind it, and someone senior pokes holes in it.
The live round times the one hour of thinking the job never asks for. Photo by William Warby on Unsplash.
A live round measures two things at once and cannot separate them: whether you can solve the problem, and whether you can perform on demand. When a candidate fails, it records a no for both. For some strong engineers the second one is what failed, and the round has no column for that.
That makes it fast. It does not make it accurate. And a false negative is not free. It is a good engineer sent back into the market, and a search that starts again from the top.
The RPG with no framework
One assignment I still remember looked, at first, like a toy. A mini RPG in PHP. A console app, no interface. A hero and monsters to battle. Health, mana, attack, defence, skills.
Then the constraint: no frameworks.
That one line changed the task. The game was not the point. The point was to build the small framework under it myself, from the autoloader up to the features, so the code could be debugged, maintained, extended and built on without pain. It was a test of architecture disguised as a game.
Every decision in it was one I would have to defend. Where does damage get calculated: in the attacker, in the skill, or in the target’s defence? Is a monster a subclass of a hero, or do both share a set of stats? How do you add a new skill without touching the battle loop? A sketch of the kind of answer that brief invites:
<?php
// One place decides how classes are found. Nothing else calls require.
spl_autoload_register(function (string $class): void {
$path = __DIR__ . '/src/' . str_replace('\\', '/', $class) . '.php';
if (is_file($path)) {
require $path;
}
});
// A skill is a strategy: the battle loop never needs to know which one it runs.
interface Skill
{
public function manaCost(): int;
public function apply(Unit $caster, Unit $target): void;
}
final class Fireball implements Skill
{
public function manaCost(): int { return 12; }
public function apply(Unit $caster, Unit $target): void
{
// The target decides how much of the hit its defence absorbs.
$target->takeDamage(3 * $caster->stats()->attack);
}
}
None of that is hard. All of it is a choice. And a choice made alone, with time, is a choice you can explain.
Put the three usual steps side by side and the difference is what each one can see:
| Step | What it sees | Under what conditions |
|---|---|---|
| Live coding | recall and speed under pressure | a clock, an observer, a new problem |
| Take-home assignment | the work itself | the candidate’s own time, tools and pace |
| Review call on the assignment | the reasons behind the work | two sides looking at the same code |
The live round sees one thing, under the wrong conditions. The assignment and the call after it see the two things the job is made of: the work, and the ability to explain and defend it.
My own record
Over my career I have done about ten live coding rounds and three to five take-home assignments. The jobs I rate as my best all came through an assignment, followed by a call where we discussed the design decisions in it.
That is one person’s record, and I remember the good processes better than the bad ones, so read it as a direction, not a rate. But that is exactly the kind of error a live round cannot see. It is not an error across the population. It lives inside each candidate: the distance between how they work and how they perform when watched. For some people that distance is zero. For me it is the difference between failing a two-pointer problem and writing it up.
The conversation is the test
A submission read in silence and scored against a checklist throws away the best part of the assignment.
The value is in the call afterwards. Now both sides have the same code on the screen. The interviewer asks why skills are strategies and not methods on the hero. What breaks if there are fifty monster types. What the candidate would change with another week. A candidate who thought it through alone has answers, and better, has opinions about their own mistakes.
The review call: both sides looking at the same work, one of them explaining why. Photo by Kaleidico on Unsplash.
This is also the answer to the obvious 2026 objection: anyone can paste the brief into a model. They can. The model can write the code. It cannot sit in the call and defend its trade-offs for forty-five minutes, answer “why not the other way,” or explain what it would do differently. The conversation is the part that cannot be outsourced, which is why it is the test.
An hour is not enough to decide to hire someone. It is not enough to decide to join them either.
Yes, the hours are unpaid
The case against the take-home is real, and it deserves full strength. A six-hour brief costs the candidate an evening, sometimes a weekend, unpaid. Employed engineers with other offers are the most likely to skip it, so the pool that submits can tilt toward whoever had the time.
All of that is true. And it is the point.
A process built only from one-hour calls asks almost nothing from either side. The company decides to hire someone after a few hours of talking. The candidate decides to spend years of their life at a company after the same few hours. For a long time hiring has been tuned for the company’s speed. The assignment swings the pendulum back.
Lift one end and the other answers. A process where only one side moves is not in balance. Photo by engin akyurt on Unsplash.
It filters for commitment, in both directions. A candidate who will not spend an evening on the actual problem is telling you something about how much they want this job. And a candidate who does spend the evening learns more about the company than any call could tell them. The brief shows what the team values; the RPG brief asked for maintainable architecture before features, which says more about a team than a job ad does. A careless brief, or no serious review of the submission, tells the candidate something too.
Economists call this a costly signal: a claim is believable because it costs something to make.2 The hours are the cost. Without them, “I’m very interested in this role” is free to say.
So the bill is not waived. It is split. The candidate pays in hours, deliberately. The company owes those hours back, in a review call where someone has actually read the code.
The claim has limits. It does not cover a brief that takes a whole weekend, a brief that is unpaid production work in disguise, or a process that collects submissions and never discusses them. It also does not scale to high-volume junior hiring, where nobody can hold a review call for every applicant.
Qualifying fast, and right
If your job is to qualify a candidate fast, the assignment is not the slow option. It is the one with fewer wrong answers in it.
- Send a scoped assignment early, not after three rounds of calls. A few hours of focused work, stated plainly.
- Tell the candidate how it will be judged: in a conversation about the decisions, not by a checklist. They will prepare reasons, not polish.
- Hold the review call within days of the submission, with someone who read the code.
- Drop the separate live coding round, or turn it into reading and extending the candidate’s own submission together.
The difference between that call and that article was never sliding windows. It was time.
References
- A. Michael Spence, Job Market Signaling, The Quarterly Journal of Economics 87(3), 1973, pp. 355–374
Notes
Keep exploring
For the sliding-window problem measured properly, with hardware counters instead of a stopwatch, read Zero Milliseconds Is Not a Score. For another case where the number on the screen measured something other than what it claimed, read The Memory Hierarchy Doesn’t Break Where You Think It Does.
Hero photo: Vestfoldmuseene on Unsplash. Article photos: William Warby, Kaleidico and engin akyurt on Unsplash.
Footnotes
-
Zero Milliseconds Is Not a Score measures a sliding-window solution to Longest Substring Without Repeating Characters in Python and C with hardware counters. The live-round problem was an easy two-pointer string problem of the same family, not the same problem. ↩
-
Spence’s example is education: a degree works as a signal to employers because it costs more to earn for the people it screens out. The take-home version is looser. What the hours signal here is interest in this particular job, not general ability, and the signal runs both ways, because the company’s brief and review say as much about it as the submission says about the candidate. ↩