The Coding Interview Inverted

Most software candidates now write code with an assistant. In response, interviews still force them to type alone for an hour. That measures a skill they rarely use on the job. The fashionable fix, “just do more system design,” is only half right.

Start with why the old round broke: three forces hit it at once. First, assistants reached the point where production code is more often reviewed than written from scratch. Second, interview prep got arbitraged. The same models that write your candidates’ code solve screening puzzles in seconds.

Gergely Orosz at The Pragmatic Engineer tracked the fallout. Interviewers suspect widespread AI cheating in remote rounds. Take-homes went low-signal because models complete them unsupervised. The old test was always easy to game with memorization, the exact skill models made cheap.

The companies with the most hiring data did not delete coding from the loop. They inverted it. Meta added an AI-enabled coding round that replaced one of its algorithm sessions. The setup: a multi-file codebase with an AI assistant. Grading checks how candidates clarify needs, read new code, debug, and explain choices.

Google is piloting a code comprehension round, per internal documents reported by Business Insider. Candidates use an approved assistant to read, debug, and optimize an existing codebase. Canva goes further: it insists candidates use AI in its technical interviews and grades whether they can spot and fix what the model gets wrong.

Look at what those rubrics have in common. Nobody tests if you can write syntax. Everyone tests if you can judge it.

The coding interview did not die; it inverted. The candidate used to write while the interviewer reviewed. Now the model writes and the candidate reviews. Your interview should look like the job: read this, find what is wrong with it, and defend your call.

The loop I would run instead

Two judgment sessions that fail in different ways, replacing the standard one-coding-plus-one-architecture stack.

Session one: greenfield, forward. Design a system from a fuzzy prompt, but do not let it be a recital. The prep industry has made “design a URL shortener” as easy to memorize as any coding puzzle. So the interviewer’s job is to keep changing the ground. Halve the budget, triple the write volume, kill the availability zone, make the data residency German. Rehearsed answers run out; judgment does not, so grade the questions they ask before they draw anything.

Session two: brownfield, backward. Real code on the table. An existing system with history and scar tissue, and a task: evolve it, or rescue it. Include an agent-written diff and ask them to review it for real. This is where code literacy lives now. It also covers the objection that dropping the typing round means hiring people who cannot read.

Charity Majors has written that you cannot trust generated code. Stepping through it line by line is now part of the job. This session tests candidates at exactly that station. A variant I like, which Airbnb runs as a dedicated round: the candidate presents the architecture of something they built. Then they defend its decisions. Artifacts are hard to bluff.

Where judgment rounds fail

Architecture rounds are bluffable. They reward talkers, and a big industry preps people for them. Running two judgment sessions risks double-weighting a gameable format.

Three constraints prevent that failure:

1. Decorrelate the sessions. Forward design and backward review fail in different ways. A candidate must bluff twice in opposite directions.

2. Anchor to an artifact. Review a real system with history, theirs or yours. Specific production details are expensive to fake.

3. Grade under pushback. A memorized design survives the first constraint change, rarely the third.

What do you lose by never watching someone write code from scratch? A floor check on raw syntax speed, which matters most for junior hires. If that worries you, fold a short pair-with-an-agent exercise into session two. Grade how they direct it; that is the skill that matters now anyway.

What you gain is two hours on the layer that survived: decomposition, tradeoffs, and failure planning. Tradeoff analysis and boundary testing cannot be automated by typing faster. They require verified human judgment. And you test the ability to look at confident, plausible, machine-written work and say “this is wrong, and here is why.”

Want a shared language for grading how candidates work with agents? I keep a six-level ladder for exactly that.

Within a few years, reviewing code you did not write will be the primary technical screen at every serious software company. Because reviewing code is the actual job.