Stop Trying to Spot AI Cheating. Design Interviews That Expose Shallow Understanding
How do you deal with AI cheating in technical interviews? Eye contact, pauses and pasted code are weak signals. Here is how to collect better evidence of real skill, without confusing ordinary AI use with identity fraud. The reliable way to deal with AI-assisted cheating in an interview is not to prove that somebody used AI. It is to collect enough evidence that they can do the job: probe a specific decision, watch them work through a real problem, change a constraint, and ask them to test their own answer. Eye contact, pause length and pasted code are weak signals that even trained interviewers get wrong most of the time. Interview design is the actual defense.[1] I have been on the candidate side of the table for most of my career. Lately I am on the other side, and the game has changed. I wrote a short TIL on one of these tricks (a candidate running an LLM on a phone just off-camera) and got a couple of DMs asking how to take precautions. I spent a couple of weeks digging in, comparing notes with other interviewers, and being honest with myself about which of my “tells” actually hold up. This post is the long answer. In one recent panel, a candidate gave a flawless system-design answer, eyes fixed a little left of the camera, then went silent when I asked “tell me about a specific time that exact approach failed for you.” Nothing showed up on the shared screen, no phone in view, and they didn’t admit to anything when I asked directly. I don’t have proof they were reading an AI’s answer off a second screen. I failed them on the capability evidence from the round, not on the eye movement. Even that sentence needs care. One silence is not enough to establish a capability mismatch. Maybe the exact situation had never happened to them. Maybe the closest example was confidential. Maybe I had asked for a memory they could not retrieve while anxious on a video call. If this had been the only weak answer, it would not have been a fair reason to reject them. The defensible version is a pattern across independent probes: can they change a constraint, choose a useful metric, debug a failure mode and defend the consequences? That is evidence I can score. Suspected cheating is not. That distinction matters more than anything else in this post. A “tell” is a nudge to use the next question already in your interview plan, not proof of anything. Treat it as more than that and you will fail honest candidates for being nervous, composing English as a second language, being neurodivergent, or just having a bad connection. In one controlled experiment, interviewers could not reliably tell when candidates used ChatGPT mid-interview: candidates solved verbatim questions correctly 73% of the time, and not one session got flagged.[^1] It was a small experiment, not a universal detection rate, but the lesson holds: a 2-3 second pause, formal phrasing, a reading cadence, eyes drifting off-screen, a face that never breaks contact: every one of those describes a nervous but honest candidate just as well as a cheater. Anxiety, composing a sentence in a second language, a slow home connection, a webcam mounted dead-centre, coaching to “hold eye contact”: all of it produces the exact same signals. None of it is proof. The correct response is to follow the same planned probes you use for every candidate, never to improvise an accusation. Falsely branding an honest engineer a cheat is a worse outcome than letting a clever one slip through. The cheating I see is not a guy with a textbook off-camera or a friend prompting answers on a placard. It is software, and it is good. One available method now is a screen overlay that listens to the interview audio, runs it through an LLM, and prints the answer on the candidate’s screen. It runs as a transparent layer, so there’s no browser tab or window for the screen-share to catch. Tools including Cluely, Interview Coder, LeetCode Wizard and Final Round AI show how accessible the toolchain has become.[2] [3] The best-known example is Interview Coder, built by Roy Lee and used during his own Amazon interview. Amazon rescinded the offer, Columbia took disciplinary action, and Lee later turned the idea into Cluely.[4] [5] [6] Whatever you think of the company, this category of tool is not going away. Here is an overlay in action: the assistant runs in a transparent window on the candidate’s own laptop, invisible on a screen-share, feeding answers right over the call: The low-tech cousin: ChatGPT voice mode or Gemini open on a phone propped out of frame. The model hears the room, generates an answer, and the candidate reads it off the screen or hears it through an earbud.[7] [8] In a coding round, the candidate runs AI in the background, has it transcribe the prompt, gets a full solution, pastes it, and renames a variable or two.[9] This blew up in March 2025 when CNBC reported a Google engineer leaning on an AI assistant mid-interview, and the whole industry started asking whether coding interviews even mean anything anymore.[10] If you run a system-design or coding round, assume this is in the room. Everything above is about a real candidate getting help. This next category is not. It’s identity fraud, and no amount of clever interview design fixes it on its own. The nation-state version is already documented. The FBI has warned that North Korean IT workers use stolen identities and other deceptive practices to get hired remotely and funnel wages back to the regime.[14] If a proxy or a deepfake can clear your loop, it is not something an individual interviewer should investigate alone. It belongs with HR, security and a documented identity-verification process. Structured, job-specific interviews consistently predict on-the-job performance better than improvised ones.[15] That is the real lever here, not sharper eyes. Three ground rules before the specifics: “AI is fine when it helps a real skill” is a useful principle and a terrible policy. It leaves the candidate guessing what counts as help and gives every interviewer a different line to enforce. Pick a mode, state it in the invitation, and apply it consistently: There is room for both interview modes in one loop. A short no-AI exercise can test whether the foundations exist; an AI-enabled task can test how the person will actually work. The important part is telling them which game they are playing. For each competency, write down six things: That last item matters. “Seemed suspicious” is not a scoring anchor. “Identified the consistency trade-off, changed the design when latency became the priority, and proposed a test for duplicate delivery” is. This is the move I reach for first, for every candidate: “Now tell me about a specific time you tried exactly that and it failed. What broke, and what did you do?” “Which part of this project would need to change to scale to 10x the load, and why?” LLMs are excellent at textbook answers. A specific, negative, personal example is harder to borrow convincingly, especially when I follow the chain: what did you observe, what did you try first, what changed your mind, and what would you do differently now?[16] [17] It is still not AI-proof. A résumé-aware model can invent a polished STAR story, and an honest candidate may not have the exact memory I ask for. I let them use the closest relevant example, then check whether the details remain coherent across follow-ups. One weak answer is a data point; a repeated inability to connect decisions to consequences is evidence. Change one constraint while they are answering: “If the deadline were halved, what do you drop?” or “We just learned that writes can arrive twice; what changes?” I am not timing the pause. I am looking at how they revisit assumptions, name the trade-off and carry the change through the rest of the design. I stopped asking abstract LeetCode puzzles. I hand candidates a small, sanitized piece of our actual kind of work: debug this API, optimize this query. No customer data, production credentials or reusable unpaid feature work. It is harder to one-shot with a tool, and more representative of the job.[18] Thinking aloud is useful, but I do not mean narrating every keystroke. That can turn the round into a test of continuous verbal performance and make the coding itself harder. Use checkpoints instead: “What assumption are you making?”, “Why this structure?”, “What would you test next?”, “What would make you abandon this approach?” Sustained, internally consistent reasoning is harder to borrow than a finished answer, and the checkpoints produce evidence an interviewer can actually write down.[17] [19] Before the interview I sometimes run a sanitized prompt through several models and see where the obvious answer is shallow. That helps me design the next constraint; it does not give me an AI fingerprint. For a “count occurrences in a string” prompt, models and honest engineers will all reach for Do not paste a candidate’s résumé, proprietary question bank or company code into a public model unless your organization’s data policy explicitly allows it. And do not score a candidate down because their code looks like a model’s code. Score what happens when they have to test, change and defend it. I no longer think an individual interviewer should decide that a room scan, a second camera or an improvised “turn your head” deepfake test is reasonable in the moment. These checks can invade a candidate’s home, disadvantage people who need accommodations, and still produce false confidence. If the role justifies identity verification or proctoring, the organization needs a written, legally reviewed process with advance disclosure, data-retention rules and a real accommodation path.[20] The interviewer follows that process and escalates anomalies. They do not invent a private investigation on the call. Some approved platforms can record paste events or replay the path through a coding task. That data may help reconstruct what happened, but it is still context, not a verdict. Use it only under a disclosed company policy and never as a replacement for a well-designed question and a scoring rubric. These are the things I used to lean on before I redesigned my questions. They still show up, and gaze-correction filters like Nvidia’s “Eye Contact” effect can paint over the classic off-screen glance anyway.[^24] A 2-3 second delay, a reading cadence, unusual eye contact or a sudden change in face brightness can all come from ordinary nerves, accessibility tools, notifications, lighting or a poor connection. I do not record them as evidence of cheating and I do not use them to decide who gets a harder interview. Every candidate gets the same planned evidence ladder. Here is a shape you can use for one technical competency: Score the competency after the call against the anchors written beforehand. A strong answer does not have to match mine. It has to make its assumptions visible, respond coherently to new evidence, and own the consequences of its choices. An insufficient answer stays at the textbook layer after several independent opportunities to go deeper. Nowhere on that rubric is a box for “looked left.” An individual interviewer can improve a question. A hiring leader has to make the whole loop reliable. That means agreeing on which competency each round owns, deciding where AI is and is not allowed, giving interviewers the same scoring anchors, and calibrating with real examples before the next candidate arrives. Recruiting communicates the policy. Interviewers assess capability. HR and legal own accommodations and privacy. Security owns identity-fraud escalation. Nobody invents policy in the middle of a call. Then measure whether the change worked. I would watch interviewer agreement, candidate drop-off, pass rates between stages, exceptions and escalations, candidate feedback, and the performance of new hires after they join. I would also review whether particular questions or interviewers produce unusual rejection patterns. A process can look rigorous while merely becoming harder, more inconsistent or more hostile. The goal is not to catch the largest number of people using AI. The goal is to build a hiring system that consistently identifies people who can do the work, gives honest candidates a fair chance to demonstrate it, and does not create more organizational risk than it removes. The line I draw is simpler now: state the rules, test the work and score the evidence. Undisclosed AI use in a no-AI round is a policy violation. Effective, transparent AI use in an AI-enabled round may be exactly the skill I want. In either mode, I need the candidate to understand the output, catch its mistakes and take ownership of the decision. Identity fraud is a different problem entirely, and it is not mine to diagnose from a webcam tell. If you are on the other side of this table and want to win the honest way, my whole job interview series documents real rounds, real questions, and what actually got me hired. No. It depends on the disclosed rules of the round. Decide whether you are running a no-AI or AI-enabled assessment, state the policy in advance, and apply it the same way to every candidate. You can run a disclosed no-AI round when unaided fundamentals matter. Proctoring still will not prove what a candidate understands. Use it only under an approved policy, then make the hiring decision from structured, job-relevant evidence. Poorly. In a controlled experiment, interviewers missed AI-assisted answers even when actively looking for them.[1] Gaze-correction filters can also fake steady eye contact. Do not score these signals or use them to decide who gets a harder question; continue with the same planned probes for every candidate. Do not improvise either one as an individual interviewer. If your organization decides the role justifies an intrusive check, it needs a written, legally reviewed policy, advance disclosure, data-handling rules and an accommodation path.[20] AI-assisted cheating is a real candidate breaking the tool policy of an assessment. Identity fraud is someone other than the candidate on record showing up at all, sometimes as part of an organized or nation-state operation.[14] I handle the first by scoring demonstrated capability and following the hiring policy. I escalate the second to HR and security rather than trying to prove it myself. My interview-questions and experiences series, with real rounds and real questions: A note on the sources: several examples below come from companies selling interview, proctoring or fraud-detection products. I use those pages to show what tools claim to do, not as independent estimates of how common cheating is or how well a detection method works. The structured-interview, accommodation and nation-state claims point to government sources. interviewing.io: How hard is it to cheat with ChatGPT in technical interviews? We ran an experiment ↩ ↩2 Alex: 8 Tactics Candidates Are Using to Cheat in Interviews ↩ ↩2 Fabric: How Candidates Use AI Tools Like Cluely to Cheat in Live Interviews ↩ TechCrunch: Columbia student suspended over interview cheating tool raises USD 5.3M ↩ Columbia Spectator: Interview Coder founders drop out amid disciplinary action ↩ Fabric: How Candidates Cheat in AI Interviews (And How to Stop It) ↩ CNBC: How Google is responding to AI cheating in coder interviews ↩ Resemble AI: How to Detect Deepfake Interviews in Remote Hiring ↩ U.S. Office of Personnel Management: Structured Interviews ↩ withSherlock: 10 Ways to Prevent AI Cheating in Remote Interviews ↩ InCruiter: How Companies Detect AI-Assisted Interview Cheating ↩ ↩2 Evohire: How to Prevent AI Cheating in 2026 Technical Interviews ↩ Utkrusht: Easy ways to catch cheaters using AI during tech interviews ↩
What actually happened, and what I can and can’t prove
Part 1: How candidates actually cheat
1.1 Invisible real-time answer assistants
1.2 The second device
1.3 Live-coding paste-and-pray
1.4 Proxy interviews and deepfakes: a different problem entirely
A candidate lip-syncing and getting caughtPart 2: Interview design that exposes shallow understanding
2.1 Decide what kind of interview you are running
2.2 Build the evidence ladder before the call
2.3 Ask for the failure, not the definition
2.4 Reframe mid-answer
2.5 Give real work, and ask for reasoning at checkpoints
2.6 Pre-compute the likely AI answer, but don’t fingerprint candidates
collections.Counter because that is the idiomatic answer.2.7 Do not improvise surveillance
2.8 Let approved tools handle the boring layer
2.9 A 45-minute version you can actually run
2.10 Fix the hiring system, not just one interview
Where I actually land on this
Lessons learned
Frequently Asked Questions
Is using AI in an interview always cheating?
Can I just ban AI and proctor everything?
How do eye contact and pause length hold up as cheating signals?
Do I need to disclose room scans or a second camera to candidates?
How is identity fraud (a proxy or deepfake candidate) different from AI-assisted cheating?
Related articles