How to Know if a Candidate Is Cheating in an Interview

You can tell a candidate is cheating in an interview by correlating behavioral tells with technical signals, because no single sign is proof on its own. Behavioral signs include a delay before answering, an unnaturally polished or generic tone, eyes repeatedly scanning a fixed off-camera point, and answers that hold up until a pointed follow-up and then collapse. Technical signs are more reliable: clipboard paste bursts during a live answer, a second monitor or virtual camera appearing mid-session, remote-access software running in the background, or a hidden overlay window invisible to screen share. Avoid deciding on nerves, eye movement, or gut feel alone, those create bias, especially in technical rounds. The dependable method is a documented checklist that combines question design, machine-level detection, and human review. Here's the one to run, strongest for live and technical interviews where the candidate performs in real time.

Use it as a starting point and adapt it to your pipeline. A checklist that is too long gets ignored; one that is too short leaves gaps. The items below are ordered by where they fall in the interview timeline.

Before scheduling the interview

• Define your AI-use policy in writing: what tools are permitted, what constitutes covert use, and what the consequence is.
• Decide on a monitoring approach. Integrity monitoring, all-display share, or both, and document it so all interviewers apply it consistently.
• Prepare a candidate disclosure that explains what will be monitored, what will not be collected, and how to opt out.
• Calibrate your questions to require reasoning, not recall. Questions that can be answered by pasting a Wikipedia definition or an LLM summary are not testing the skills you care about.

In the calendar invite

• Attach or link the monitoring disclosure so the candidate has read it before the day.
• Explain what software the candidate needs to install (if applicable) and include a test link they can verify in advance.
• State the permitted tools explicitly, IDE of their choice, standard library docs, specific reference URLs, so there is no ambiguity on the day.

At the start of the session

• Confirm consent verbally. A brief "you received our monitoring disclosure and are happy to proceed?" is sufficient.
• Verify screen sharing shows the expected environment. Coding IDE visible, no obvious second tabs in the title bar.
• Note any atypical setup the candidate mentions (network issues, older hardware) that might affect signal interpretation later.
• Confirm integrity monitoring is running and the session ID is recorded against the candidate record.

During the interview

• Note the timing of questions asked. This context helps a reviewer interpret signal clusters in the report.
• Follow up on suspiciously fluent answers with a "walk me through your reasoning", not as accusation, but as standard practice for all candidates.
• Do not coach or react to integrity signals in real time, let the monitoring system collect them and review after.

After the interview

• Review the integrity report before the debrief, not during it, signals should inform the discussion, not dominate it in real time.
• Treat the score as one input among technical score, interviewer assessment, and follow-up question quality, a high integrity score does not override a poor technical performance.
• Document your decision alongside the report, if a signal was reviewed and judged benign, note why, so the record is defensible.
• Store the signed report in the candidate's ATS record per your data-retention policy.

Question design checklist

• Use a problem close enough to real work that candidates must make tradeoffs.
• Prepare two follow-up constraints that require modifying the original solution.
• Ask the candidate to explain failed approaches, not only the final answer.
• Decide in advance whether docs, search, AI, snippets, or notes are allowed.
• Keep interviewer notes on answer ownership, not just correctness.

Question design and integrity monitoring reinforce each other. Monitoring helps show whether the environment was trustworthy. Better questions help show whether the candidate owns the work. You need both to make a confident technical hiring decision.

Review checklist after an elevated report

• Compare the event timeline with the exact moment each question was asked.
• Check whether the candidate was told the relevant rule before the session.
• Separate tool presence from active tool use.
• Look for independent corroborating signals before recommending rejection.
• Consider a targeted follow-up interview when evidence is serious but inconclusive.

The goal is a decision your team can defend. A strong candidate should not fail because of a harmless environment quirk, and a weak or fraudulent session should not pass because the interviewer missed what happened off-screen.

Team operating checklist

Technical interview integrity is a team habit, not a one-time setting. Recruiting operations should own the policy and consent language. Engineering should own question design and follow-up quality. Legal should review data collection and retention. Hiring managers should own final decision consistency. When each group owns its part, the process becomes much easier to scale.

Review a sample of completed reports each month. Look for repeated ambiguous cases, unclear interviewer notes, and questions that are too easy to outsource to AI. Update the checklist when the team learns something. The best integrity process gets calmer over time because fewer edge cases are surprising.

This is also how you keep the candidate experience sane. The process should be firm about misrepresentation without making every honest candidate feel suspected from the start.

Frequently asked questions

How do you know if a candidate is cheating in an interview?

Correlate behavioral tells (a delay before answering, an over-polished or generic tone, eyes fixed off-camera, answers that collapse under a specific follow-up) with more reliable technical signals (clipboard paste bursts, a second monitor or virtual camera appearing mid-session, remote-access software, or a hidden overlay window invisible to screen share). No single sign is proof; the reliable method combines several signals with human review.

Is screen sharing enough for a technical interview?

No. Screen sharing is useful, but it does not reliably reveal hidden overlays, second-device assistance, or remote-control activity on its own. It works best as one part of a broader integrity workflow.

Should the same checklist apply to take-home tests?

Usually not. Take-home exercises have different expectations around tool use and collaboration. Your live technical interview checklist should focus on sessions where the candidate is expected to perform independently in real time.

How often should teams revisit the checklist?

At least quarterly, or whenever your permitted-tool policy changes. Interview cheating patterns evolve quickly, so stale process documentation becomes a risk on its own.

For the policy template that sits behind this checklist, see Building an Interview Integrity Policy: HR Template. For the full recruiter playbook, see The Remote Hiring Integrity Playbook.