Detection and scoring methodology

How InterviewWatch Detects AI Assistance And Interview Integrity Risks.

InterviewWatch does not decide whether a candidate cheated. It observes disclosed technical events during an authorized live interview, groups related events into incidents, weights their severity, and gives a human reviewer a signed timeline. No single signal is treated as proof.

Signal classes14 detectors
DecisionHuman review
Media recordingNone
Evidence modelContextual
The short answer

How does InterviewWatch detect AI use in a remote interview?

It combines operating-system evidence that is difficult for screen sharing alone to show: known AI applications and browser titles, newly observed AI-service network lookups on Windows, capture-excluded overlays, remote-control software, clipboard-event size, focus changes, device changes, and typing or answer-timing patterns. The system records which signals appeared and when. It does not read the candidate's prompts, answers, screen, or clipboard content.

Observation is not intent

An AI process running can be relevant evidence, but it does not by itself establish how the process was used. The interviewer must compare the incident timeline with the interview format, disclosed rules, and other evidence.

Signal coverage

Fourteen detectors, grouped by the question they help answer.

The exact low-level implementation differs between Windows and macOS. The report uses stable, human-readable categories so reviewers do not need to interpret raw operating-system events.

AI and knowledge assistance

  • Known AI desktop processes and local LLM runners.
  • AI-related browser window titles.
  • New AI-service DNS entries visible to the Windows resolver.
  • Knowledge-source activity such as documentation or coding-reference sites.

Hidden or external control

  • Windows excluded from normal screen capture.
  • Remote-control host or viewer software.
  • Injected input and unusual focus transitions.
  • Agent heartbeat loss or interruption.

Environment and behavior

  • Virtual camera or audio devices in active use.
  • Monitors added or removed during the session.
  • Large or structured clipboard events, without content.
  • Uniform keystroke timing and pause-then-burst answer timing.
  • Expected meeting-platform context.
Evidence pipeline

From consent to a reviewable report.

1Candidate disclosure and consentThe agent explains the session and starts only after authorization.
2BaselineExpected devices, displays, and relevant running tools are recorded as context.
3Live observationFast and slow detector loops emit structured events and a heartbeat.
4Incident correlationRelated start, update, end, and point events become a readable timeline.
5Server-side scoringThe final score is recomputed from the saved incident timeline.
6Human reviewAn authorized reviewer interprets the evidence in interview context.
Scoring

A prioritization aid, not an automated verdict.

Each incident category has a configured severity contribution. Duration and repeated observations can change the contribution for signals that persist. Context-only events, such as an expected meeting application or a multi-monitor baseline present before the interview, can remain informational rather than deductive.

The server recomputes the final score from the stored timeline instead of trusting a number sent by the desktop agent. This makes the report reproducible from the evidence it contains.

Interpretation rules

  • One signal is not treated as proof of cheating.
  • Informational baselines are separated from risk events.
  • Reviewers see timestamps, category, severity, and context.
  • The report should be compared with the employer's disclosed policy.
  • No candidate is automatically rejected by the product.
Data boundary

What is observed, and what is deliberately excluded.

Observed metadata
Not collected

Signal category, relevant process or window category, timestamps, duration, display and device changes, focus events, clipboard-event size, timing statistics, network-resolution categories, and heartbeat status.

Screen pixels, screenshots, screen recordings, webcam video, microphone audio, meeting audio, typed text, clipboard contents, private file contents, or the semantic content of answers.

Read the privacy policy Read the security overview

Known limitations

What InterviewWatch cannot reliably conclude.

Understanding these boundaries helps hiring teams interpret reports fairly and decide when additional review is needed.

Second-device assistance

Software on the interview computer cannot directly observe a phone or another physical computer. Timing and behavior may create review signals, but they are not direct proof.

Encrypted DNS and cached domains

DNS-over-HTTPS can bypass the Windows resolver cache, and domains already cached before the agent starts may not appear as new network evidence. Process and title signals can still apply.

Operating-system boundaries

Signal availability and permissions differ by platform. On Windows, elevated applications can restrict lower-privilege keyboard and focus hooks. On macOS, system permissions affect available observations.

Legitimate tools

A tool can be open for an allowed reason. A reviewer must interpret it against the interview policy and timing.

Behavioral inference

Typing cadence and answer latency are weak signals on their own and can be affected by disability, language, anxiety, or interview format. They require cautious, contextual review.

Interview context

Allowed resources, accessibility needs, interview format, and company policy affect how a signal should be interpreted. The report keeps the decision with the reviewer.

Quality checks

Detection behavior is checked with positive and negative scenarios, event sequencing, heartbeat interruptions, score calculation, and report generation.

Evaluate it in your environment

Interview formats and allowed tools differ between employers. A useful evaluation should include your platforms, policies, accessibility requirements, and common candidate workflows.

Methodology FAQ

Direct answers for evaluators and candidates.

How does InterviewWatch detect AI use during an interview?
It correlates known AI processes, AI-related browser titles, newly observed AI-service DNS entries on Windows, focus changes, clipboard-event metadata, and answer timing. It reports observations for human review and does not read prompts or prove intent.
Does it read keystrokes or clipboard contents?
No. It uses timing and event-size metadata. Typed text and clipboard contents are not collected.
Can one signal automatically fail a candidate?
No. The product does not automatically reject candidates. The report is contextual evidence for an authorized human reviewer.
Why is human review required?
Technical events can have legitimate explanations. The hiring team should compare each incident with the interview format, allowed tools, timing, and surrounding evidence before making a decision.

Evaluate the method against your interview policy.

Bring your allowed tools, interview format, platform requirements, and false-positive concerns to a product review.

Request a methodology reviewAbout InterviewWatch