Detecting candidates using AI in interviews does not work well enough. A wrong call ends a career.

Assume candidates using AI in interviews is the default, and say so in the invitation. Ask them to defend what they produce.

Three formats survive. A broken service, their own code, and what the tool suggested that they rejected.

If your interview can be passed by ChatGPT, it was testing recall.

Recall testing was true before any of this existed. The loops struggling hardest were the weakest already.

Four reasons detection of candidates using AI in interviews fails: accuracy, invisible errors, an arms race, and a panel that asks worse questions
Why detecting candidates using AI in interviews fails

Why does AI interview cheating detection fail?

AI interview cheating detection fails for 4 reasons. The tools are not accurate enough for stakes that end a candidacy.

You never see the errors. A wrongly accused candidate never comes back with proof. The detector always looks like it works.

Detection is an arms race you lose. A panel watching for candidates using AI in interviews asks worse questions.

The stakes. A false positive ends a candidacy. Said out loud, it also damages a reputation.

The arms race. Every measure gets a countermeasure within weeks. Theirs cost nothing. Yours cost your team time.

The corrosion. A panel listening for cheating treats candidates as suspects. Suspicion damages the signal you were protecting.

What should you do about candidates using AI in interviews?

Assume every candidate is using AI in interviews and state it plainly in the invitation.

“Use whatever you would use at work, including AI assistants. We will ask you to explain and defend what you produce.”

Nothing is banned and the bar has moved. The second sentence is the whole interview.

Canva went further in June 2025: it expects candidates to use AI.

Canva’s engineering blog says candidates “are expected to use their preferred AI tools”.

Three interview formats that survive candidates using AI: a broken service, the rejected suggestion, and one line of their own code
The 3 formats that survive candidates using AI in interviews

Which 3 formats survive candidates using ChatGPT in interviews?

Three formats survive candidates using ChatGPT in interviews.

A small working service with a subtle bug, 40 minutes, all tools allowed. Then 4 questions about the fix.

The direct question of what the tool suggested that they did not use. And 1 decision in their own code.

1. The broken service. Make the bug behavioural: an off-by-one under concurrency, or a retry that duplicates writes.

A model finds the bug and fails this sequence:

  • Why does your fix work?
  • What else touches this code path?
  • What would break if the load doubled?
  • How would you have caught this before production?

Someone who understands the fix answers all 4. Someone who pasted it runs out around the second.

Four follow-up questions on a bug fix that separate understanding from pasting
The 4 follow-ups candidates using AI in interviews cannot answer

2. The rejected suggestion. “What did the tool suggest that you did not use, and why?” Pasting the first output cannot answer it.

3. Their own code, line 40. “You retry 3 times with a fixed delay. Why 3, and why fixed?”

Anyone who did not make the decision runs out within 2 follow-ups.

What does allowing AI in interviews cost you?

Allowing AI in interviews costs you design work. A broken-service exercise takes a few hours to build.

The same exercise resists the tools and tests something close to the job. It produces evidence for a scorecard.

Build 2 or 3 and rotate them. A week of work lasts a year. A LeetCode problem does none of those things now.

A broken service exercise costs a few hours to build and lasts about a year, against a LeetCode problem that resists nothing
What a broken-service exercise costs against what it returns

What if you suspect a candidate is cheating with AI?

If you suspect AI cheating, go deeper on the work. “Let me understand your approach here”, followed by 3 specific questions.

Three specific questions settle almost every suspected case, on evidence.

If the answers do not hold up, you have a defensible scorecard line. “Could not explain the behaviour of code they submitted.”

An unexplained submission is a real finding. “The detector flagged it” is an accusation.

The tools are now part of the job. An engineer who uses them well ships more than one who refuses to.

Your interview should tell using them well from using them blindly. If it cannot, the gap is in the interview.

Common questions

Should you allow AI in a take-home assignment?

Yes, and add a defence step. A take-home with no follow-up conversation tests nothing now. Cap it at 3 hours and allow every tool. Then spend 20 minutes of the next round on 3 specific decisions. The submission becomes the interview material.

What about proctoring software or lockdown browsers?

Proctoring tools push the tooling off-screen without removing it. They make the candidate experience considerably worse. A phone sitting beside the laptop defeats every one of them. The engineering effort is better spent on a question that a model cannot pass. That question works whatever the candidate is running.

Does allowing AI make the interview easier?

Allowing AI makes the interview harder in the part that matters. The candidate has to defend the code. Why this structure, what breaks first, what they would change. That is closer to the job than writing a binary search from memory.

How many exercises do you need to avoid leaks?

You need 2 or 3 exercises, rotated and refreshed once a year. A broken-service exercise leaks more slowly than a LeetCode problem. The bug is specific to your codebase, and the follow-up questions carry the scoring. If an exercise leaks, the defence questions still work on someone who read the answer.

How do you use AI during an interview?

AI during an interview has 2 sides: the candidate’s and yours. Candidates use AI to write and check code. Your invitation should say that is allowed. Your side uses it to structure notes afterwards, never to score. Then ask what the tool suggested that the candidate rejected. That question does the work a detector cannot.

The short version

Detection does not work, cannot be audited, and makes your panel worse at interviewing.

Allow every tool, say so in writing, and ask candidates to defend what they produce.

Use a broken service. Ask what they rejected.

Go deep on 1 line of their own code.

Where AI genuinely helps your side of the process is in AI in technical hiring.

If your loop needs rebuilding rather than patching, I do that as a fixed engagement.

An audit of your loop, with each round checked against what AI can now pass. Book a free 30-minute call.

Want this fixed in your loop?

SmartHiring trains engineering interview panels on their own open roles. Elman Huseynov, a Tech Hiring Expert in Berlin, runs every engagement. One workshop writes the scorecards for your roles, then calibration runs until the panel agrees. It starts with a free 30-minute call.

No pitch if the loop is already fine. See an example audit report.