Every candidate in your pipeline has Claude open in another tab. Some of them tell you. Most of them don't. The proctoring vendors know this, which is why they keep shipping new ways to lock the browser, watch the webcam, and flag the "suspicious" glance off-screen. It's an arms race, and the candidates are winning.
So a lot of teams reach for the obvious lever: ban it. No AI, no autocomplete, no Stack Overflow. Whiteboard the algorithm like it's 2015.
That doesn't restore signal. It just moves the problem somewhere you can't see it.
The job changed. The interview didn't.
Here's the uncomfortable part. The engineers you're trying to hire already use AI every day on the job. They prompt it, they paste its output, they catch it when it's wrong, they throw away the 30% that's subtly broken. That last skill — noticing when the assistant is confidently incorrect — is one of the most valuable things a senior engineer does now.
A banned-AI interview measures none of it. You're testing whether someone can do, from memory and under a stopwatch, a thing they will never again do without a tool. You optimize for recall and typing speed. Then you put them on a team where the actual work is decomposition, judgment, and verification.
The interview drifted away from the job, and banning AI widens the gap.
"But how do I know they can really code?"
This is the real fear, and it's fair. If the assistant can write the function, what are you even measuring?
You're measuring the same thing a good senior measures in code review: did this person make good decisions, and can they defend them? Give someone a realistic task with the assistant turned on and you immediately see things a clean-room puzzle hides:
- Do they decompose a vague problem into the right pieces, or do they prompt their way into a corner?
- When the assistant hands them working-but-flawed code, do they notice the missing edge case, the swallowed error, the test that doesn't actually test anything?
- Can they explain why they accepted or rejected what the tool produced?
A candidate who leans on AI without judgment falls apart on a task like this — faster than they would on LeetCode, not slower. The tool amplifies whoever is driving it. Skill becomes more visible, not less.
Assume the AI is there
The fix isn't detection. It's design. Stop trying to prove the assistant is absent and assume it's present, because in the job it always will be. Then build the interview around the thing you actually care about: judgment under realistic conditions.
That's the bet behind AI-native technical interviews. The candidate works in a real editor with a real AI assistant they can ask anything. Meanwhile a second AI — a silent watcher — observes the whole session: the diff, the prompt history, the test runs. It never talks to the candidate. It builds an evidence-cited score against the rubric you wrote, and it flags the moments that matter — the shortcut that hides a tradeoff, the test that passes for the wrong reason.
You stop policing the tool and start grading the work.
What you get back
When you stop fighting the assistant, three things happen:
- The signal sharpens. You see how someone thinks with the tools they'll actually use, not how well they memorized an algorithm.
- Candidates relax. Nobody resents an interview that lets them work the way they really work. Your offer-accept rate is part of your hiring funnel too.
- The decision is defensible. Every recommendation traces back to a specific moment in the transcript, so "no hire" is a sentence you can actually back up.
Banning AI feels like control. It's the opposite — you've blinded yourself to the one skill that now separates strong engineers from weak ones. Let the assistant in, and measure who can think.
Want to see what an AI-allowed interview looks like in practice? Read how to interview engineers who use AI, or start with the AI-native interview overview.