AI cheating in scenario and behavioural interviews

MatchCard · 21 July 2026 · 6 min read

Quick answerMost AI-cheating detection tools are built for live coding interviews, watching for tab-switching or suspicious code timing. Scenario and behavioural interviews, the format most non-technical roles actually use, have no equivalent signal, leaving them largely unguarded even as AI-generated answers become common there too.

Search "AI interview cheating detection" and almost everything that comes back is built for one scenario: a live coding interview, watched for tab-switching, screen anomalies, or code that appears faster than a human could type it. That's a real problem worth solving. It's also a small slice of hiring. Most roles, sales, operations, customer success, account management, don't run a coding round at all. They run scenario and behavioural interviews, and almost nothing in the AI-cheating-detection market currently covers that format.

Why coding-interview detection doesn't transfer

Live coding-cheating detection works by watching a narrow, technical signal: keystroke timing, window focus, whether the candidate's problem-solving trace looks like a human thinking or a paste event. None of that exists in a scenario interview. There's no code to time, no IDE to watch, often no live session at all, just a written or recorded answer to "tell me about a time you had to deliver bad news to a client." The behaviours that give away a coding cheat simply have no equivalent here.

That gap matters because scenario and behavioural formats are already where a lot of AI-assisted answering happens. 38.5% of a 19,368-interview sample showed clear AI-cheating signals, and in a related survey of hiring professionals in the same research, 91% said they'd encountered or suspected AI-generated answers in online meetings. Meetings, not code editors. This is squarely a scenario-and-behavioural-interview problem, in a market where most detection tooling is pointed elsewhere.

What a generated scenario answer actually looks like

A candidate pastes "tell me about a time you managed conflicting priorities" into a chatbot and gets back something fluent, structured, and, on the surface, plausible. It's also detectable, if you're reading for the right things rather than scanning for the wrong ones:

• It's specific to nothing. Real accounts of real events carry unfakeable residue: an oddly precise number, a detail nobody would bother inventing, a name withheld but a shape still visible. Generated answers are smooth and could belong to anyone in any company.
• It answers the topic, not the question. A well-built scenario question is engineered to force a specific disclosure, a trade-off made, a mistake owned. Generated answers routinely produce a competent essay on the general topic while quietly avoiding the actual disclosure the question was built to extract.
• It doesn't survive cross-examination. One polished answer is cheap to fake. The same claim checked against the CV, the salary conversation, and two other answers in the same assessment is a different, much harder problem: details drift, the self-described seniority doesn't match the story, the timeline stops adding up.

Reading, not scanning

This is the same underlying approach covered in more depth in our broader look at how candidates cheat hiring assessments, applied specifically to the format most vendors ignore. MatchCard's authenticity engine runs three reasoning passes on every written answer, Deep Read, Cross-Check and Evidence Trail, before producing a verdict: reading each answer for whether it addresses what the question was built to surface, checking it against everything else the candidate submitted, and anchoring every flag to a quoted piece of evidence rather than a black-box percentage. It was built around scenario and behavioural formats from the start, not retrofitted from a coding-interview tool.

Frequently asked