Why Async Proctoring Isn't Enough for Live Interviews
Async proctoring, meaning webcam recording, browser lockdown and post-hoc video review, was built for a specific problem: an unsupervised candidate taking an unsupervised exam. A live interview is neither of those things. There is already a human watching. The failure mode is different, and tooling built for exams does not transfer cleanly.
Short answer
Async proctoring answers "was this person alone and present?" A live interview already answers that: an interviewer is on the call. The question a live round needs answered is "is this answer theirs?", and recording cannot address it.
The gap is structural. A recording is produced from the capture stream, so any window excluded from capture is absent from it. The methods that work in live rounds are precisely the ones a recording cannot contain.
On this page
The assumption it is built on
Exam proctoring makes three assumptions, all reasonable for a timed test taken alone, and all false for a technical interview.
- Nobody is watchingSo presence and identity must be established by the tooling. In an interview, a human is already on the call for an hour.
- The assessment lives in one windowSo locking the browser constrains the candidate. In an interview they need an editor, a terminal, documentation and a video call.
- Review can happen afterwardsSo recording and later analysis is sufficient. In an interview the interviewer can ask a question in the moment, which is far more informative than any footage.
Where the model breaks down
| Method | Async proctoring sees | Endpoint monitoring sees |
|---|---|---|
| Capture-excluded overlay | Nothing. Omitted from the stream by design. | The exclusion flag, plus owning process and z-order. |
| Second physical device | Nothing, unless it enters the camera frame. | Answer timing only, which is honest about its limits. |
| Remote driver | Nothing. Injected input looks normal on video. | Injected-input flags and pointer geometry. |
| Virtual camera | Nothing. It looks like a camera. | Device driver and registration time. |
| Second tab | Possibly, if the share includes it. | Focus departure and dwell. |
| Candidate absent or substituted | Yes. This is what it is good at. | Partially, via device and behaviour signals. |
Note the last row. Async proctoring is genuinely good at one thing, and that thing is the one a live interview already handles by having a person on the call.
The observation-point problem
This is worth stating precisely because it is not a quality gap that a better proctoring vendor could close. It follows from where each approach observes.
Screen capture reads a composited stream that the operating system assembles. A window marked with the exclude-from-capture attribute is skipped during composition. The interviewer's live view, the recording, and any model analysing that recording all derive from the same stream, so all three are missing the same window. No amount of reviewer attention or model sophistication recovers information that was never in the file.
An agent on the endpoint enumerates windows through the window manager, which reports the exclusion attribute itself. It sees the overlay exists, which process owns it, where it sits, and when it appeared, all without reading a single pixel. See hidden overlays that beat screen sharing.
What live interviews actually need
- Environment state, not media. Which processes and windows exist, which devices are attached, what has focus.
- Question anchoring. Events are meaningless without knowing when questions were asked. This is the piece exam tooling has no concept of.
- Correlation. Findings from clustered signals, not a stream of individual alerts a reviewer learns to dismiss.
- Real-time capture, deferred review. Collect during, review after, never interrupt the interview.
- A human with a follow-up question. The single most effective control, and one only a live round offers.
Key takeaways
- Async proctoring assumes nobody is watching; a live interview has an interviewer for an hour.
- Recording derives from the capture stream, so it omits capture-excluded windows by construction.
- Browser lockdown is irrelevant when the candidate needs an editor, terminal and docs.
- Live rounds need environment state anchored to question boundaries, which exam tooling has no concept of.
- Use proctoring for genuinely unsupervised stages and endpoint monitoring for human-led ones.
Using both, when both make sense
These are complementary rather than competing, provided each is used where its assumptions hold.
Async proctoring fits
- A timed assessment the candidate takes alone.
- Certification or credential exams.
- Stages where presence and identity are genuinely unverified.
- High-volume screening with no human present.
Endpoint monitoring fits
- Live technical and system-design rounds.
- Panel interviews with an interviewer present.
- Take-home review sessions.
- Any round where the question is authorship, not attendance.
The cost side nobody prices
Even where proctoring is a reasonable fit, the costs deserve to be on the same page as the benefits. Recording a candidate's webcam, screen and room creates a data asset you must secure, retain, honour access requests against, and eventually delete. It generates false positives on disabilities and neurodivergent traits. And it costs offers: strong candidates decline rounds that require room scans, and they tell others.
None of that is an argument against proctoring in the exam context it was built for. It is an argument against reaching for it in a live interview, where you pay all of those costs and receive coverage of methods nobody is using.
Frequently asked questions
What is the difference between async proctoring and live interview monitoring?
Async proctoring was built for unsupervised exams: it records the candidate's webcam and screen, locks down the browser, and has a person or a model review the footage afterwards. Live interview monitoring runs on the endpoint during a human-led interview and records structural metadata rather than media.
The difference in observation point is what matters. Anything excluded from the capture stream is absent from a recording, while the operating system can still see it.
Why does async proctoring fail for live interviews?
It solves a problem the live interview does not have and misses the one it does. There is already a human watching, so presence verification adds little.
Meanwhile the methods that actually work in live rounds, capture-excluded overlay windows, a second physical device, and remote-control drivers, are either invisible in the recording or outside the camera frame entirely. Browser lockdown is also largely irrelevant when the candidate is working in their own IDE on a video call.
Can you use proctoring and live monitoring together?
Yes, and for some loops it is the right answer. Proctoring fits the unsupervised stage, typically a timed assessment a candidate takes alone, where presence and identity are genuinely unverified. Live monitoring fits the human-led rounds.
What does not work is applying exam-era tooling to a conversation and assuming coverage, because the failure modes do not overlap.
Does recording an interview help catch AI assistance?
Much less than teams expect. The recording is produced from the same capture stream the interviewer already saw, so it contains nothing new, and it specifically omits any window marked to exclude itself from capture.
Reviewing footage afterwards mostly confirms impressions rather than adding evidence, while creating a substantial privacy liability that persists for as long as the recording is retained.
Is browser lockdown useful in a technical interview?
Rarely. Lockdown assumes the assessment happens inside a controlled browser window, which is true for an exam and false for a technical interview where the candidate is working in their own editor, terminal and documentation.
It also cannot restrict a second machine or a phone, which is where a determined candidate moves once the primary machine is constrained.
What should replace async proctoring for live rounds?
Endpoint metadata correlated into findings: process and window state including capture-excluded windows, focus events anchored to question boundaries, paste size and provenance, display and virtual-device topology, and input cadence against the candidate's own baseline.
Combined with interview design that asks candidates to extend their own answers, that covers the live failure modes without recording anybody.
References
- Hidden overlays that beat screen sharing, on the capture-exclusion mechanism.
- What interview integrity monitoring is, for the category comparison.
- How to detect AI assistance, for the correlation model.
- Virtual camera and voice detection, on why a recording cannot see a synthetic feed.
Give your interviewers what they can't see
InterviewWatch observes the endpoint during live rounds, catching what the capture stream is built to omit, with no recording of any kind.