How to Hire an Engineer Who Can Out-Reason the Agent

The skill you used to interview for is now the cheapest thing on your team. Here's the one question that separates an engineer who thinks from one who just types.

You’re still grading engineers on the one thing your agents already do better than all of them.

I saw the alternative in an interview this year. The best engineer I’d met in months barely touched the keyboard. We had a whiteboard, a problem, and forty-five minutes, and he spent most of it not typing. He’d sketch an approach, stop, and explain why he wouldn’t take it. Then he’d take it anyway, but only after ruling out the alternatives out loud.

I kept pushing. Why that data structure? Why not the simpler one? What breaks at scale? He never hit the bottom. Every “why not” had another floor underneath it, and each floor was more specific than the last. I’d made up my mind before he left the room.

A year ago, an interview like that would have bothered me. Where was the code? But the code is the part I’ve stopped caring about, because it’s the part the machine now does for free.

The Question That Died

For fifteen years, the interview was “how would you build this?” We asked because, back then, being able to produce the how was a reliable signal that you understood the why. You couldn’t fake your way through implementing a rate limiter or a job queue. The typing was proof of the thinking.

The agent broke that link.

Now anyone can produce a fluent, confident how. The agent hands it over in thirty seconds, complete with tests and a tidy explanation. The candidate who “solves” your coding screen might be brilliant, or might be a competent prompt operator who’s never once questioned what the machine gave them. Your interview can’t tell the difference anymore, because you’re grading the part the agent already does.

Coding was never the job. Coding was the proxy. Agents stripped the proxy away and left the real thing standing there, exposed: judgment. What to build, what to trust, what to throw away, when to stop.

So you have to test for judgment directly. And judgment shows up in exactly one place, the answer to why this, and why not the alternative?

What Depth Actually Looks Like

This is the part that stays abstract in most hiring advice, so let me make it concrete. Here’s the difference between an engineer who runs the agent and one who supervises it. Same three tasks. Watch the reasoning, not the output.

The migration. The agent writes a database migration that adds a standard index on a 40-million-row table. The shallow engineer reads it, sees green tests, ships it. The one you want to hire stops: “Why a full B-tree here? This column is 95% null. A partial index on the non-null rows is a fraction of the size, and the query planner still uses it for the lookup we care about. And why is this running synchronously? A plain CREATE INDEX locks writes on 40 million rows for the duration. In production that’s a stall. It has to be CREATE INDEX CONCURRENTLY. The agent didn’t know the shape of the table. I do.” That’s not knowledge of Postgres. That’s the reflex to interrogate a confident answer.

The dashboard. The task is “make the dashboard faster.” The agent’s instinct, and the junior’s, is to add caching everywhere. The engineer with judgment asks a different question first: “Faster for whom? The p50 is 200 milliseconds. The p99 is 8 seconds. That 8 seconds is one N+1 query in the org-admin view that maybe 2% of users ever load. If I cache the whole dashboard, I’ve added invalidation bugs for the 98% who were already fast, to fix a problem for the 2%. I’d kill the N+1 and cache nothing.” Naming why not the obvious move is the entire signal.

The architecture. The agent proposes full event sourcing for a new feature: an event store as the source of truth, read models rebuilt as projections off the event log, the whole replay apparatus. The impressive-sounding option. The engineer worth hiring argues against it: “Why event sourcing? We have one write path and nobody’s asked to reconstruct past state or replay history. That’s three weeks standing up an event store and a projection layer, plus a class of eventual-consistency bugs we’d own forever, for a problem we don’t have. If all we actually want is a record of how a status changed over time, a plain status-history table gives us that today. I’d reach for the real thing the day we genuinely need to rebuild state from events. That day isn’t on the roadmap.” Critical thinking is often the discipline to talk yourself out of the more impressive answer.

Notice what all three have in common. The candidate isn’t demonstrating that they can build. They’re demonstrating that they can choose, and defend the choice against the roads not taken. That’s the scarce thing now.

The Fifth “Why Not”

The real test isn’t the first answer. It’s the fifth.

Anyone can give you one reason. Ask “why not the alternative?” once and most candidates have something. Ask it again. And again. The prompt operator runs out of road by the second question and falls back on “it’s best practice” or “that’s the standard approach.” The engineer who thinks keeps producing reasons, each more specific, until they hit a genuine tradeoff and name it: “Below about a million rows I’d actually do the opposite. The index maintenance isn’t worth it at that size.”

That moment, where they volunteer the condition under which they’d reverse their own decision, is the hire. It means the decision was reasoned, not remembered.

I Learned This the Expensive Way

I didn’t always screen like this. At TinyWhale, the startup I co-founded before it was acquired, we went all in from day one. Hired five developers immediately and built at full speed. We’d hired for the old signal: could they build? They could. They built fast. That turned out to be the problem, not the solution.

By month three we’d cut back to two.

Not because the other three were bad engineers. Because we’d assembled a team optimized for output, and output was the one thing we didn’t actually need more of. We were burning capital building features nobody had asked for, at high speed, because nobody in the room, myself first, had stopped to ask whether we should be building them at all. The correction wasn’t just a smaller team. It was a different way of working: build alongside customers instead of ahead of them, and treat the question “should we?” as more valuable than the answer to “can we?” That shift is the reason the company survived long enough to work.

I was hiring for horsepower when the scarce thing was judgment. The agent era just makes that mistake faster and more expensive, because horsepower is now free and judgment is the only thing you’re actually paying for.

Hire the Bar, Not the Body Count

If you’re a founder about to make your next technical hire, this is the shift that matters: you are no longer buying output. Output is a commodity your existing engineers can generate at ten times the speed they could two years ago. You’re buying the judgment to point that output at the right target and catch it when it’s confidently wrong.

That changes the math on team size. Three engineers who out-reason the agent will out-ship twelve who out-type each other, and they’ll do it with fewer bugs in production, because someone was actually interrogating what got shipped. The bar you hold in the interview is the team you end up with. Hold it high on the wrong thing, and you’ll hire a room full of people who can all ask the machine the same question and none of whom can tell when it lied.

So change the interview. Drop “how would you build this?” Hand the candidate the agent’s answer to a real problem, and ask: why did it do it this way, and why not the alternative? Then keep asking “why not?” until one of you hits the bottom.

If they hit the bottom before you do, keep interviewing. If you do, you’ve found your hire.

I’m putting together the full version of this: the exact “why not the alternative?” question set I use, the follow-ups that separate reasoning from recitation, and the answers that should make you nervous. If you want the agent-era screening guide when it’s ready, subscribe and I’ll send it your way.