Hiring

I ended a recent essay by dodging a question. This is me coming back to it, still without an answer, because the question got sharper the longer I looked at my own org chart.

The consensus move in AI-era hiring is to buy judgment fully formed. Hire seniors only. Why pay someone to learn on work the tooling already does?

Forty-plus candidates screened, four engineers hired, and a taxonomy I wasn't expecting to find. Making AI fluency a hard requirement filtered the applicant pool, but the more interesting result was the spectrum it exposed among everyone who made it through: non-users, reluctant adopters who reach for it on boilerplate and tests, green users who accept whatever the tool suggests, collaborators who push back on it, and vibe coders who can ship a demo but can't explain the architecture underneath it.

The gap that matters sits between the third stratum and the fourth, and it's nearly invisible on a resume. Both groups produce working code. One follows the AI, the other leads it. A take-home that required AI usage, plus a presentation on the process rather than the output, was the only thing that reliably told them apart.

The interview industrial complex broke in two directions. The FAANGs over-optimized until leetcode prep became its own industry; startups never built the rigor in the first place and hired for velocity. Both missed the same thing. Code was never the hard part. Knowing what to build and why was always the hard part.

I started as the engineering department at a startup and hired every person who came after, and I filtered for how people reason through ambiguity rather than how they perform while someone watches them type. Some people thought that wasn't rigorous enough. Then AI commoditized code production and the startup math got brutal: one thinker with AI tools does what used to take a thinker plus two implementers. Here's what I hire for now, and how the interviews changed.