How to Detect AI Cheating in Technical Interviews

The five reliable tells

None of these is a smoking gun on its own. In combination they justify a deeper probe — never an immediate reject.

Tell 1 — Latency mismatch

Candidate finishes reading the question (you can see their eyes move down the screen). A pause of four to eight seconds. Then a fluent, well-structured answer arrives at full conversational speed. People who think their way to an answer either start halting and refine, or pause and then deliver in fragments. The "long pause, then complete answer" pattern correlates with reading from a generated transcript.

Tell 2 — Eye-glance pattern on video

Eyes drift to a side monitor at predictable moments: just after each question is asked, then again before the answer begins. The candidate is reading the AI overlay. Reliable when paired with latency mismatch; ambiguous in isolation because candidates legitimately glance at notes.

Tell 3 — Prosody and pacing

Genuine answers have natural stress patterns and uneven cadence. AI-read answers have even pacing, slightly over-articulated emphasis, and a tendency to deliver in complete sentences without filler. The pattern is most audible on STAR-format behavioural answers, where genuine recall produces "uh, so this was about three years ago, and we had…" and read answers produce "Three years ago, my team faced…"

Tell 4 — Follow-up brittleness

The 2-follow-up rule: ask "why did you pick X over Y?" and then "what would change if the input scaled 10x?" Candidates who thought their way to the original answer can sustain the defence. Candidates who used AI for the initial answer usually run out of detail after the first follow-up and produce a generic restatement on the second.

Tell 5 — Correct but generic

The answer is right, but missing the project-specific colour that genuine experience produces. No names of teammates, no specifics about the codebase, no surprising constraint, no thing-that-didn\'t-work. AI-generated answers default to platonic best-practice; lived experience defaults to specific weirdness.

The false-positive traps

Non-native English speakers

Latency mismatch is unreliable when the candidate is translating internally before speaking. Prosody patterns shift; pacing is uneven for reasons that have nothing to do with AI. Penalising these patterns is both unjust and legally exposed. If your interview process penalises non-native speakers as a side effect of "AI detection," you have built a discrimination engine, not a hiring funnel.

Neurodivergent communication patterns

Some candidates pause longer before speaking, deliver answers in unusually structured form, or sound "scripted" by neutral observers. None of this is AI. The same patterns that trigger AI-cheating suspicion are often the patterns produced by neurodivergent thinking styles — which the ADA in the US and equivalent laws in the EU explicitly protect.

Prepared from notes

Reading from prepared notes during behavioural interviews is a legitimate practice. Some candidates write out STAR-format answers in advance and refer to them. The result can look like AI-read prosody. The cure is to ask candidates to disclose what they have prepared and to follow up specifically beyond the prepared answer.

Interviewer bias against "too polished"

The most pernicious false positive: an answer that is well-structured, articulate, and on-topic gets flagged as AI because it is too good. This penalises the well-prepared candidate and rewards mediocrity. Train interviewers explicitly that polished is not a tell on its own — the supporting signals (latency, eye-glance, follow-up brittleness) have to confirm it.

Structural defenses that work better than detection

Pair programming

A senior engineer in the room can ask follow-up questions in real time, raise alternative trade-offs, and read the candidate\'s collaboration patterns. AI assistance is essentially useless under these conditions. See our pair programming interview spoke for the operational details.

Live solution defence

Have the candidate walk through a problem out loud before they write any code. No coding window, no whiteboard, just spoken reasoning. AI cannot whisper a coherent system-design defence into someone\'s ear in real time, especially when the interviewer is interrupting with adversarial follow-ups.

Narrate while coding

Even when the candidate is at a keyboard, require them to narrate what they are doing and why. Combine with adversarial mid-flow questions ("what happens if we removed this line?"). The cognitive load of pretending to think while typing AI-suggested code while answering questions in real time is too high to fake for long.

Behavioural follow-up depth

For non-technical signal, the 2-follow-up rule plus specificity probes are remarkably effective. "Who else was on the team?" "What was the deadline pressure?" "What did the post-mortem find?" Genuine answers gain detail with each follow-up; AI-assisted answers lose it.

The unifying principle: design the interview so that being in the room is the value, not just being able to produce a correct answer. See AI-resistant interview design for how to fit these into the broader funnel.

Related guides