Hiring AI Engineers When Everyone Uses AI
Every engineering candidate you interview in 2026 uses AI tools in their daily work, and that is exactly what you want. The question an interview needs to answer was never "can this person write code without help." It is "can this person direct, evaluate and take responsibility for a solution," AI-assisted or not. That distinction gets lost when interview policy is written as a blanket ban.
Short answer
Stop testing unaided typing and start testing judgement. Give candidates an artefact to critique, then change a constraint and have them adapt it live. Generation is cheap; situated judgement about a specific artefact is not, and it is far closer to the actual job.
Run a mix: one closed-book element where you need unaided reasoning, one open-book element where tool use is permitted and how they direct and verify it is what gets scored. Tell candidates which is which.
On this page
Stop asking the wrong question
A closed-book algorithms round measures a candidate's ability to reproduce a known solution unaided. That was a reasonable proxy for engineering ability when reproducing solutions was most of the difficulty. It is a much weaker proxy now, and it has an active cost: it tells strong candidates that you have not updated your process since the work changed.
The skills that actually differentiate engineers now are upstream and downstream of generation. Framing a problem so that a solution is possible. Recognising that output is subtly wrong. Understanding the failure modes of something that looks correct. Taking responsibility for code you did not type character by character.
Fluency versus dependence
| Behaviour | Fluent | Dependent |
|---|---|---|
| Framing the problem | Clarifies constraints before reaching for a tool. | Starts generating immediately. |
| Reading output | Notices subtle errors and says why they matter. | Accepts plausible-looking output. |
| Explaining choices | Can defend an approach against an alternative. | Cannot say why one beat the other. |
| Changed constraint | Adapts quickly, reasoning aloud. | Stalls or restarts from scratch. |
| Confidence | Names what they are least sure about. | Uniform confidence across everything. |
| Disclosure | Open about tool use. | Conceals it, sometimes deliberately. |
The right-hand column is what an interview should surface, and note that almost none of it requires knowing whether a tool was used. It requires asking questions that only understanding can answer.
A format that tests judgement
- Open with an artefact, not a blank editorA design document, a pull request, or an implementation with problems in it. Ask what they would change before writing anything.
- Let them use their normal tools, and say soIf the round is open-book, make it genuinely open. Candidates who suspect a trap behave unnaturally and you learn less.
- Change a constraint mid-problem"The input no longer fits in memory." "This now runs in a hot path." Adaptation is where understanding becomes visible.
- Ask what they are least confident aboutA genuinely useful question. Fluent engineers answer it precisely; dependent ones cannot locate their own uncertainty.
- Probe one decision to depthPick a single choice they made and go three questions deep. Depth exposes borrowed reasoning faster than breadth.
- Keep one closed-book element if you need itShort, and clearly signposted as a different round with a different rule.
The flawed-code review exercise
If you adopt one thing from this article, make it this. Generate a solution with an AI tool, introduce two or three realistic problems, and ask the candidate to review it as though it arrived as a pull request.
What strong candidates do
- Find the substantive problems, not only the style ones.
- Explain the consequence of each in production terms.
- Distinguish "wrong" from "I would do it differently".
- Ask about context the code does not show.
- Say which parts they would accept as-is.
What dependence looks like
- Surface comments only: naming, formatting, minor style.
- Accepts the overall approach without questioning it.
- Misses the failure case entirely.
- Cannot say what would break, only that something might.
- Treats plausible structure as evidence of correctness.
The exercise is also fair in a way closed-book rounds often are not. It does not disadvantage candidates who think best with tooling, it maps directly to real review work, and it produces a conversation rather than a pass or fail.
Where monitoring fits when AI is allowed
Permitting AI does not remove the need for integrity controls. It changes what they are for. A blanket ban makes any tool use a violation, which is unenforceable. A specific boundary makes monitoring meaningful, because there is now a line for it to report on.
| Round | Permitted | What monitoring reports |
|---|---|---|
| Closed-book element | Language docs only. | Assistant processes, off-surface pastes, hidden windows. |
| Open-book element | Their normal tools, openly. | Little of interest, deliberately. Context only. |
| Any round | n/a | Remote-control sessions and injected input, which are never permitted. |
The third row is the one worth keeping regardless of how open your rounds are. Whether AI is allowed is a policy choice; whether the candidate is the person doing the work is not. See proxy interviews and remote-control fraud.
Key takeaways
- A blanket AI ban tests a skill the job no longer requires, and it costs you strong candidates.
- Test judgement: give an artefact to critique, then change a constraint and have them adapt live.
- The flawed-code review exercise separates fluency from dependence with no monitoring at all.
- Permitting AI makes monitoring more useful, because a specific boundary is something to report against.
- Identity and proxy controls stay regardless of how open your AI policy is.
- Say which round is which, and credit open tool use rather than punishing it.
Writing the policy candidates see
The second clause matters more than it looks. Without it, candidates hide usage they would have been credited for, because they assume any AI use counts against them. That costs you the signal you were trying to collect. Fuller wording is in our policy template.
Frequently asked questions
Should you ban AI tools when interviewing engineers?
A blanket ban is usually the wrong call and signals that you do not understand the job. Every engineering candidate uses AI tooling daily, and a total prohibition tests a skill they will never exercise again.
The workable structure is a mix: one closed-book element where you need to see unaided reasoning, and one open-book element where tool use is explicitly permitted and how they direct and verify it is what gets scored. State clearly which round is which.
How do you test whether a candidate actually understands AI-generated code?
Hand them a deliberately flawed AI-generated solution and ask them to review it for production. Strong candidates find the problems quickly, explain the consequences, and say what they would change. Candidates who cannot work without the tool accept it as written or spot only surface issues.
This single exercise distinguishes fluency from dependence more reliably than any monitoring signal, and it mirrors what the job actually involves.
What is the difference between AI fluency and AI dependence?
Fluency means directing the tool well: framing the problem, noticing when output is wrong, and taking responsibility for the result. Dependence means being unable to proceed without it.
It shows up immediately when a candidate is asked why they chose an approach, to adapt it for a new constraint, or to say what they are least confident about. Fluency is a hire signal; dependence is the thing an interview should surface.
Where does integrity monitoring fit when AI use is allowed?
It matters more, not less, because permission makes the boundary specific rather than absolute. If a round permits documentation but not live answer generation, monitoring tells you which side of that line the session sat on.
Without a stated boundary there is nothing to monitor against, which is why policy has to come first and why "we allow AI" is not a complete policy.
What interview format works best for engineers who use AI daily?
Formats built around critique and adaptation rather than generation. Give the candidate an artefact, a design, a pull request, a flawed implementation, and ask what breaks, what they would change and why. Then change a constraint and have them adapt live.
Generation is cheap now; situated judgement about a specific artefact is not, and it is also much closer to what senior engineering work involves.
How should the AI-use policy be worded for engineering candidates?
Name the round rather than the product, and say what is permitted as well as what is not. For example: this round is closed-book, you may prepare with any tools, during the session please use only language documentation and no live answer generation.
For the open-book round, say so explicitly and add that how the candidate uses the tool is part of what is being assessed, so nobody hides usage they would be credited for.
References
- Coding test cheating prevention, for question design in coding rounds.
- ChatGPT in job interviews, on what is and is not detectable.
- Interview integrity policy template, for the permitted-AI clause.
- Proxy interviews and remote-control fraud, for the controls that stay regardless.
Interview AI engineers without an anti-AI process
InterviewWatch reports against the boundary you set, whichever rounds you open up, and never assumes tool use is misconduct.