# AI interview cheating detection for employers

> AI interview cheating detection works best through adaptive tasks, corroborated signals, and structured scoring rather than screen watching.

Cluely and Interview Coder have made visual detection a bad foundation for interview integrity. Both vendors describe native overlays that listen to audio or read the screen, generate answers during the call, and keep their windows out of ordinary screen shares. An interviewer can watch a clean shared desktop while the candidate reads an answer that the interviewer cannot see.

That does not make the tools unbeatable. It makes the old interview brittle. Employers should separate three questions: what the interview software recorded, what behavior the interviewer observed, and whether the candidate can repeatedly demonstrate the claimed skill when the task changes. The third question produces the strongest hiring evidence. The first two should trigger verification, not an automatic rejection.

## Hidden overlays defeat screen watching

A clean screen share does not prove that the candidate worked alone. Cluely says it can hear meeting audio, view the screen, and return live answers in a movable window. Interview Coder says its desktop app captures a coding problem through a shortcut, generates code plus reasoning and complexity analysis, and displays the result in a click-through overlay. Both market invisibility during screen sharing as a feature.

The mechanism is less mysterious than the marketing. Modern operating systems let an application mark a window for exclusion from some capture paths. Microsoft's documentation for `SetWindowDisplayAffinity` includes `WDA_EXCLUDEFROMCAPTURE`, which omits a window when the desktop compositor handles capture. Apple's ScreenCaptureKit gives applications fine control over selected displays, apps, and windows. A conferencing application receives frames after those choices have been applied, so it may never receive the excluded overlay.

Microsoft also says display affinity is not a security or digital rights management guarantee. Capture behavior varies with operating system version, sharing mode, and the application doing the capture. Cluely's own guide lists compatibility exceptions for some hardware, operating systems, and full-screen sharing combinations. These qualifications matter, but they do not rescue a detection plan based on asking candidates to share the whole desktop. Sometimes the overlay leaks into the share; often it does not. An employer cannot build a fair process around hoping for a leak.

The same limitation applies to screenshots and recordings made through the ordinary capture pipeline. A second physical camera could see the actual monitor, and managed corporate hardware could inspect running processes, but forcing either into a remote hiring process creates privacy, legal, and candidate-experience problems. It also selects for willingness to accept surveillance rather than ability to do the job.

Treat screen sharing as collaboration. It lets the interviewer follow the candidate's code and discussion. Do not treat it as an x-ray of the candidate's computer.

## Platform alerts are leads, not verdicts

Interview platforms can record events inside their own environment, but a separate native assistant may leave few browser events. A web page can observe focus changes, paste events, edits, and some display information that the browser exposes. It generally cannot enumerate unrelated desktop windows or read their contents. That boundary explains why an overlay can stay outside a browser proctor's view.

CoderPad's Playback documentation says the service records keystrokes in the pad and marks external paste events and moments when the candidate leaves the IDE. The same documentation warns that either event can have an innocent explanation. HackerRank's Interview Integrity Signals groups repeated actions such as copy and paste, tab switching, and window resizing. Its documentation also says pasted content does not always mean misconduct.

Read those caveats as operating instructions. A single paste is weak evidence. A focus loss is even weaker because password managers, accessibility software, notifications, browser developer tools, and an interviewer's own request can cause it. Repeated pasted blocks that arrive immediately after each prompt deserve a follow-up, especially when playback shows no intermediate edits. They still do not identify Cluely, Interview Coder, or any other specific tool.

The strongest telemetry has a time relationship to an observed capability gap. Suppose the timeline shows a 25-second pause, then a complete unfamiliar algorithm appears through a paste, and the candidate cannot trace its state on a four-element input. That combination warrants concern. If the candidate explains every invariant and modifies the solution correctly, the paste may have come from a permitted local editor.

Preserve raw event times and interviewer notes instead of writing "candidate cheated." Facts survive review; conclusions harden too early. Record what appeared, when it appeared, what verification question followed, and how the candidate responded.

## Identity controls solve a narrower problem

Identity verification, browser monitoring, and AI assist detection are often bundled under "interview integrity," but they answer different questions. An identity check asks whether the applicant and interview participant are the same person. Browser telemetry asks what happened in the assessment page. A skill probe asks whether the participant controls the work. Passing one says little about the others.

Keep those controls separate in policy and in the evidence record. A face match cannot show that no assistant ran. A tab-switch alert cannot show that another person took the screening test. Strong technical performance in a live round does not resolve an identity mismatch. When employers merge these signals, reviewers tend to treat several weak alerts as mutual confirmation even though they concern unrelated risks.

