How to Stop AI Cheating in Coding Assessments: A Threat-by-Threat Guide

In one line: no single feature makes a test AI-proof. Match each anti-cheating control to the threats the roles you hire for actually face. Against the everyday threats (an invisible overlay assistant, in-browser AI, a second device) you need a hard lockdown and webcam proctoring together.

Key points

• The most common cheating method in 2026 is invisible to screen sharing: an invisible overlay assistant, a hidden app that reads what's on the candidate's screen and shows them the answer in a translucent window only the candidate can see. What stops it is a lockdown that keeps the app from running on the test machine.
• Choose stronger controls for the threats you actually face: in-browser AI needs only light screen monitoring. A hidden overlay assistant needs a hard lockdown. A second device needs webcam proctoring. If you buy a proctoring feature before you have mapped your threats, you can end up with heavy monitoring against one risk while another risk stays uncovered.
• Some threats have no product that fully stops them: a real-time deepfake or a fully offline second device can slip past any control. For those two, either accept the risk or move the check to a later stage, such as an in-person interview as the last step that verifies both key skills and identity.
• Start from your threats, then find the plan that covers them: list the threats that apply to the roles you hire for, using the six threat sections below, and check which of a vendor's plans defends each one. A vendor's blanket claim to be AI-proof tells you nothing until you see what its plan covers at the price you would pay.

On this page

• Which AI-cheating threats should you plan for?
  • Invisible overlay assistants on the candidate's computer: hidden apps that feed answers during the test
  • In-browser AI: a chatbot in another tab
  • Second device: a phone or tablet used off to the side
  • Live interview AI assistants: real-time answers during a video interview
  • Impersonation and deepfakes: someone else takes the test
  • Repeat attempts and leaked questions: the test itself is compromised
• Which tool covers which threat?
• Does stronger anti-AI proctoring hurt candidate experience?
• How should you choose an anti-AI assessment approach for your situation?
• Anti-cheating assessment FAQ

Which AI-cheating threats should you plan for?

What vendors sell as AI proctoring is a set of separate defenses against separate threats, so work out which threats your roles face before buying. A typical candidate who cheats uses one of three things: an invisible overlay assistant on their computer, a chatbot in another browser tab, or a second phone or laptop used off to the side. Most buyers should assume all three. Someone else taking the test, deepfakes, and leaked questions are narrower threats and matter only for some roles.

Invisible overlay assistants on the candidate's computer: hidden apps that feed answers during the test

An invisible overlay assistant is a hidden app on the candidate's own computer that reads the question and feeds them the answer during the test. You cannot reliably detect one from inside the browser, because it hides from screen capture. You prevent it with a hard lockdown that stops the app from launching on the test machine. It is the most common form of AI cheating in 2026. Tools like Cluely, LockedIn AI, and Interview Coder are the well-known examples. In a 2026 Fabric study of nearly 20,000 technical interviews, dedicated assistants like these were the single largest category of cheating.

Trying to catch an overlay assistant from inside the browser does not work. The app flags its own window to be excluded from screen capture, so a recording or a screen share shows the desktop straight through it, as if nothing were there. And because the app runs outside the browser and never touches it, a browser-based proctor has almost nothing to observe.

The protection is a lockdown app, a small application the candidate installs and takes the test inside. Five of the vendors compared here offer one. With TestDome specifically, the lockdown app is included with every pack, self-serve. HackerRank ships its App too (its integrity marketing page still says coming soon, but the app is available) and gates it to Pro. HackerRank lists Pro at $4,490 a year or $449 a month, so confirm at purchase. The full TestDome vs. HackerRank comparison works through what that tier gates. Codility's Desktop App is in Preview and reserved for its contact-sales Custom plan. Mettl's is contact-sales only. iMocha's Safe Assessment Browser, a lockdown app with VM detection, is contact-sales as well.

The overlay-assistant tools themselves (Cluely and its peers) also ship an off-device mode that runs on a second phone, which no lockdown can reach. That case belongs to the second-device threat covered below, where the defense is a camera.

In-browser AI: a chatbot in another tab

The oldest and simplest form of AI cheating is a candidate opening ChatGPT, Gemini, or an AI coding assistant in another browser tab or window during the test. Because that tab is visible on the screen, lighter screen monitoring is enough to catch it. No full lockdown is required. It is the crudest method and, for that reason, a shrinking share of cheating as candidates move toward the hidden apps above. Copy-paste protection covers the common way a candidate moves an answer from the AI into the test, and screen monitoring flags browser DevTools, the hidden developer console built into every browser, when it is opened. None of this forces the candidate into a locked-down app.

Choosing this lighter control over the full lockdown is a decision about trust and candidate experience, and it depends on your threat exposure. The hard lockdown, which also blocks app switching and restricts web access to the test itself, is what you add when you also need to stop invisible overlay assistants. Either covers in-browser AI. Vendors with neither are relying on softer signals like tab-focus loss, which a determined candidate can work around.

Second device: a phone or tablet used off to the side

