Hey everyone, Neil here. You're reading High-Signal Hiring. Hiring systems from 20+ years of global recruitment experience and 500+ technical hires. Zero noise and instantly actionable.
Last week, in Issue #27, I made the case for the domain switcher: That the engineer worth hiring is often the one who hasn't worked in your industry, because AI has made domain context cheap to acquire.
This week, a related shift that most founders are getting wrong in the interview room. Your engineers are using AI to write code. That isn't the problem, and trying to police it is a waste of everyone's time. The problem is hiring someone who ships code they can't explain.
You'll learn why the hiring bar has moved from authorship to ownership, why it's the production risk that stays hidden until it costs you, and how to redesign your interview to test for it this week.
Not a subscriber yet? Sign up here
| The bar moved from writing to owning
For twenty years the core interview question was some version of "can this person produce the code."
It made sense, because producing working code was hard and slow, so the ability to do it told you a lot (and had value).
That signal has collapsed. When a candidate can generate a clean-looking solution to your take-home in the time it takes to read the brief, watching them produce code tells you almost nothing. What you need to know is whether they understand what came out, and whether they could fix it when it breaks.
That is a different question, and most interview loops still aren't asking it. BairesDev's 2026 survey of more than 1,500 developers across 77 countries found that only 16% of senior engineers think their juniors fully understand the AI-generated code they submit.
Most of what's going into production is only half understood by the person whose name is on the commit, and the interview never tested for the half that's missing. Screening for whether someone used AI misses the target. What you want to know is whether they can own what it produces.
| Why this is the risk that bites you later
The damage from this kind of hire doesn't show at interview. It shows six weeks in, when something breaks and nobody on the team can explain why the code was written the way it was.
Gergely Orosz at The Pragmatic Engineer framed the underlying problem well, and his 2026 analysis of AI's impact on engineers is worth reading alongside this issue. His core point is that far more code is entering production while human review capacity has stayed flat. The volume went up and the understanding didn't. That gap is widening at almost every company using these tools at scale, and it's where your next wave of expensive, hard-to-trace bugs will come from.
When you hire someone who can generate but not defend, you're adding to that gap. You're putting more code into your system that nobody truly owns. For an early-stage company with no QA team and no time to spare, that isn't a minor quality issue. It's the thing that stalls you when you can least afford it.
| What ownership looks like
Ownership doesn't mean writing every line yourself. It means being able to answer for every line, whoever or whatever wrote it.
A candidate who owns their output can tell you why the code is structured the way it is, not just what it does. They can point to where it would break under load or with bad input, and tell you what they'd change with another day on it. They treat the AI as a fast junior who needs supervising, not as an oracle they copy from. This is the judgment I wrote about in Issue #14, where your best engineer often isn't your fastest coder, and in Issue #26 on hiring for decisions made under ambiguity.
AI hasn't removed the need for that judgment. It's made it most of the job.
The engineer who lacks this can still look impressive for about ten minutes. They produce quickly and the output looks plausible. The cracks show when you ask them to go one level deeper than the generated answer, which is exactly what a good interview should force them to do.
| How to interview for it (and the trap to avoid)
You don't need to rebuild your process. You need to point it at ownership instead of production. Three changes do most of the work.
1️⃣ First, bring real AI-generated code into the room and ask them to review it rather than write it. Hand them a working but flawed solution and ask what's wrong with it, where it would fail, and how they'd harden it. Critiquing AI output is now a sharper test of seniority than producing a solution from scratch.
2️⃣ Second, interrupt and ask "why this, and not that" at the decision points. The engineer who understands the code can defend the trade-offs. The one who doesn't will start telling you what the code does instead of why, and you'll hear the difference inside two or three questions.
3️⃣ Third, make them break their own solution. Ask where it falls over and how they'd know in production. Engineers who own their work think in failure modes by habit, so if someone has never looked past "it ran," this is where you find out.
The trap to avoid is reading AI fluency as competence. A candidate who name-drops the right tools and moves fast feels like a strong hire, and that feeling is what catches founders out. Being fluent with the tools is the baseline now, not the edge. What sets a candidate apart is whether they can stand behind what those tools produced.
The job stopped being about who can write the code and became about who can answer for it. Hire the engineer who owns the output, not the one who generates it fastest.
Cheers
Neil