An in-person interview reduces some remote assistance options, but it does not justify returning to an expensive process for every role. Candidates can still use wearables or memorize supplied answers, while travel requirements shrink the pool and burden people with caregiving or disability constraints. Use an on-site stage when physical presence reflects the job or when the hiring risk supports the cost, not because the company has failed to design a good remote exercise.

A company-owned assessment device gives administrators more technical visibility. It can restrict applications and network access without searching a candidate's personal machine. That may suit high-stakes regulated work, but shipping and managing hardware for ordinary startup hiring is rarely proportionate. A locked device also prevents candidates from using their normal accessibility setup unless the company plans accommodations carefully.

Proxy interviewing needs a different response from overlay use. Confirm identity at stated points in the process, keep interviewer handoffs clean, and compare live capability with earlier work when the difference is material. Do not use accent, appearance, or a name discrepancy as a shortcut. Ask for the minimum information required by a written process and escalate through the same review path for every candidate.

The practical goal is not a perfectly observed room. It is enough independent, job-related evidence to make a hiring decision. Two short live exercises on different days can sometimes produce better confidence than an hour of invasive proctoring. The candidate must maintain the same depth, terminology, and ownership across contexts, while the company gets another sample without pretending it can see every screen.

## Human signals only matter in clusters

No gesture proves tool use. Looking slightly off-center may mean the video tile sits beside the editor. Long pauses may reflect thought, audio delay, a second language, or an accommodation. Smooth speech may come from preparation. Nervous speech may come from being interviewed. Anyone who claims to detect cheating from eye movement alone is selling confidence, not accuracy.

Assist tools do create recurring coordination costs. The candidate must listen to the interviewer, trigger or wait for the assistant, read its output, decide whether it fits, and speak while making the code appear. That divided attention can produce clusters an experienced interviewer should investigate:

- Silence followed by a sudden polished answer whose vocabulary differs from the candidate's earlier explanation.
- Code that appears faster than its author can explain, especially with comments or abstractions that were never discussed.
- Repeated answers aimed at the previous question after the interviewer adds a constraint.
- Confident use of a library call that does not exist or does not behave as claimed.
- An inability to predict the next executed line without rereading a visible or hidden explanation.

None of these signs should become an amateur body-language score. Use them to choose the next job-related probe. "Show me where this invariant is established" is useful. "Why are your eyes moving?" is accusatory, easy to answer, and unrelated to engineering work.

Interview Coder explicitly says it supplies line comments and reasoning so a candidate can explain generated code. Cluely lets a user move the window toward the normal sight line. Employers should assume basic explanations and gaze checks have already been anticipated. A capable assessment must demand interaction with the work, not a performance of looking busy.

Consistency across several small probes matters more than one dramatic gotcha. A genuine engineer can misunderstand a prompt and recover. An assisted candidate can also answer some follow-ups well. The decision should rest on a pattern of demonstrated control over the solution.

## Tool fluency and concealed substitution are different

Using AI is not automatically cheating. Concealing a prohibited assistant during an assessment is a policy violation; using an explicitly allowed assistant can be a relevant job skill. Employers create confusion when the invitation says "technical interview" and leaves candidates to guess whether documentation, search, autocomplete, or generative AI is allowed.

Set the boundary in writing before the interview. Name what candidates may use, what they must disclose, and what part of the evaluation measures unaided reasoning. If the job expects engineers to use Claude Code, Codex, or similar tools, banning them for the entire process can test an obsolete workflow. If the role requires independent diagnosis during an outage or security incident, an unaided segment has a clear job basis.

A workable policy might say: "You may use language documentation and the editor's standard completion. Do not use a person or AI service to generate answers during the first exercise. The second exercise allows AI, but you must share the prompts and verify every change." That wording gives the interviewer two distinct samples. It also removes the candidate's excuse that the rules were implicit.

Disclosure changes what the interview can measure. In an AI-allowed segment, score problem framing, prompt judgment, testing, correction, and ownership of the final answer. A candidate who accepts a plausible but broken result has shown poor engineering judgment even while following policy. In the unaided segment, reduce scope and assess decomposition, debugging, and communication rather than memorized syntax.

Apply the same rules to every candidate for the same role, and provide a clear accommodation route. The U.S. Equal Employment Opportunity Commission says employment tests must be job related and employers may need to provide reasonable accommodations. Local requirements vary, so legal counsel should review recording, identity, and monitoring practices. More surveillance is not a neutral substitute for a valid test.

## Adaptive questions expose borrowed understanding

