The PR I Hand Every Candidate Now

Three years ago I gave a candidate a take-home: build a rate limiter, ship it in 48 hours. She nailed it — clean interface, sensible tests, a design doc nobody asked for. We hired her. Week one, she reviewed a PR our agent had generated to add a caching layer in front of that same rate limiter. Tests green, CI green, diff looked reasonable. She approved it in four minutes. The cache key didn't include the tenant ID. Two tenants started sharing rate-limit state, and one enterprise customer's traffic spike throttled everyone else on the shared cache for about twenty minutes before someone noticed the pattern in the logs. She could still write a rate limiter from scratch. What she couldn't do was doubt one she hadn't written herself. That gap is the whole interview now.

What I actually hand candidates

I stopped asking people to write code in interviews about a year ago. Now I hand them a PR my agent generated — usually Claude Code or Cursor against a small internal service — that passes CI cleanly and reads like something a competent engineer would ship. Somewhere in it is a bug that only shows up under a condition the tests don't cover: a cache key missing a scoping field, a retry that isn't idempotent, a date comparison that's off by one timezone, a lock released in the wrong order under a specific race. I say, "This merged an hour ago. Walk me through it like you're the second reviewer." Then I shut up and watch the order they read things in — diff first or call site first, do they ask what the function is even for before they ask if it's correct, do they run anything, do they get suspicious of the parts that look a little too tidy.

Two reactions, same PR

Most candidates split into two clean groups within the first three minutes, and that split predicts more about their first quarter than anything else I've tried. Group one treats the PR as a puzzle to close out: they find something plausible to tweak, propose a fix, and reach for "ship it" — because the code compiles, the tests pass, and looking competent means moving fast. Group two stalls somewhere unexpected and asks a question that isn't anywhere in the diff: "wait, why does this function exist — what was here before the agent touched it?" That question is the whole signal. It means they're not evaluating the patch, they're evaluating whether the patch should exist at all. Much rarer move.

Why this is the scarce skill now

For twenty years, hiring signal and typing speed tracked each other closely — the person who could produce a working rate limiter in 48 hours was usually also the person with good judgment under pressure, because both drew on the same fluency. Agents broke that correlation. Typing code is nearly free now; anyone on the team, me included, can generate a plausible PR for almost anything in a few minutes. What didn't get cheaper is deciding whether the output deserves to exist. The bottleneck moved from "can you produce this" to "do you trust what got produced" — and that second thing never shows up in a take-home, because a take-home is 100% self-authored. There's nothing to distrust. You need to hand someone an artifact they didn't write and watch what their suspicion does.

Isn't this just code review?

Every eng org already does code review, so this is the objection I get most, and I don't think it holds. Reviewing for style is pattern-matching against a rubric you already carry — naming, structure, does it follow the codebase's conventions. It's a confidence-preserving activity: you're checking a person's work against norms you already trust. Distrusting a confident-wrong artifact is the opposite move. It means treating a clean, tested, conventionally-styled diff as guilty until proven innocent, precisely because you know the author — an agent — has no skin in the game and no shame about being wrong. Most review rounds hand candidates code from a "teammate," which quietly signals assume good faith. Mine hands them code with CI green and zero social cover, which is the actual condition they'll be reviewing agent output under six months from now.

Same instinct, different surface

I weight three other things in the loop, and I used to treat them as separate competencies before I noticed they're all downstream of the same reflex. Whether someone runs several agents on parallel branches and can tell you, without checking, which one is probably wrong before they've read either diff — that's distrust applied ahead of time instead of after the fact. Whether they talk about their agents the way a manager talks about a report — "I don't let it touch the migration path unsandboxed, it got overconfident there last week" — that's distrust baked into how they delegate, not just how they review. And whether they can tell you about a time an agent's confident wrong answer sent them down a bad path for twenty minutes before they caught it — because if they can't produce that story, it usually means they've never pushed back hard enough on an agent to get burned, which means the reflex isn't built yet. None of these are separate hiring criteria. They're one muscle, tested from three angles, so a candidate who fakes it on the PR round can't also fake it three more times.

What to hand your next candidate

Steal the mechanic, not my specific bug. Take a real agent-generated PR your team merged in the last month — you have one, everyone does now — find the edge case your tests happened not to cover, and hand it over cold: "this merged an hour ago, review it." Then ask exactly one question while they read: "what would make you NOT merge this?" Candidates who can only answer in terms of style or tests are still auditioning for the old job. The ones worth hiring will start interrogating why the code exists at all before they've finished reading it.