When a candidate uses a separate phone, tablet, or laptop, that device runs outside anything the test machine controls, so no lockdown can reach it. Your defense here is a camera. A webcam can detect the candidate looking away or a device in frame, and a second camera widens that view. The second device might be running a chatbot, connecting the candidate to another person, or running a live interview AI assistant in its phone mode. That mode is marketed as running "on a separate device, no download, undetectable." The defense is the same in every case, because you are catching the device itself, whatever happens to be running on it.

Vendor coverage differs here. Mettl markets a 360-degree dual-camera setup that uses the candidate's own phone as a second lens. By Mettl's own description, that setup is the deepest second-device coverage in this comparison. With TestDome specifically, webcam proctoring uses a single camera to detect off-screen glances, a visible phone or tablet, multiple people in frame, or the candidate stepping away. The webcam catches a phone used off to the side, though not a device held fully out of frame.

Live interview AI assistants: real-time answers during a video interview

During a live video interview, a tool like Sensei or Final Round AI listens to the interviewer's spoken question and feeds the candidate an answer within a second or two. The live human interviewer is no longer a reliable proctor. This threat only matters if you run live coding interviews, and no vendor has a test-time product fix. A live interview cannot be locked down, and the AI assistant runs off audio on a second device that nothing on the test machine sees. Specialized live-interview platforms like CoderPad and CodeSignal apply in-session signals, such as a full solution appearing in seconds after no typing. These signals help but do not close the audio path. The dependable response is interview design: ask unpredictable follow-up questions, and make the candidate explain and change their own code. A live interview AI assistant built to answer predictable questions cannot survive that kind of interview.

Impersonation and deepfakes: someone else takes the test

Impersonation means the person taking the test is not the person you are hiring, whether a plain stand-in or a real-time deepfake that puts a synthetic face on camera. Impersonation is a narrow threat, mainly for remote-contractor and security-sensitive roles. The response is a formal ID check placed somewhere in your hiring funnel. iMocha, CodeSignal, HackerRank, Mettl, and TestGorilla verify a government or photo ID inside the test itself. CodeSignal includes ID verification un-gated on its cheapest self-serve Build plan. With TestDome specifically, the webcam confirms someone is present but does not check a document. If you assess with TestDome, run the formal ID check at another stage of the funnel.

Deepfakes are the hardest case. No vendor, including TestDome, has a verified defense, so a proctored score cannot prove identity against one. For most volume hiring, deepfakes are not a realistic risk.

Where deepfakes are a risk, for remote contractors or security-sensitive roles, TestDome's recommendation is a sequence that spares most candidates the friction of a formal ID check. Record webcam video through every stage, which costs little. Run the heavier ID check only on the finalist, at the offer stage. Then have that check confirm the finalist is the same person who appears in the earlier recordings. TestDome supplies the webcam recording. The ID verification and the continuity matching are the job of a dedicated ID-verification provider, and one provider usually offers both. Running the sequence is outside TestDome's scope. The sequence catches a stand-in. A deepfake used consistently from the first recording to the last will still get through. Continuous recording also carries the same biometric-data retention cost that the candidate-experience section below weighs.

Repeat attempts and leaked questions: the test itself is compromised

Two related things can undermine the test itself: the same candidate taking it more than once to improve their score, and the questions leaking so candidates arrive already knowing the answers. The response to both is test design. It matters most when you run the same test at high volume. With TestDome, duplicate attempts from the same IP address or browser are flagged. The flag detects a likely repeat rather than blocking it. A determined repeat taker on fresh hardware and a new network can still get through, though a candidate who does not suspect the check has no obvious reason to switch machines. For leaked questions, where questions circulate between candidates or get posted online, the general counter is a large pool of questions drawn at random, plus plagiarism checks that catch copied answers. Most vendors offer some form of this.

Which tool covers which threat?

Read TestDome's own row honestly. It has no formal ID-document step. On impersonation it trails iMocha, CodeSignal, HackerRank, Mettl, and TestGorilla, all of which verify a government or photo ID. And on second-device coverage, its single camera gives real coverage but does not match the dual-camera depth Mettl markets.

Where TestDome holds up is the lockdown app. TestDome includes it self-serve with every pack, with no Pro plan or sales call between a buyer and the control that shuts out on-device overlay assistants. HackerRank, Codility, Mettl, and iMocha all offer the same kind of app but gate it: HackerRank to Pro, Codility to Preview/Custom, Mettl and iMocha to contact-sales. The protection exists across all five of them. What varies is the access and the price. CoderPad is a special case. It declines photo ID by policy and reserves its webcam for the Custom plan. Its integrity model therefore rests on the live human interviewer, exactly the person a live interview AI assistant is built to fool.

Does stronger anti-AI proctoring hurt candidate experience?

Yes, meaningfully, along three specific axes: candidates drop off when the process feels invasive, stricter monitoring raises real privacy exposure, and heavier verification carries bias and legal risk if it's not applied consistently. It is a genuine tradeoff that no vendor has made disappear, though some design choices soften parts of it.