The best defense is a task that changes in response to the candidate's decisions. An assistant can generate a standard solution quickly. It has a harder time preserving a coherent mental model while the interviewer introduces a new constraint, points to a failed test, or asks the candidate to compare two imperfect choices.

This does not mean inventing riddles. Use a small problem with observable state and several legitimate approaches. Let the candidate state assumptions before coding. Once the first version works, change one condition that resembles actual product work. The interviewer should know why each change matters and score the reasoning, not whether the candidate guesses a preferred trick.

For example, begin with an in-memory function that groups events by account and returns the latest event. After the candidate has a working version, apply this sequence:

1. Ask what happens when two events share a timestamp, and require a deterministic rule.
2. Limit memory so the full input cannot be retained, then ask which guarantee must change.
3. Provide one failing test caused by out-of-order input and ask the candidate to diagnose it aloud.
4. Request a minimal metric that would reveal dropped or late events in production.

Each turn depends on the current implementation. A generic generated answer becomes stale as soon as the state changes. The candidate must point to code, predict behavior, edit a narrow area, run a test, and interpret the result. Those actions reveal ownership without requiring the interviewer to prove which application is running.

Do not fire questions rapidly just to outrun a model. That punishes thoughtful candidates and turns latency into a proxy for ability. Give normal thinking time, then ask for concrete predictions. The useful pressure comes from continuity: every answer must remain compatible with the code and decisions already on screen.

Ask for alternatives when a candidate produces a polished solution immediately. "What simpler version would you ship if this processes 500 records a day?" tests judgment. "Which input breaks your current assumption?" tests boundary awareness. These are ordinary engineering questions, and that is why assist tools cannot reliably fake them for someone who lacks the underlying skill.

## Debugging reveals more than blank-page coding

A debugging exercise produces stronger evidence than a fresh algorithm because the candidate must gather facts from a system they did not author. Generators are good at producing plausible code from a clean prompt. They are less dependable when the decisive clue lives in a log line, a misleading variable name, a test fixture, and the order of two state transitions.

Choose a compact repository that runs locally in the interview environment. Include one realistic defect, enough tests to establish expected behavior, and one irrelevant clue. The issue should match the role: a stale cache entry for a backend engineer, an effect cleanup error for a frontend engineer, or a retry that duplicates a message for a platform engineer. Avoid obscure framework trivia.

Ask the candidate to narrate observations separately from hypotheses. "The second request returns the first user's value" is an observation. "The cache key ignores the user ID" is a hypothesis. Candidates who can maintain that distinction tend to test before rewriting. Candidates reading generated guidance often jump straight to a confident cause and then struggle when the first patch fails.

The interviewer should introduce one controlled surprise after the initial fix. Change the test data, enable parallel execution, or reveal that the dependency retries. Then ask whether the patch still holds. This is not a trap if the new fact resembles work the role actually involves and every candidate receives an equivalent change.

Watch the edit trail. Genuine debugging usually includes inspection, a small experiment, a failed or confirming result, and a focused change. An assistant may still help a knowledgeable candidate, which is acceptable in an AI-allowed segment. In an unaided segment, a complete patch that arrives without any relationship to the evidence deserves verification. Ask the candidate to revert it and reproduce the causal chain in smaller steps.

Blank-page algorithm interviews mainly reward recall, rehearsal, and recognition of familiar problem families. Those are precisely the tasks an overlay can substitute for. Debugging and modification measure whether the person can take responsibility after the generated first answer stops matching reality.

## A scorecard should reward evidence of control

Score the same observable capabilities for every candidate. Do not add a secret "seems suspicious" category after an interviewer gets a bad feeling. A structured scorecard keeps integrity concerns connected to job performance and makes disagreements reviewable.

Use a four-point scale with behavioral anchors:

| Dimension | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
| Problem model | Cannot state inputs or constraints | Restates prompt but misses a major constraint | Builds a workable model and corrects gaps | Anticipates consequential ambiguity and tests it |
| Code ownership | Cannot trace the submitted code | Explains local lines but not control flow | Predicts behavior and makes a focused change | Compares alternatives and explains the tradeoff |
| Verification | Accepts output without checking | Runs a happy-path example | Chooses tests that cover stated risks | Uses failures to revise the model efficiently |
| Continuity | Contradicts earlier decisions | Needs repeated prompting to reconnect changes | Keeps code and explanation consistent | Incorporates new constraints without losing prior guarantees |
| Tool judgment | Hides or blindly accepts assistance | Discloses tools but cannot validate output | Uses allowed tools and checks their output | Rejects bad suggestions and explains why |

