How to Detect ChatGPT During a Live Coding Interview
Technical screens are the single biggest target for stealth AI copilots — the questions are predictable and the answers are easy to feed. Here's what actually gives it away, live.
Technical interviews are the easiest kind of interview to cheat on with AI, for a boring reason: the questions are predictable. "Reverse a linked list," "explain event loop behavior," "walk me through Big-O for this function" — these are exactly the prompts a tool like ChatGPT (or a purpose-built wrapper around it) answers fluently, instantly, and consistently. A candidate doesn't need to be clever about it. They need a second screen and a script.
Why technical screens specifically are the easiest target
Behavioral interview questions vary enough between companies and interviewers that a generic AI answer often sounds slightly off — too generic, missing the specific context of the role. Technical questions don't have that problem. Question banks for "reverse a linked list" or "implement a debounce function" are public, well-documented, and answered essentially the same way by every reasonably capable model. That predictability is exactly what makes a stealth copilot's job easy: it doesn't need to understand your company, your team, or the specific role — it just needs to recognize a well-known problem type and produce a well-known answer.
This is also why technical screens tend to be where AI Detectability catches the highest volume of flags across a typical hiring pipeline: the questions are consistent enough that a live copilot performs almost identically every time, which is itself a detectable pattern once you're looking at more than one interview.
What a live copilot actually looks like from the other side of the call
It helps to know roughly what's happening on the candidate's end. Most tools in this category listen to (or read a live transcript of) the call audio, generate a suggested answer using an underlying language model, and display it somewhere your camera can't see — an overlay window positioned to look like a normal app, a second monitor angled just out of frame, sometimes a browser extension styled to blend into a completely unrelated tab. The candidate reads or paraphrases what's on screen in something close to real time. None of this requires any technical skill from the candidate beyond following along.
The tells that show up in a live coding screen specifically
- The explanation arrives before the confusion does. A candidate who's actually working through a problem usually narrates uncertainty first — "hmm, let me think about the edge case here" — before landing on an answer. A candidate reading a generated answer often gives the clean, structured explanation immediately, with the uncertainty missing entirely.
- Vocabulary that's oddly consistent with textbook phrasing. Real engineers describe the same concept differently depending on how they learned it. An answer that sounds like it was lifted from a well-written blog post or documentation, word for word, on a question that should produce a more personal explanation, is worth noticing.
- A perfect answer to a question they clearly didn't expect. Real hesitation on an unexpected question is normal. A flawless, structured answer with zero pause on a question you deliberately didn't warn them about is the opposite of normal.
- Explaining code they just wrote inconsistently. Ask a candidate to walk back through a solution they supposedly just typed themselves. Someone who wrote it can usually explain their own reasoning fluently. Someone who pasted a generated answer sometimes struggles to explain a specific line the same way they "wrote" it.
- A mismatch between typing speed and explanation quality. Someone genuinely reasoning through a hard problem usually types in bursts — pause, type a few lines, pause again. Code that appears in one smooth, near-constant stream, followed immediately by a polished explanation, is a pattern worth a second look.
A realistic example of how this plays out
Picture a mid-level backend candidate given a standard "design a rate limiter" prompt. They answer immediately, correctly, and clearly — token bucket, sliding window, the tradeoffs between them, all delivered in about ninety seconds with no false starts. On its own, that's just a strong answer. But when the interviewer changes one constraint mid-question — "what if this needs to work across multiple servers, not just one" — the candidate's second answer either takes a visibly longer pause than the first one did, or simply restates a version of the same generic answer without actually addressing the new constraint. That gap between fluency on the expected question and difficulty adapting to an unexpected follow-up is one of the more reliable live signals there is.
Why text-based cheating detectors alone get this wrong
A lot of the AI-text-detection industry was built for essays and written assignments — feed in a block of text, get back a probability score that it was AI-generated. Applied naively to a live spoken interview, this approach has a real, well-documented problem: general AI-text classifiers falsely flag non-native English speakers at a much higher rate than native speakers, because non-native phrasing patterns and AI-generated phrasing patterns can look statistically similar to a classifier trained mostly on native-English text. That's a serious bias problem for a hiring tool, and it gets worse, not better, in a technical interview where a lot of candidates are already communicating in a second or third language.
The fix isn't a better text classifier — it's checking against something more specific than "does this sound like AI wrote it." Matching a candidate's actual answer against what a known stealth copilot literally produces for that same question is a fundamentally different (and fairer) check than asking "does this sound too polished for a human."
What to actually do live, in the moment
- Ask for the messy part, not the answer. "What would break this?" or "what's the worst-case input?" — questions with no clean, memorized answer are harder for a copilot to feed convincingly.
- Change the constraint mid-question. "Same problem, but you can't use a hash map" — a live thinker adapts audibly. Someone reading a fixed script often can't adjust as fluently.
- Ask them to explain their own code back to you, out of order, a few minutes later, on a different line than the one they just wrote.
- Watch for the gap between question difficulty and response time, not just the answer's correctness — a hard question answered instantly is a bigger tell than an easy one answered instantly.
- Don't rely on a single tell. Any one of the signals above happens innocently sometimes. A cluster of them on the same candidate, across multiple questions, is what actually matters.
How common is this, really
| Year | Interviews with at least one AI-assisted answer flagged |
|---|---|
| 2023 | 6% |
| 2024 | 14% |
| 2025 | 24% |
| 2026 | 33% |
| 2023 | 6% |
|---|---|
| 2024 | 14% |
| 2025 | 24% |
| 2026 | 33% |
Rough share of technical screens flagged with at least one AI-assisted answer, based on aggregate detection trends. Individual pipelines vary — this is directional, not a universal rate.
A few common questions
Does this mean a candidate who answers confidently is probably cheating? No — confidence and fluency are normal in a strong candidate. The signal is the specific combination above: no hesitation on genuinely unexpected material, textbook phrasing on a question that should produce a personal answer, or difficulty adapting when a constraint changes. A confident candidate who also adapts fluently to follow-ups is just a strong candidate.
What if the candidate is simply well-prepared, not cheating? This is exactly why any single flag should be read as a signal worth a follow-up question, not an automatic rejection. Someone who over-prepared for a common question type will usually still be able to adapt when you change the constraint. Someone reading a live-generated answer often can't.
Is this worth worrying about for junior roles too, or just senior ones? If anything, junior technical screens are targeted more, not less — the question banks are even more standardized (data structures, basic algorithms), which makes them easier for a copilot to answer well regardless of the candidate's actual level.
Where this runs automatically instead of relying on you catching it live
Candit's AI Detectability reads the interview transcript in the background of every technical screen and checks it against reverse-engineered builds of the actual stealth copilots candidates use — including ChatGPT-based tools like Cluely — rather than a generic "does this sound like AI" classifier. When an answer crosses the threshold, it's flagged live, per speaker, with the exact line that triggered it, so you're not relying on catching the tell yourself in the middle of running the interview. That flag also comes with Counter AI, a follow-up to ask while you're still on the call, and the AI use report afterwards shows where in the screen AI help showed and how.
It's also worth being clear about why this still works against a tool that hasn't been named yet: Candit doesn't try to lock down a candidate's device or browser the way older proctoring tools do — there's no environment to escape, because the signal isn't what's on a screen, it's how the answer was actually delivered, read live from the transcript and audio as the interview happens. That's ongoing work, not a one-time build: reverse-engineering how candidates actually use these tools is retested on a roughly weekly basis as new copilots appear.
First session free. No card required.