You're not hiring a developer. You're hiring an editor.

The problem

The job changed. The hiring process is in denial.

A candidate aces your technical screen. Writes clean code, communicates well, you hire them. Six months later they’re approving agent output they don’t understand, can’t explain, and wouldn’t catch if it was wrong.

You didn’t hire a bad engineer. You hired for a job that no longer exists.

The work now is judgment — reading generated code skeptically, cutting what doesn’t belong, explaining not just what you built but what you chose not to build and why. That’s editorial instinct. Your interview isn’t screening for it. In most cases, it’s screening against it.

The trap

Your filter works perfectly. It’s filtering for the wrong thing.

The standard technical screen asks one question: can this person produce output? Reasonable question. 2019 called, it wants its hiring criteria back.

Agents produce output. Cheaply, quickly, at 3am without complaining about sprint planning. What they don’t do is decide whether the output is right, whether the abstraction holds, or whether the whole thing should be thrown away and reconsidered.

The traits that make someone a great editor — pausing before writing, questioning the premise, asking what problem this actually solves — read as red flags in a live coding screen. You’ve been filtering them out for years. Some of them are working somewhere else right now, making better decisions than your team.

The toolkit

Three interview moves that screen for editorial judgment

Don’t add these on top of your existing process. Replace something.

The deletion exercise. Hand them a working PR — passing tests, ready to merge — and tell them to cut it by 40%. Not refactor, cut. What they remove first tells you almost nothing. What they refuse to remove tells you everything.

The agent review. Run a feature through a coding agent. Functional, plausible, subtly wrong in two or three places. Ask them to review it like it came from a teammate. Most candidates catch the syntax issues and miss the architectural ones. A few find the thing that would have hurt you in production six months later. Hire those.

The rejected alternative. At the end of any design discussion, ask: “What’s the approach you decided against, and why?” One type of candidate lists options. Another type explains a tradeoff. You’ll know which one you’re getting within about fifteen seconds.

Pick two of these. Three if your recruiter has forgiven you for the last process overhaul.

One last thing

The candidate who looks slow is the one you want.

They ask questions before touching the keyboard, want to understand constraints before writing anything, and every traditional signal says underperforming. Every traditional signal is wrong.

Output velocity is a commodity now. A $20 subscription has it. What isn’t a commodity is the judgment to know what’s worth keeping, what needs cutting, and what should never have been written in the first place.

You’re not hiring someone to type. You’re hiring someone to decide, and your interview should probably reflect that.