Calibrate interviewers with sample recordings or transcripts before using the scorecard. Have two reviewers independently score a few sessions, discuss differences, and tighten anchors that invite personality judgments. "Communicates clearly" is too vague. "States a prediction before running the test" is observable.

Keep integrity evidence beside, not inside, the capability score. A platform event log can say that three external pastes occurred. The capability score can say the candidate could not explain or modify the pasted code. A policy decision can then consider both. Mixing them into one number hides which fact drove the rejection.

Set the decision rule before interviews begin. For example, require at least a 3 in code ownership and verification for a senior engineering role, regardless of total score. A fluent candidate should not compensate for inability to test. A quiet candidate who controls the code should not lose to presentation polish.

## Respond to suspicion with a fixed protocol

When signals cluster, the interviewer should verify skill calmly during the session. An improvised accusation rarely produces useful evidence and can expose the company to inconsistent treatment. A fixed protocol helps the interviewer preserve the candidate experience while protecting the process.

First, note the exact event without labeling intent. Then ask a task-related question that requires control of the current work: trace a small input, change one constraint, remove an abstraction, or explain a failing test. If the answer remains disconnected, ask a second reviewer to examine the recording, code playback, policy, and notes after the session. Give the candidate a channel to explain an accommodation or permitted tool before making a final integrity decision.

Do not demand access to private files, browser history, messages, or process lists on a personal computer. Do not ask a candidate to pan a phone around a room unless the role and jurisdiction support a carefully reviewed proctoring requirement. These measures are invasive, easy to evade with another device, and likely to create more risk than evidence.

The interviewer's note should read like this:

```text
14:12:08 Prompt constraint changed from unique to duplicate timestamps.
14:12:31 Candidate pasted 18 lines; platform marked an external paste.
14:13:02 Candidate said the map preserves both events, but the code overwrites one.
14:14:10 Asked candidate to trace [A@10, B@10]; predicted two outputs.
14:15:04 Test returned one output; candidate could not identify the overwrite.
```

That record supports a decision about code ownership. "Eyes moved right and answer sounded like AI" does not. The protocol should end the exercise only when continuing cannot add useful evidence, such as repeated refusal to follow the stated rules. Otherwise, finish the structured questions and let the review process work.

## Redesign the interview before buying more detection

Detection products can add telemetry, but they cannot repair an assessment that rewards answer retrieval. If every candidate receives a familiar prompt with one expected solution, the company has built an ideal target for an assist tool. More monitoring adds friction around the same weak signal.

Run an audit of the hiring loop against the actual work. For each stage, name the capability, the evidence collected, the allowed tools, and the decision rule. Delete stages that measure the same thing twice. Replace at least one recall-heavy exercise with debugging or modification. Keep the task small enough that interviewers can follow every decision.

Version the interview materials like production code. Store the prompt, tests, scoring anchors, and approved follow-ups together. When a candidate reveals an ambiguity, decide whether it tested useful judgment or merely confused them, then update the package for future sessions. Rotate the surface details without changing the measured capability, so leaked prompts lose value while scores remain comparable.

Interviewer training is part of the control. A strong question fails when the interviewer gives away the answer, skips the adaptive change, or records impressions after memory has blurred the sequence. Run the exercise internally with engineers who did not write it. If they disagree about the expected behavior or cannot finish within the allotted time while speaking aloud, fix the exercise before using it on candidates.

Measure the loop after hiring. Compare interview dimensions with probation outcomes, code review quality, incident work, and manager feedback, using only data your employment policy permits. Do not claim validation from a few memorable hires. Look for dimensions that never affect a decision, interviewers whose scores drift, and tasks where nearly everyone gets the same result. The review may show that a beloved algorithm round adds cost without separating candidates.

This is also where engineering leadership and hiring economics meet. A company adopting AI in production needs people who can direct models and catch their mistakes. It still needs proof that those people understand the systems they will own. An effective loop measures unaided fundamentals in a bounded segment and AI judgment in a disclosed segment.

The Team & AI Audit I offer examines team workflows and AI adoption; the same discipline applies to a hiring loop because unclear ownership and weak verification become payroll problems after the offer. The point is not to purchase suspicion. It is to know which evidence justifies adding an engineer to the team.

Cluely and Interview Coder will keep changing shortcuts, capture behavior, and generated explanations. Chasing each release gives the vendor control of your interview design. Build questions that require candidates to preserve a working mental model as facts change, document what they actually do, and score that evidence consistently. A hidden overlay cannot supply durable understanding to someone who does not have it.