Candidate drop-off is the most visible cost. A lockdown that disables screenshots and restricts web access, combined with webcam proctoring, feels heavy to a candidate weighing several offers at once. Some candidates will abandon the test. Privacy is the second axis. Continuous webcam and screen recording, and especially formal ID verification, sit close to biometric-data rules like BIPA in the US and GDPR's special-category data provisions in the EU. Mishandling that data creates liability whether or not the proctoring itself worked. Bias and legal exposure is the third axis. An identity-verification step that performs unevenly across demographics is a discrimination risk built into the control itself. So is monitoring that disproportionately flags candidates using older hardware or slower connections.

One source of candidate distrust can be lowered by design. Asking a candidate to install a proctoring app raises a fair question: what does this thing on my machine actually do? That concern is why TestDome runs its lockdown on Safe Exam Browser, the open-source secure browser developed and maintained by ETH Zurich, rather than a proprietary app of its own. An independent, university-built tool that candidates can inspect is easier to trust than a vendor's closed application. Many candidates will recognize it from their own university exams. The choice does not remove the install or the monitoring, but it answers the what-is-this-app worry with something a candidate can check.

None of that means proctoring isn't worth using. It means the level of control should follow your actual threat exposure and the friction you can impose without losing candidates. How senior the role is makes a poor guide. If anything, an in-demand candidate with other offers is the one most likely to walk away from a heavy, distrustful process, so seniority often argues for less intrusive proctoring. If candidate experience is a primary concern for your funnel, the same discipline that makes a test feel relevant and transparent keeps completion rates up. Our guide on candidate experience in coding assessments covers that discipline in depth.

How should you choose an anti-AI assessment approach for your situation?

Choose by threat. Decide which of the threats above apply to the roles you hire for, then check which vendor covers those threats on the plan you'd realistically buy. Your exposure and your tolerance for candidate-experience friction set the level of control.

If impersonation is a real risk for your roles, treat it as a process decision. Somewhere in your funnel you need a real identity check. The check can sit at one point, at several, or at every stage. What matters is choosing deliberately where it goes. You have three options:

• Put it in the test itself with a tool that verifies a government ID (CodeSignal includes this un-gated on its cheapest self-serve plan, and iMocha and Mettl verify ID as part of their contact-sales offerings).
• Keep it out of the test to reduce friction and run it at the offer stage.
• Do both.

And because no vendor has a defense against a real-time deepfake, keep a final human step, a live interaction or a reference check, wherever identity really matters.

Anti-cheating assessment FAQ

How do I prevent AI cheating in coding assessments? Match the control to the threat. For in-browser AI, screen monitoring with copy-paste protection catches the common case at low friction. To also stop invisible overlay assistants, add a hard, OS-level lockdown so the overlay app can't launch on the test machine. Add webcam proctoring to catch a second device, and formal ID verification if impersonation risk matters for the role.

Can you stop ChatGPT cheating on a coding test? Yes, for the common case. A hard lockdown blocks access to ChatGPT and every other site on the test machine during the test. If a candidate finds a way around the block, screen proctoring can separately detect visible use of AI tools, screenshot software, or browser DevTools. What no lockdown reaches is a fully local, offline AI model running on a separate, unmonitored device, because that device sits outside anything the test machine controls. This gap is why a webcam or dual-camera check matters as a companion to the lockdown.

Can invisible AI overlay assistants be detected? Not from inside a normal browser. Overlay assistants hide from screen capture and run outside the browser. The dependable protection is a lockdown app that the candidate takes the test inside, which TestDome, HackerRank, Codility, Mettl, and iMocha all offer. They differ mainly on price and access.

What about a second device or a deepfake? For a second device, the defense is a camera. The table above shows each vendor's coverage, from TestDome's single webcam to the dual-camera setup Mettl markets. Deepfakes are a narrower concern. They are mainly an organized-fraud threat aimed at remote and security-sensitive roles, rarely something a typical candidate attempts in a coding test. No vendor, including TestDome, has a verified real-time defense, so if that threat applies to your hiring, add a later identity check so a stand-in cannot turn a clean score into a hire.

Does AI proctoring hurt candidate experience? It can, and the three costs (drop-off, privacy exposure, and bias or legal risk if verification isn't applied evenly) are weighed in the candidate-experience section above. The answer is not to drop proctoring but to fit its intensity to your threat exposure and the friction your candidates will accept.

What actually works for AI proctoring on coding assessments in 2026? There's no single answer, because coverage is per-threat and the market has not solved AI cheating as a whole. On the test machine, a hard lockdown reliably stops in-browser AI and keeps overlay apps from launching. Formal ID verification addresses impersonation better than presence checks alone. Deepfakes and live interview AI assistants have no test-time product fix, so handle the first with an identity check at a later stage and the second with interview design. Beyond that, rely on an unaided-skill score from a job-relevant work-sample test so the threats nobody has solved don't decide who gets hired.

Start your 14-day TestDome trial