October 23, 2026·5 min read
There is a failure mode that hiring teams discuss quietly and rarely design for: the person who did the technical assessment and the person who starts on Monday are not the same person.
It is rare. It is also real, and it concentrates in a specific place: high volume pipelines, fully remote, where every stage before the offer is asynchronous or on camera with someone nobody will ever meet. The more your process looks like a series of tests, the easier it is to send somebody else to take them.
The instinct is to reach for verification: an ID upload, a webcam check, a proctoring tool. Those mostly inconvenience honest candidates and catch nobody who prepared.
An ID photo proves a document exists. It does not prove who is in the room, who is on the other end of the screen share, or who is typing while someone else talks.
Webcam monitoring watches the wrong surface. It sees a face and a room. It cannot see the second machine, the person out of frame, or the remote session into the same desktop.
It costs you candidates. Every additional verification step is friction applied to everyone to deter a few. At volume that trade can be worth it. It is worth measuring rather than assuming, because a drop in completion is a real cost paid by every honest applicant.
It carries obligations. Identity documents and biometric data are not ordinary application data: collecting them means storage, retention, access control and a lawful basis, which is a bigger commitment than most teams realise when they switch the feature on. The adjacent rules are covered in what the EU AI Act means for your technical interview process.
Continuity, not verification.
A substitute can pass a test. A substitute cannot defend a decision they did not make, four days later, in a conversation about the specific thing they built.
That gives you three cheap mechanisms, none of which require a camera or a document:
One: have the candidate explain their own work, live. Short, fifteen minutes, on the thing they submitted. Why this approach. What you would change. What was the hard part. Nobody can answer those convincingly about somebody else's work, and everybody who did the work can.
Two: make one stage interactive and unscripted. A live session in a real environment, where the task moves under them. The requirement changes halfway. A new error appears. The person in the room has to react, and reaction cannot be prepared or outsourced in real time.
Three: keep the same person across stages, and have them notice. A single interviewer who sees the candidate twice will spot a difference in voice, approach and knowledge that no checklist encodes. This is the oldest mechanism there is and it keeps working.
These three cost interviewer time, which is why volume pipelines avoid them and why volume pipelines are where substitution happens. There is no free fix: either humans spend time, or the process is cheap and gameable.
What you can do is spend that time where the stakes are highest. Nobody needs identity assurance on an applicant who will be screened out on the first task. Put the interactive stage after the first filter, and make it the gate before an offer, and you are spending human attention on ten people rather than five hundred.
Occasionally a signal appears: the person in the final round sounds different, or cannot discuss their own submission, or the written English in the take-home does not match the conversation.
Do not accuse. Ask them to walk through their work, in detail, with specific questions. It resolves itself quickly in both directions, and an innocent candidate experiences it as a normal technical conversation rather than an interrogation.
Keep a record of what you observed, in the specific, not the inferred: this answer did not match this submission. If the decision is challenged later, observations are defensible and suspicions are not.
Apply the same standard to everyone. Suspicion that falls more heavily on candidates with certain accents or in certain countries is a discrimination problem wearing a security costume. If you only ever ask one group to explain their work, the process is not an integrity measure, it is a bias.
Related reading on the assistance side rather than the substitution side: how to design a technical interview a candidate cannot cheat and what HackerRank proctoring catches and misses.
The mechanism that works here is an unscripted session where the work happens in front of you, and that needs an environment both sides can see live.
EasyEnv gives the candidate a real machine for the session, with the interviewer able to watch the terminal and screen as it happens and the whole session recorded. The task can be changed mid-session, because the environment is real rather than a fixed exercise, which is precisely what a stand-in cannot absorb. Afterwards the recording is there if a decision is ever questioned, which is more useful than a stored identity document and far less sensitive to hold.
The limits, plainly. This is not identity verification and we would not claim it is: it makes substitution impractical rather than detectable. It costs interviewer time, so it belongs at the stages that matter. And a recording is personal data too, with retention and access rules of its own, so decide how long you keep sessions before you start making them.
Substitution is a volume-pipeline problem, and documents and webcams are the wrong tools for it. Make one stage live, unscripted and about the candidate's own work, keep the same interviewer across stages, and spend that attention where an offer is actually at stake.
Interview the reasoning, in a session that can change under them, and the identity problem mostly solves itself without a single ID upload.
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
A week inside the team answers nearly everything an interview is guessing at, and rules out most of the people worth hiring. Here is when a trial earns its cost, how to structure one that is fair, and what to run instead when it is the wrong tool.
Contract hiring skips the loop, which is the point, and then the work arrives and nobody can say whether it will survive the handover. Here is a single session that tests what actually matters for short engagements, and the four things to watch while it runs.
Read more
Support interviews test warmth and scripts, then the job turns out to be technical from the first ticket. Here are four tasks on a real box with a real symptom, reproducing a vague report, separating configuration from defect, reading the logs that matter, and writing the reply.
Read more
