How to Stop People Cheating on Interviews

What interview cheating looks like in practice

The dominant pattern is no longer a printed cheat sheet or a friend on speakerphone. It is a purpose-built desktop application that listens to the interview, generates answers, and displays them in a window designed to be invisible to screen sharing. The candidate reads naturally from their own screen while the interviewer sees nothing unusual.

Alongside that, hiring teams encounter remote-control software, where another person drives the machine; proxy candidates, where a different person entirely performs the interview; and coding copilots that produce solutions faster than any human types. Each of these is invisible to a video call.

Why browser-based proctoring misses modern AI assistants

Most proctoring tools are built as browser extensions or lockdown browsers. They can see the tab, the page, and sometimes the webcam, but their visibility ends at the edge of the browser process. Modern AI assistance does not live inside the browser.

Tools such as invisible interview copilots and always-on-top answer overlays run as native desktop applications. They render above every other window, are frequently excluded from screen capture and screen share, and never touch the exam tab. A lockdown browser can be perfectly locked down while an assistant quietly reads the question and displays an answer on the same screen.

The same gap applies to remote-control software, virtual machines, injected keyboard input, and a second device sitting off camera. None of these leave a trace inside the browser, which is why a session can look clean in a browser-only tool and still be assisted end to end.

• Native overlay applications draw above the browser and are often invisible to screen sharing and screen recording.
• Remote-access tools let another person drive the machine without any browser-visible signal.
• Virtual machines and sandboxes let a candidate run the assessment in a controlled environment with helpers outside it.
• Synthesized or injected keyboard input can type answers that were never physically typed.
• A second phone, tablet, or monitor off camera leaves nothing at all in the browser.

What device-level detection actually sees

Detecting AI assistance reliably requires observation at the layer where the assistance runs: the operating system. ScreenComply pairs a browser-based API with an optional desktop agent that inspects the environment around the assessment rather than only the page inside it.

The agent enumerates running processes and browser extensions against a continuously updated list of AI assistants, answer overlays, and interview-copilot tools. It looks for always-on-top and transparent windows, remote-access sessions, virtualization, screen-capture drivers, additional connected displays, and USB storage events. It checks whether keyboard input originates from local physical hardware, and it records focus changes, clipboard events, and typing cadence patterns that distinguish composition from paste-and-modify behavior.

No detection system is perfect, and ScreenComply does not claim to catch every form of assistance. The goal is different and more useful: gather corroborating, timestamped signals so a human reviewer can make an informed, defensible decision instead of guessing from a webcam thumbnail.

• Process and extension enumeration against a maintained AI-assistant list.
• Overlay and always-on-top window detection, including windows excluded from screen share.
• Remote access, virtual machine, and screen-capture detection.
• Multi-monitor enumeration queried from the operating system, not inferred from gaze alone.
• Input-source integrity, clipboard and paste events, and typing-cadence analysis.
• Network and secondary-device signals on the local network.

Making the process consistent and defensible

Integrity checks only work when they are applied uniformly. Applying extra scrutiny to selected candidates creates fairness and legal exposure; applying the same verification to every candidate at a given stage does not.

Announce the check in the invitation, run it identically for everyone at that stage, and route every flagged session through the same human review. Prevent mode can be reserved for the stages where the stakes justify it, with lighter Detect-mode coverage earlier in the funnel.

• Disclose monitoring in the interview invitation, before the session.
• Apply the same configuration to every candidate at the same stage.
• Use Detect mode broadly and Prevent mode for high-stakes stages.
• Send every flag through the same documented human review.
• Keep the report on file so the decision can be explained later.

How audit-ready integrity reports work

A detection is only useful if it can be explained to someone who was not in the room. Every ScreenComply session produces a structured integrity report: an executive verdict with a risk level, a chronological evidence timeline, and the underlying signal detail behind each entry.

Each entry is timestamped and tied to the specific observation that produced it, so a reviewer can see what was detected, when it happened, and how strong the signal was. Reports are written in non-accusatory, factual language, because the institution or employer makes the decision, not the software.

Reports can be exported to PDF and shared with a secure link, which is what makes them usable in academic-integrity hearings, HR reviews, and compliance audits. Retention is configurable, including tiers that minimize or eliminate stored artifacts for privacy-sensitive programs.

• Executive verdict with a graded risk level rather than a pass/fail guess.
• Chronological, timestamped evidence timeline linked to underlying signals.
• Human-review-by-design framing: factual observations, not accusations.
• PDF export and secure sharing for hearings, HR files, and audits.
• Configurable retention, up to zero-retention operating modes.