Proctoring done right: signals, not surveillance

Separate an event from its meaning

A browser window loses focus. A face moves out of frame. Another voice appears in the background. These are events that a remote-interview tool may detect, but they are not explanations. A notification, an unstable connection, a child entering the room, or an assistive workflow can produce signals that look unusual without indicating dishonest behaviour.

The first responsibility of the reviewer is to preserve that distinction. A system can surface something worth checking. It should not silently turn a detection into an accusation. Treat each signal as a prompt for contextual review, and document the reasoning that connects an observation to any next step.

Explain the process before the interview

Candidates should know what information is collected, why it is relevant, who reviews it, and where to raise a question. Use plain language. “We review changes in browser focus” is more understandable than a broad statement that a session is “protected by intelligent integrity monitoring.”

Also describe the practical expectations of the session. If notes, a calculator, or a particular reference source are allowed, say so. If a candidate needs an accommodation or cannot meet the technical requirements, provide a contact and an alternative process where appropriate. Ambiguity makes both the interview and the later review less fair.

Review the timeline, not just a score

An overall risk label compresses many different events into one summary. Before drawing a conclusion, look at when an event occurred, how long it lasted, and what was happening in the interview. A brief interruption during the introduction is not the same as a repeated unexplained pattern during a work sample.

A useful review process connects the event to the relevant transcript or recording, considers technical explanations, and records whether the issue was resolved. Avoid asking a candidate to defend themselves against a score they cannot understand. If clarification is needed, describe the specific observation neutrally.

• Check the timestamp and surrounding conversation.
• Consider connection problems and environmental interruptions.
• Ask whether the event affects the evidence for the role.
• Record the reason for any follow-up or decision.

Limit access and retention

Interview recordings and session logs may contain personal information that is not relevant to hiring. Define who needs access and for what purpose. A hiring manager may need evidence about an answer without needing unrestricted access to every technical log. Share information deliberately rather than treating the whole workspace as public to the organisation.

Retention should be a considered policy, not an accidental consequence of keeping everything forever. Agree how long different records are needed, how requests are handled, and when information should be deleted. Specific privacy and employment obligations vary; involve the people responsible for those requirements in your organisation.

Build a human review and escalation path

Make someone accountable for interpreting a flag. Reviewers should be able to distinguish a resolved technical issue from a concern that genuinely requires another conversation. For ambiguous or high-impact cases, a second reviewer can challenge assumptions and check whether the response is proportionate.

Look back at the process over time. Are some types of events routinely irrelevant? Are candidates reporting confusing instructions? Improve the instructions and review standards rather than simply adding more monitoring. Interview integrity and candidate trust are both stronger when the process is transparent, limited, and open to explanation.