How to Detect AI Assistance in Remote Interviews

A new category of tools generates fluent, real-time answers for candidates during live interviews. Most are designed to stay out of sight of the video call and screen share. Detecting them reliably means looking past any single tell and correlating several weak signals into one strong conclusion.

By 2025, surveys showed roughly one in five candidates admitting to covert AI use during interviews. The tooling is mainstream and well funded, so a detection approach built around blocking one named app ages out within weeks. A durable approach watches behaviour and environment, not brand names.

Why a single check is never enough

Any one signal can be explained away. A second monitor might be legitimate. A burst of typing might be a fast coder. A new background process might be a notetaker. Individually, each is noise. The fraud becomes obvious when several of them line up at the same moments, for example, a focus change to an off-screen window immediately followed by a long, perfectly formed answer pasted into the editor.

The signals that matter

• Process & window presence. Assistant-style helpers and their windows, including ones kept off the shared screen.
• Focus changes. Repeated switches to a window that never appears in the screen share.
• Clipboard behaviour. Large pastes whose timing tracks the interviewer's questions (size and source, never the content).
• Input timing. Answers that arrive as a single fluent block rather than the start-stop rhythm of real typing.
• Network & device context. Connections and virtual devices that appear only for the session.

Detect without surveilling

Good detection is also privacy-preserving. You do not need to read what a candidate types or record their screen to know that a fluent answer was pasted from an off-screen window seconds after a question. Capturing timing and metadata rather than content keeps the approach both effective and defensible, and keeps honest candidates undisturbed. We cover this in consent-first interview monitoring, and why recorded-video proctoring approaches don't solve this problem in why async proctoring isn't enough for live interviews.

Detection should follow the method, not the brand name

AI interview tools rebrand constantly. One month the risk is a browser tab, the next it is a desktop overlay, a phone beside the laptop, or a companion device showing generated answers. A detection strategy based on product names will always be late. The stable part is the method: outside question capture, answer generation, answer delivery, and candidate relay.

Each method leaves a different kind of trace. A browser-based assistant may produce focus changes and knowledge-source activity. A desktop overlay may create window attributes that do not appear in normal screen sharing. A phone-based assistant may not appear on the candidate machine at all, but the response pattern can still show unusual pause-to-fluent-answer timing. Strong detection combines these weak signals into a reviewable timeline.

What a reviewer should see

The report should not simply say "AI detected." That is too blunt and too easy to dispute. A reviewer should see what happened, when it happened, how severe it was, and what policy it relates to. For example: "At 14:22, immediately after question 4, active focus left the coding environment for 48 seconds, landing on a known AI assistant; at 14:23, a 1,200-character paste sourced from that assistant landed in the answer editor."

This level of detail lets the hiring team make a proportional decision. It also protects candidates because the review is based on evidence rather than a vague impression that someone sounded too polished.

Implementation checklist

• Define allowed and prohibited AI use by interview type before monitoring begins.
• Collect only metadata needed to evaluate integrity.
• Correlate focus, process, clipboard, device, display, and timing signals.
• Require human review before any adverse decision.
• Keep the evidence report attached to the candidate record for auditability.

How to separate preparation from live assistance

Good candidates use AI to prepare. They may practice answers, summarize their projects, review common interview questions, or generate study plans before the call. That is different from using live AI assistance to answer questions during a closed-book interview. Your detection program should preserve this distinction clearly.

The practical line is timing and disclosure. Preparation happens before the session and shows up as better readiness. Live assistance happens during the session and may show up as external activity, hidden answer delivery, paste bursts, or answer timing that does not match the candidate's interaction with the task. A candidate who openly asks whether a tool is allowed is behaving differently from one who hides it.

This distinction helps avoid an anti-AI posture that feels unrealistic. The goal is not to ban learning tools. The goal is to make sure the interview still measures the candidate's own judgment, skill, and communication. For a fuller playbook on interviewing engineers who use AI daily, see hiring AI engineers when everyone uses AI.

How the pieces connect

AI assistance touches hidden overlays, clipboard behavior, timing patterns, multi-monitor setups, and policy language. No single signal proves covert AI use on its own, the strength of a detection program is in correlating several of them against one session, then handing a human reviewer the full picture instead of a lone alert.