Stop asking candidates to write code. Ask them to review it.

Here is an interview format that tells you more in forty-five minutes than any whiteboard ever did. You hand the candidate a pull request: a few hundred lines, generated by a coding agent, tests included, CI green. The description is confident and well formatted. The code is clean, consistently named, sensibly commented. You ask one question: would you merge this? Then you watch. Some candidates skim for five minutes, find nothing structural to object to, and say it looks good. Others start pulling threads. Why does the retry wrap a POST that isn’t idempotent? Why does the new endpoint check the session but never the tenant? Why does the migration add a non-nullable column to a hot table? Same diff, same clock, completely different engineers.

That contrast is the biggest shift I’ve noticed in technical hiring this year. Companies are quietly moving the weight of the loop away from writing code and toward reviewing it: attention to detail, the ability to spot the issue that everything automated has already missed. Not because writing stopped mattering, but because it stopped discriminating. A model writes the linked-list reversal. A model does the take-home, and honestly, letting it do the take-home is fine; that’s the job now. What the model cannot do for the candidate is know which of its own outputs to distrust.

The whiteboard question stopped measuring anything

For twenty years the coding interview rested on one assumption: producing working code is scarce, so watching someone produce it under pressure tells you who they are. That assumption is gone. Generation is close to free, and the loops that still spend an hour watching a candidate type are measuring a skill their own team no longer bottlenecks on. The scarce thing moved. It moved to the moment after the code exists, when someone has to decide whether it ships.

The best loops I’ve seen don’t ban LLMs from the take-home; they assume them. What gets evaluated is everything the model didn’t write: the harness the candidate built to check the output, the tests that would catch a regression, the two paragraphs explaining what they didn’t trust and why. Then the onsite is a review session. That ordering is not a gimmick. It’s the production workflow, compressed into an interview.

LGTM was always a bet. Now it’s a bad one.

Approving with a one-word LGTM was never rigorous, but it used to be a reasonable bet. The author was a colleague who had context, a reputation, and skin in the game. Review was a second opinion on work someone had already sweated over, and the social contract did half the verifying. Every part of that bet is now off. The author is a model with no context beyond the prompt and nothing at stake. It produces plausible, test-passing code at a volume no team can absorb, which is the same verification bottleneck that swallowed the million-line Bun rewrite: the operative word in “unreviewed slop” was never slop.

There is a nastier wrinkle. Polish used to correlate with care. A tidy diff with good names and thorough comments usually meant a thorough author, so reviewers learned to read polish as a proxy for correctness. Generated code breaks the proxy: it is maximally polished by default, independent of whether it is right. The diff that double-charges a customer under a timeout retry reads exactly as well as the diff that doesn’t.

I’ve watched this fail in production more than once: a reviewed, approved, green-CI change that took the service down anyway, because the review was a scroll and a nod. The failure was never exotic. It was always something a trained reviewer catches in ninety seconds, sitting in plain sight in a diff nobody actually read.

What the trained eye actually sees

So what does the reviewer who catches it know that the one who scrolls past doesn’t? Not a checklist. A library. Years of incidents compress into a set of shapes that fire on sight, the way a chess player sees a fork without calculating. The reviewer isn’t reading the code line by line; they’re querying every way code like this has failed before, and generated code fails in recognizable families.

The third family is the killer, because it is invisible in the diff view by construction. The bug isn’t on any line the PR touches; it’s in the relationship between the new code and the system around it. A reviewer who has been paged for that class of failure checks for it reflexively. A reviewer who hasn’t approves a locally correct change and finds out at 2am what “locally” meant. That gap is experience, and it is the part of the job that is genuinely hard to replace: you can rent generation by the token, but you cannot rent a memory of your own outages.

Which raises the question the rest of this post hangs on: if review skill varies this much, what is it actually worth per day?

Reviews per day is the new velocity

Here’s the arithmetic nobody puts on a dashboard yet. When agents write the code, your feature velocity is not how fast anyone types. It is how many diffs get a real review per day, multiplied by how many defects that review actually catches. Throughput times catch rate. A reviewer who rubber-stamps sixty diffs a day looks phenomenally productive right up until the escaped bugs come due. A reviewer who grinds through a checklist catches plenty but drowns, and the backlog quietly becomes the bottleneck the static review queue always was. The trained eye is the only profile that wins on both axes, because pattern recognition is fast in a way deliberate checking is not.

Play with the load slider and the difference stops being abstract. At sixteen diffs a day the three reviewers look interchangeable. At fifty, the reflex has shipped a week of incident response into prod, the checklist has a backlog older than the sprint, and the trained eye is still clearing the queue with single-digit escapes. Same stream, same defects. The only variable is the eye.

How to interview for it

If you buy the argument, the loop almost designs itself. Take a real PR from your codebase, or generate one the way your team actually generates them, and seed it with three or four defects from the families above: realistic ones that have bitten you, not puzzle traps. Green CI, clean description. Then let the candidate work the way they would on the job - running the code, asking questions, using whatever tools they want. You’re not grading a defect scavenger hunt. You’re watching the process: what they check first, whether they run it or only read it, whether they ask what invariants the system expects, whether they separate “this blocks the merge” from “this is a nitpick.” A candidate who finds two real issues and asks sharp questions about a third beats one who leaves fifteen style comments.

The same design works inward. Review skill is trainable, which is what makes betting on it rational rather than nostalgic. Run your last three incidents backward: pull the diff that caused each one and let the team review it cold, knowing something is wrong but not what. Have reviewers state a hypothesis before opening a PR - “this touches billing, so I’m looking for retry and idempotency problems” - because a review with a hypothesis is a search, and a review without one is a scroll. The library the trained eye queries was built one incident at a time; you can build it deliberately instead of waiting to get paged.

The gap that compounds

Prompting is a commodity skill. Everyone on your team can ask an agent for a feature, and within a year every candidate you interview will have shipped something model-written. Filtering production-grade code out of plausible code is a different game entirely, and the market has started pricing the difference: the engineer who can do forty real reviews a day is worth more than the one who can generate four hundred diffs, because the diffs were never the constraint. Every week of agent-assisted shipping widens this gap. The teams that treat review as the core engineering skill - hire for it, train it, measure it - compound quality while everyone else compounds backlog.

The interview question of the last decade was “can you build it?” The models answered that one on everyone’s behalf. The question that’s left is the one that was always underneath it: do you know what you’re looking at? Hire for that.