Ask a hiring manager to describe a candidate who "uses AI well," and most can't get past the shrug. They know it when they see it — which really means they don't have a rubric, they have a vibe. That's a problem, because "uses AI" was never the skill. Everyone uses AI now, including the mediocre engineers you already regret hiring. The skill is what a candidate does in the gap between the assistant's suggestion and their own decision to keep it, discard it, or rewrite it. Call that gap direction. If your process doesn't test for it explicitly, you're scoring candidates on something that no longer separates anyone.
"Uses AI" is not a skill; directing it is
Every candidate you interview this year has an assistant open. That's not a signal any more than "types on a keyboard" is a signal — it's the baseline condition of the job now. What varies, enormously, is what they do with it: whether they hand it a vague ask and ship whatever comes back, or whether they treat it like a fast, occasionally wrong collaborator that needs supervision.
Direction is a real, learnable, gradable skill, not a personality trait or "AI fluency" or how fast someone can write a prompt. It's a loop: state the problem precisely enough that a good answer is even possible, evaluate what comes back against reality rather than against "does it look plausible," and decide, deliberately, when to keep, fix, or throw away the result. Candidates differ wildly on all three. Most rubrics currently measure none of them.
The behaviors that separate strong from weak AI users
Watch two candidates use the same assistant on the same task, and the difference isn't in the tool. It shows up upstream and downstream of it.
Upstream: how they specify intent. A weak candidate types "add pagination to this endpoint" and takes whatever eight lines come back. A strong candidate first spends thirty seconds establishing constraints the assistant can't infer on its own — whether results need to stay stable if rows are inserted mid-scroll, whether the client already sends a cursor. The prompt they write encodes understanding of the system. The prompt a weak candidate writes encodes only the ticket title.
Downstream: how they treat the output. A weak candidate reads code the way you skim a text message — fast, for gist, trusting the tone. A strong candidate reads it the way you'd read a contract someone else drafted: line by line, asking what happens at the edges. Did it handle the empty case? What happens if this gets called twice in a row?
And in between: knowing when to stop trusting the loop at all. Strong candidates recognize a class of problem where an assistant's fluency actively works against them — anything where the risk is an omission rather than a visible error, like a permissions check, a data migration, or a business rule the assistant has no way to know. In those spots, the tell isn't cleverer prompting. It's the candidate slowing down and doing the reasoning themselves before asking for a draft at all.
A concrete rubric for AI-direction
Strip that down into something you can actually score in an interview, and four dimensions cover it.
Specification. Did the candidate give the assistant enough context to succeed, or did they hand off the ambiguity along with the work? Good looks like stating an assumption out loud before prompting — "I'm telling it this needs to be safe to retry, because the client will retry on timeout" — not silently accepting whatever the first draft happened to assume.
Verification. Did they check the output against something real — an edge case, a second run, an existing test — before treating it as done? Good looks like running the code against a case they invented themselves, not just the case the assistant already handled.
Override. When the output was wrong, subtly wrong, or simply not the approach they wanted, did they catch it and say why? Good sounds like "this works, but it swallows the error instead of surfacing it — I want it to fail loudly," delivered before you have to ask, not after.
Restraint. Did they recognize the moments where prompting an assistant was the wrong move entirely — a place that needed their own judgment, not a fast draft? Good looks like a candidate closing the assistant for two minutes to work out, by hand, what should happen if a migration fails halfway through, then coming back to implement it.
None of these are about how eloquently a candidate talks about AI in the abstract. They're about what they actually did, in front of you, with a specific tool and a specific task. That's what makes the rubric gradable instead of vibes-based.
How to observe it in a screen
You can't see any of this from a résumé line that says "proficient with AI tools," and you can't infer it from a finished pull request either — a clean diff looks the same whether the candidate directed the assistant carefully or just tidied up its output. You have to build a screen that surfaces the loop itself, and that takes three ingredients.
A real task, not a puzzle — something in an actual small codebase with real constraints, because direction only shows up when there's something to get wrong. An assistant present for the whole session, not summoned for one sanctioned moment, because you need to watch the specify-verify-override cycle happen more than once. And a think-aloud requirement: the candidate narrates what they're asking for and why, in real time, rather than working in silence and explaining afterward from memory.
That last piece matters more than it sounds like it should. A candidate explaining their prompt before they send it is showing you the specification step directly. A candidate narrating what they're checking for before they run the code is showing you verification directly. Ask for the explanation after the fact instead, and you get a story reconstructed to sound reasonable in hindsight — a different, much weaker signal than watching the actual decision happen.
Red flags
A handful of patterns are worth naming explicitly, because they show up reliably and each one is diagnostic of a different failure.
Blind acceptance is the clearest: the candidate takes the assistant's first answer, every time, with no visible check against the actual problem. You'll see it as a rhythm — prompt, paste, run, move on — with no pause anywhere that looks like scrutiny.
Can't explain the code catches people who paste and never really read. Ask them to walk through what a specific block does and why, and a candidate who understands their own output can answer in the terms of the problem. A candidate who doesn't will answer in the terms of the prompt — "I asked it to add caching, so it added caching" — which tells you the explanation lives one level removed from the code itself.
Over-delegation is the subtler failure, because it can look like productivity. The candidate hands off decisions that were theirs to make — what an API should return on a partial failure, whether a field is actually required — instead of deciding and then directing the assistant to implement the decision. The output ships fast and looks fine. What's missing is any evidence the candidate made a judgment call anywhere in the session.
Watch for the inverse too, though it's rarer: a candidate so wary of the tool that they refuse to use it productively at all, re-deriving by hand things a good assistant would've gotten right in one pass. That's not a green flag either — it's a different way of failing to direct the collaboration well.
What this predicts about on-the-job performance
The reason this rubric is worth building, rather than a nice-to-have, is that direction is the same skill on the job that it is in the interview — it doesn't stay contained to "how someone uses their AI assistant." A candidate who specifies intent precisely before prompting is the same person who writes a clear ticket before handing a task to a teammate. A candidate who verifies output against edge cases is the same person who catches the real problem in a teammate's pull request before it ships. A candidate who knows when to override the tool is the same person who pushes back on a bad requirement instead of quietly building exactly what was asked for.
That's why the gap between a candidate's confidence and their actual judgment shows up early and matters late. Someone who over-delegates to an assistant in an interview will over-delegate to whatever's easiest on the job — a framework default, a teammate's offhand suggestion, the first search result — because the underlying habit was never really about AI. It's about whether the person does the thinking, or waits for something else to do it for them.
Score for direction and you're not scoring a skill that expires with this particular generation of tools. You're scoring the same engineering judgment hiring has always tried to measure — just observed through the one collaborator every candidate now has in the room. We built the rubric above directly into Chiron's AI coding assessment, alongside the broader case for redesigning the screen around real work in how to screen engineers when everyone uses AI; see pricing if you want the packaged version. But you can run this rubric with a whiteboard and a stopwatch. What matters is that you're finally scoring the decision, not the artifact it happened to produce.