In a nutshell
- Hidden AI help in remote interviews is common enough that you should plan for it, not hope it isn't happening. Most of it is invisible to screen share.
- There are real signals worth noticing: pauses before substance but not small talk, reading-style eye movement, instantly optimal answers, polish that collapses under one follow-up. None of them is proof.
- Detection software is an arms race. The tools that help candidates are explicitly sold as undetectable, and the countermeasures need access to the candidate's machine.
- The better move is to change the format so hidden help stops paying off: an explicit AI policy, follow-up ladders, problems that change on screen, and a defense of any work done offline.
- You never need to prove cheating. You only need to score whether the candidate demonstrated the skill. That one shift removes most of the stress from this problem.
How common is AI cheating in interviews, really?
Common enough that "it won't happen to us" isn't a plan.
In an April 2025 survey of verified professionals on Blind, 20% of US respondents said they had secretly used AI during a job interview. That's a self-selected sample, so treat it as a signal, not a census.
The vendor numbers run higher. Fabric, which sells AI interviewing with cheating detection, flagged 38.5% of 19,368 interviews on its platform between July 2025 and January 2026, with technical roles at 48% against 12% for sales. Those are flags from Fabric's own detector, on a sample that looks mostly India-based, not proven cases.
And on the employer side, CoderPad's 2025 survey of about 5,000 developers, recruiters and hiring managers found 40% of recruiters had caught a candidate cheating at least once. CoderPad sells an interview platform, so the usual caveat applies.
So the honest summary: nobody has a clean prevalence number. But every source points the same way, and technical roles look most exposed.
What does hidden AI help actually look like now?
It's not a candidate alt-tabbing to ChatGPT anymore.
Fabric's breakdown of its flagged cases is useful here, again as vendor data: 45% used dedicated overlay tools, 34% voice-mode LLMs, 18% tab switching and 3% a live human helper. Fabric adds that roughly 79–82% of cases used methods traditional tab-switch proctoring can't see.
In practice that means four setups:
- Overlay assistants that read the screen and listen to the call, then show answers in a window your screen share doesn't capture. I cover these in detail in Interview Coder and Cluely detection.
- Voice-mode assistants on a phone or second laptop, listening to your question and answering in an earpiece or on a second screen.
- A second device with any chatbot, out of camera view.
- A human helper, either feeding answers or sitting the interview entirely. That last one is an identity problem, not a cheating problem, and it needs different checks (see fake job candidates and proxy interviews).
Notice what all four have in common. None of them shows up on the screen you're looking at.
What signals are worth noticing?
These are plausible side effects of relaying answers from a tool or a person. Each one is a reason to ask another question, never a finding.
| Signal | What it might mean | Innocent explanation | What to do next |
|---|---|---|---|
| Multi-second pause before technical answers, instant replies to small talk | Waiting for generated text | Translating from a first language; thinking style | Ask a fast gut-call question: "A or B, quick instinct?" |
| Eyes tracking left to right while answering | Reading from a screen | Looking at notes or the problem; neurodivergent gaze patterns | "Without looking at anything, just tell me how step two works." |
| Instantly optimal solution, no exploration | Pre-generated or recalled answer | They've seen the problem before; genuinely strong | Change a constraint immediately |
| Polished answer that collapses under one follow-up | Generated text, no understanding behind it | Over-rehearsed prep; anxiety | Ask why this approach and not the obvious alternative |
| Rewrites from scratch instead of editing their own code | Didn't write the first version | Perfectionism; unfamiliar editor | "Can you get there by changing your existing code?" |
| Fluency or vocabulary shift between rounds | Different source for different parts | Comfort varies by topic | Ask them to rephrase in plain words |
The pattern I'd weight most is the last-but-one. Someone who wrote the code, or seriously reviewed what an assistant wrote, edits it. Someone reading answers tends to start over.
Why can't any of these signals be a verdict?
Because every one of them fires on honest candidates, and you can't tell the cases apart from the outside.
Nerves cause pauses and freezing. Working in a second language produces exactly the "slow on substance, fast on small talk" pattern. Neurodivergent candidates may look away to think or speak in a structured way that sounds rehearsed. Network lag delays everything. And a candidate who has drilled a classic problem gives an instant, optimal, completely honest answer. That's a problem with your question, not with them.
So if you reject people on signals, you will reject good engineers. You'll also have no defensible reason written down when someone asks why.
Why is detection software an arms race you lose?
Look at the incentives on each side.
Cluely, the company that grew out of Interview Coder, publicly prices a "Pro + Undetectability" tier at $149.99 a month against $19.99 for base Pro, at the time of writing. Being invisible during screen share is the product they charge extra for. When your countermeasure improves, theirs is funded to improve too.
The countermeasures also have a structural problem. Detectors such as Truely, launched by Columbia students in 2025, work by inspecting the candidate's machine: browser windows, microphone and screen access, network requests. That means asking the candidate to install monitoring software on their own computer. Then:
- A phone on the desk or a second laptop is outside the software's reach entirely.
- Senior engineers with options tend to decline processes that want software on their personal machine. You keep the candidates with fewer alternatives.
- Anything that scans faces or tracks eyes can bring biometric privacy obligations. Illinois' BIPA, for example, requires written consent for biometric capture. Check with counsel before you buy.
So detection tools aren't useless. They catch the low-effort cases. But they can't be the foundation of your process, because the people you most need to catch are the ones who'll pay for the workaround.
What should you change in the interview format instead?
Make hidden help slow, awkward and visible in its effects, without pretending you can see the help itself. Five changes do most of the work.
1. Write down your AI policy and send it before the first interview
A lot of what gets called cheating happens where the rules were never stated. Talogy, which sells assessments, found that an upfront honesty agreement cut unauthorised help from 28% to 13% across more than 2,000 participants. Vendor data, but cheap to act on.
You can start from our free AI interview policy template.
2. Split the loop into two lanes
Some stages should allow AI and score judgment: what they asked for, what they kept, what they caught. Others should be independent and measure unaided reasoning. Any stage you don't supervise live is AI-allowed whether you say so or not, so say so. I go through the decision in should you allow AI in coding interviews.
3. Never ask a single question. Ask a ladder
Start with a base question, then change a constraint, then ask why they chose this over the obvious alternative, then tie it to something they personally shipped. Each rung removes something an assistant depends on. The full method with worked examples is in technical interview follow-up questions.
4. Show the problem on screen and change it live
Audio pipelines hear everything you say. A constraint that only appears on screen, typed in mid-session, forces a recapture while the candidate is mid-sentence.
"I'll share the starter code. It stays up the whole time, so don't worry about memorising it. I'm going to change it as we go. Start with the simplest version that works, even if it's slow."
Asking for the brute-force version first lowers the stakes for nervous candidates and makes a sudden jump to a perfect answer conspicuous.
5. Defend anything done offline
Take-homes and async tests are AI-allowed by nature. That's fine, as long as a live defense follows where they change their own code while you change the requirements. Someone else can do a take-home. They can't do the defense for the candidate.
What do I say when something feels off mid-interview?
Don't change your tone and don't accuse. Go deeper.
"Nice. Why that approach over a hash map?"
"Walk me through what happens on the second iteration, step by step."
"Let's step away from the code for a minute. Describe the boxes and arrows for me, like you're explaining it to a new teammate."
Drawing and verbal reasoning are much harder to relay through a tool in real time, and explaining design without code is a normal part of the job.
If your published policy says you may, a neutral environment reset is reasonable:
"Quick housekeeping before the next part. Could you share your full screen rather than just the editor? It helps me follow along when we switch between things."
If they decline, note it and move on. A refusal is an observation, not an admission. Then finish the interview normally, with the same time and questions as everyone else.
What never to say: "Are you using ChatGPT right now?" Honest candidates are humiliated, dishonest ones say no, and you've learned nothing.
What goes on the scorecard?
Observations and ladder results. Never conclusions about intent.
| Write this | Not this |
|---|---|
| "Rung 1: answer didn't change when I added the out-of-order constraint" | "Was reading from ChatGPT" |
| "Paused 4–6 seconds before technical answers; small talk instant" | "Seemed off" |
| "Couldn't explain why they used a queue; restarted instead of editing" | "Probably cheating" |
Here's the key move. If a candidate can explain, modify and defend their work across three rungs, whatever caused the signal doesn't matter much. If they can't, you have a performance finding that stands on its own. You score what was demonstrated, and you never need to prove anything.
Checklist: before your next remote technical interview
- [ ] AI policy sent with the invite and repeated at the start of the call
- [ ] Each stage labelled AI-allowed or independent
- [ ] Two base questions per 45 minutes, each with 3–4 prepared perturbations
- [ ] Problem shown in a doc or editor you control
- [ ] Opening script asks for brute force first and thinking aloud
- [ ] Any take-home or async test followed by a live defense
- [ ] Scorecard asks for evidence per rung, not impressions
- [ ] Same interviewer sees the candidate at two or more stages
- [ ] One extra probing question ready for each signal above
Where should I start?
If you want to know where your current loop is most exposed, take the free cheat-risk audit. It's a short self-check that points at what to fix first, which is usually not a new detection tool.
If you'd rather have the whole system ready to run, the question bank with ladders by stack, AI-allowed work samples with rubrics, and the identity and 30-day validation templates are in Unscripted, the paid kit. But the five format changes above are the core of it, and you can start with them tomorrow.