A proctoring system watches the browser tab you control, the webcam pointed at a face, and the clipboard inside the window. A candidate with a phone on a book stand beside the keyboard is outside all three, and always was.
This is not a criticism of any particular vendor's implementation. It is arithmetic about where the boundary sits. Everything on your side of the boundary is watched carefully. Everything on the other side is invisible, and the other side now contains a model that will write the whole solution from a photograph of the question.
So the useful question is not "how good is the proctoring". It is: what do you get for it, what does it cost, and what would you do instead.
Credit where it is due, because these are real and they do fire.
Tab switching and window focus. Leaving the assessment window is logged, and on a long test the pattern is informative: three switches while reading is normal, forty is not.
Paste events. A solution appearing in one paste is a strong signal, and it is the single most common thing flagged.
Webcam frames. Presence, absence, a second face, obvious phone handling in view.
Copies of the same answer. Plagiarism detection against previous submissions catches the candidate who found the solution in a public repository, which used to be the main threat model and is now the smallest one.
Taken together this catches unsophisticated cheating, which is most cheating. That is a genuine result and worth something.
A second device. A phone or a laptop next to the machine, out of frame, running whatever it likes. Nothing in a browser sandbox has any visibility into it. Camera monitoring degrades this a little and does not solve it, because a person reading from a screen to their left looks like a person thinking.
Typed-in answers. The paste heuristic assumes copying. Typing what you read is slower, entirely undetectable, and now the default behaviour of anyone who has been told that pasting is flagged.
Someone else in the room. Out of frame, saying the next step.
A better-prepared candidate who memorised this exact question. The question bank is finite and the internet has all of it. This has never been cheating, exactly, and it corrupts the score in the same way.
The general shape: proctoring detects the mechanics of a candidate obtaining an answer through the monitored window. It has no view of an answer arriving through the air.
The false positive rate is not zero and the cost of each one is high.
A candidate with an unreliable connection drops frames and gets flagged. A candidate on a shared machine, in a shared flat, at a kitchen table with someone walking past, gets flagged. A candidate who types fast in bursts because they thought first, which is what strong engineers do, produces a rhythm the heuristics dislike.
And there is a cost you cannot see: the senior candidates who read "webcam monitoring required" and do not schedule. They have other offers and they are not sitting an invigilated exam for a first-round screen. The filter removes the people you most wanted, silently, before you know they existed. Why your best candidates drop out of the funnel is the wider version of this.
There is also what it says about you. Surveillance is a statement of expectation, and the candidate is being asked to accept it before you have offered anything. Some will. The ones with options will remember it.
The reason cheating is worth this much effort is that the assessment has one correct answer that exists somewhere else. Every dollar of proctoring is spent defending a format that is trivially defeated by knowing the answer.
Change what is being assessed and the economics change.
Give someone a real environment with a real, broken, mildly ugly system in it. A service that will not start, a query that got slow last week, a deploy that half-worked. There is no public solution because the scenario is yours. Looking it up returns generic advice. An AI model can help, and it should be allowed to help, because it cannot know which of the four plausible causes is the one in front of them without doing the work of ruling out the other three.
Now watch the work. In EasyEnv the candidate has a real box and a recorded session, so what you review is the sequence: what they checked, what they ruled out, where they went wrong and how they recovered. That sequence is the assessment, and there is no way to obtain it from elsewhere, because it is a record of a person thinking in front of a specific machine.
Note what this does to the cheating question. It does not defeat cheating with better detection. It removes most of the value of cheating, which is a stabler place to stand. How to design a technical interview a candidate cannot cheat goes further into the mechanics.
Some teams need one, usually for volume screening or compliance reasons. Then:
Treat flags as questions, never as verdicts. A flag means look at the session, not reject the candidate. Automatic rejection on a proctoring flag will, over a year, reject honest people.
Tell candidates exactly what is monitored, up front. Not in the terms of service. In the invitation. The ones who object will object either way, and the ones who accept deserve to have accepted knowingly.
Weight it low. A proctored screen is a filter for obvious problems, not evidence of ability. It should never outvote a session where somebody did real work in front of you.
Review your flag rate by candidate location and equipment. If it correlates with anything other than behaviour, you have an adverse impact problem wearing a technology costume.
Proctoring answers "did this candidate obtain the answer through the window I was watching". That was a useful question when the answer lived in a public repository. It is a much weaker question now that the answer lives on a phone.
The alternative is not more surveillance. It is an assessment where the answer does not exist anywhere else, which is also the assessment that tells you more about the job.
Why HackerRank scores don't predict on-the-job performance covers the other half of the problem: what the score means even when nobody cheated.
If your best candidate cheated perfectly and passed, what would you have learned about them that you wanted to know?
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
For a recruitment agency, submission-to-interview ratio is the whole business model. Here is why CV screening cannot move it, what a technical assessment platform has to do differently for agency work, and how to introduce one without adding a step candidates walk away from.
Most technical interview feedback is either legally sanitised nothing or a list of everything the candidate did wrong. Here is what to send instead, what your lawyer actually objects to, and how a real-environment interview makes the useful version cheap to write.
Read more
Teams assess whether engineers can use AI well and never assess what they feed it. Here is what AI security literacy actually covers, why a code review will not catch a leak, and four interview exercises that surface it before it becomes an incident.
Read more
