Coding Test Cheating: Prevention Without Proctoring Theater

Invasive proctoring — webcam surveillance, eye-tracking, full screen recording, periodic screenshots — has a documented record of alienating strong candidates, producing false positives on disabilities and neurodivergent traits, and failing to stop determined cheaters anyway. There is a better model. It does not require treating every candidate like a suspect.

How coding tests get cheated

The vectors differ between live and asynchronous formats:

Live coding sessions (with an interviewer present on a call) are most commonly assisted by a covert AI assistant running on a secondary monitor or a second device. The candidate reads the problem, queries the AI, and presents its output as their own thinking. Fluent, block-delivered answers following a brief pause are the primary signal. We cover the full signal set in How to Detect AI Assistance in Remote Interviews.

Asynchronous take-home tests face a different problem: there is no session to monitor, so any answer could have been produced with any tool. Integrity monitoring does not help here — the only real mitigations are question design (open-ended, context-specific questions that cannot be answered well by an LLM without deep knowledge of the candidate's claimed experience) and a follow-up live discussion where the candidate explains their solution.

What proctoring theater gets wrong

Full-screen-recording proctors fail for several reasons:

• They do not stop phone-based cheating. A candidate can have ChatGPT running on a phone in their lap. No screen recording system sees that.
• Eye-tracking and gaze detection produce poor signals for code. Engineers look around while thinking — at whiteboards, at previous lines, at the ceiling. A system trained on essay-writing behaviour flags normal coding patterns as suspicious.
• Strong candidates opt out. Surveys of senior engineers consistently show that invasive proctoring is a significant deterrent. At the senior end of the market — where candidates have options — asking someone to submit to full-screen recording for a coding test is a meaningful filter against the people you most want to hire.
• The evidence is not useful. Hours of screen recording produce a volume of data that no human reviewer can process. False positives require manual investigation of lengthy recordings. The signal-to-noise ratio is poor.

What actually works

For live sessions: metadata-only integrity monitoring. Process presence, window focus events, clipboard timing, and input cadence catch desktop AI assistance reliably without recording anything. The candidate experience is indistinguishable from an unmonitored interview — there is nothing to disable, no permission to grant, no webcam to position. The signal report arrives automatically at session end.

For take-home tests: question design and follow-up. Questions that require the candidate to reason about a specific codebase, a specific architectural tradeoff, or a scenario that requires synthesising their own experience cannot be answered well by a general-purpose LLM. Follow up every take-home with a 20-minute live discussion where the candidate explains their approach — a candidate who did not write the code cannot walk through it fluently under follow-up questions.

For both: disclosure and deterrence. Stating clearly in the job posting and the interview invitation that integrity monitoring runs on live sessions deters a large portion of opportunistic cheating without monitoring anyone. Candidates who would have used a covert tool often decide not to bother.

For the full recruiter guide covering live and async formats together, see The Remote Hiring Integrity Playbook. For the checklist version, see Technical Interview Integrity Checklist.