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 I argued the engineer worth hiring is the one who knows when to stop the agent, not just drive it. Judgment over horsepower.
This week is about the problem sitting one level up from that. Before you can test an engineer's judgment, you have to know what you're hiring for, and then work out how deep a given candidate really goes. Both are harder than they sound, and getting either wrong is what quietly sinks the hire.
You'll learn why qualifying the role is now the harder half of the job, why "uses AI" hides a canyon most CVs paper over, and the two questions that cut through both.
Not a subscriber yet? Sign up here
| Sourcing was never the hard part
Everyone thinks their hiring problem is a supply problem. Not enough good people in the pipeline. It almost never is. Getting strong candidates interested in a compelling role is the easy bit, and it has stayed easy even as the market has tightened. Frame the opportunity well and good people lean in.
The hard part is qualification. Reading the role accurately, then reading the candidate against it. AI has made both of those brutally hard at the same time, and that is the reason a good recruiter is worth a fortune right now. Not the sourcing. The judgment about fit that sits underneath it.
| The role is the harder half
Start with something most founders won't say out loud. They don't fully know what they're hiring for.
That isn't a criticism. When you're building something new, the shape of the role only comes into focus as you go. Founders who've been heads-down building for months still need the first few interviews to sharpen their own picture of the hire. That is normal. The spec is a hypothesis, and the early conversations are how you test it.
The problem is what founders reach for instead of doing that thinking. More and more of them now hand the job description straight to a model. Do that with a role you don't understand yet and it hands back a confident, polished spec for the wrong job. When the brief is clear, AI sharpens it. When it's muddled, AI just scales the mess. A tidy JD built on a fuzzy brief is worse than none, because it looks finished.
A better prompt isn’t the answer. Before you write a line of the spec, write down the three or four things this hire has to get done in their first 90 days. Outcomes tied to your product, not "ships fast with AI." I know I've banged on about the 90-day mission across a few issues now, but that's because it works and I've watched it work. That short list is the role. If you can't write it, you're not ready to hire yet, and neither is your AI.
| "Uses AI" hides a canyon
Now the candidate side. The phrase "experienced with AI" on a CV covers a range so wide it's almost meaningless. A founder I trust framed the ladder better than I've heard it put anywhere. Three rungs:
1️⃣ One, productivity use. Autocomplete, chat, cleaning up code faster. Useful, and completely generic now.
2️⃣ Two, building with AI. Using Claude or Codex to ship production software. This is the standard now, not a differentiator. If an engineer isn't doing this, that's the flag.
3️⃣ Three, building AI. Designing the agentic product itself. This is the rare one, and it's a different kind of engineering. If you want the clearest picture of what that top rung involves, Anthropic's own engineering guide, Building Effective AI Agents, is the best read going. The tell in an interview is whether the engineer thinks in the primitives the work demands.
Take a concrete example. An AI concierge takes a guest request, opens a task, and that task might get resolved by a human three days later. A session-based agent can't hold that. It runs, then stops. You need durable workflows that can pause and wait for a status to change, and a worked-out answer for long-term memory as the same user moves through completely different states over weeks. Strong engineers who've only ever built traditional software walk straight past this. They apply a SaaS mindset to an agentic problem and get lost the moment the 90-day objective comes up.
One line from him stuck with me. “They build with AI, but they've never built AI.”
| Don't overcorrect into the vibe coder
Worth being clear, because this cuts both ways. The answer is not to chase the person who found agents last month and now vibe-codes everything with no fundamentals. That's the opposite failure. You want strong engineering fundamentals and serious depth on the agentic side, in the same person.
And you don't necessarily need someone who's shipped an agentic product commercially, because that person is rare and priced accordingly. What you need is evidence they've gone looking. Someone who says "I built my own agent to do X" or "I've been pulling apart an agent framework to see how it handles memory." If an engineer hasn't touched any of this by now, it probably doesn't excite them, and this isn't a role for someone it doesn't excite.
| Two questions that do the work
So how do you qualify both halves without a four-hour process. Two questions carry most of the weight.
For the role, ask yourself first what this person delivers in 90 days. If you can't answer it cleanly, stop and fix that before you interview anyone.
For the engineer, ask them to walk you through an agent or a harness they've built, and how they handled memory and a task that outlives the session. The productivity user runs dry in two sentences. The builder can't stop talking, and inside a minute you'll hear whether they think in the primitives the job needs. It also tests desire, which when the experience is rare is the thing you're really buying.
Sourcing gets the attention because it's visible. Qualification is invisible, which is exactly why it's the skill that's suddenly worth so much. Read the role honestly, read the depth accurately, and you've done the part AI can't do for you yet. Get that right and the hire almost makes itself.
Cheers
Neil