August 14, 2026·5 min read
A strong engineer took your coding test last month. They did badly. Not because the problem was beyond them, but because there was a countdown timer in the corner, a webcam watching, a rule against opening documentation, and a requirement to narrate their thinking to a stranger.
None of those things exist in the job. All four were in the test. So you measured how they cope with those four things, and then you rejected them for it.
That is the argument here, and it is not mainly a kindness argument. It is a measurement argument. Anything the format filters for that the job does not need is noise in your result, and noise costs you good hires.
Meant to test: working under pressure. Actually tests: how someone performs while being visibly timed, which is a separate trait. It hits hardest for people with anxiety disorders, ADHD, and anyone returning to interviewing after years in one job.
Real engineering has deadlines. It almost never has a visible countdown attached to a graded task, which is a specific and unusual stressor.
Instead: give a generous window and be explicit that it is generous. "Ninety minutes, most people finish in sixty, we do not score speed." Then honour it. If you genuinely need to see someone under time pressure, that is a separate exercise with a separate purpose, and it belongs later in the process, not at the screening stage.
Meant to test: integrity. Actually tests: tolerance for being watched, plus whether you have a quiet, private, well-lit room. That last one is a wealth filter and a housing filter.
It also produces false accusations. Proctoring software flags people for looking away, for a second face passing behind them, for stimming, for reading aloud. Those are all normal.
Instead: design the task so cheating does not help. If the answer is not findable, surveillance stops being the control. We wrote up how in how to design a technical interview a candidate can't cheat. If you want evidence of process, record the work session, tell the candidate clearly, and use it as material for the debrief rather than as an accusation engine.
Meant to test: knowledge. Actually tests: short-term memory under stress. Nobody works without documentation. Nobody.
It also punishes people who move between languages, who use assistive tooling, or whose recall is affected by medication or fatigue.
Instead: let them look things up, and grade what they do with what they find. If you are worried the task becomes trivial when it is lookupable, the task was the problem.
Meant to test: nothing. Nobody chose this. Actually tests: whether the candidate's assistive technology happens to work with your vendor's editor widget.
This is the most common accessibility failure in assessment tools, and the one candidates rarely report, because reporting it means disclosing a disability to a company that has not hired them yet.
Instead: two things. Ask your vendor for a current accessibility conformance report and actually read it. And always offer a path where the candidate works in their own editor on their own machine, or over a plain terminal, which is far more likely to work with their setup than a custom web widget.
Meant to test: communication and reasoning. Actually tests: the ability to speak and solve simultaneously, in what is often a second language, while being evaluated.
Plenty of excellent engineers go quiet when they concentrate. Narration is a performance skill. It correlates with confidence far more than with ability.
Instead: ask for the reasoning in writing, or ask for it afterwards. "Take ten minutes, then walk me through what you found" gets you better reasoning than live narration, and it removes the double-task penalty. If you want to see collaboration, make it an actual collaboration, as in how to run a pair-programming interview.
Meant to test: nothing. Actually tests: willingness to disclose a disability to a stranger who controls whether you get the job.
If the only way to get more time is to email a recruiter explaining your medical situation, most people will not do it. They will take the test as-is and do worse, and you will never know why.
Instead: offer it before anyone asks, in the invitation, in one plain sentence: "If a different format would let you show your ability better, reply and tell us. You do not need to explain why." That last clause is the whole thing. It removes the disclosure cost.
The thing to say clearly, because someone always asks: none of this makes the assessment easier.
The task is the same. The problem is as hard as it was. What changes is that you stop measuring things you never intended to measure. A candidate who solves your problem with documentation open, in silence, in ninety minutes, on their own keyboard, has demonstrated exactly the skill you wanted. The version who did it in forty-five minutes while narrating to a webcam demonstrated the same skill plus a performance trait you do not need.
If anything, removing the noise raises the bar, because now the score is about the work.
There is also a compliance dimension. In the UK the Equality Act 2010 requires reasonable adjustments in recruitment, and in the US the EEOC has published guidance on how software, algorithms and AI in hiring can breach the ADA when they screen out people with disabilities. Worth reading before you buy a proctoring product.
Two parts of our setup matter here, and one limitation.
The environment is a real Linux machine, so the candidate can work the way they normally work: their own shell habits, a plain terminal, documentation open, their own tooling. A terminal is far more compatible with assistive technology than a bespoke code widget, and nobody has to fight an unfamiliar editor while being assessed.
The session is recorded, terminal and screen. That means you do not need live narration to know how someone worked. They can be silent for twenty minutes, and the debrief still has the full picture. Removing the think-aloud requirement is normally the change that costs the most signal. Here it costs none.
The limitation, stated plainly: a browser-based environment is still a browser-based environment. If a candidate needs a specific assistive setup that does not travel into a web session, the right answer is to let them do the work locally and share the result, and we would tell you to do that rather than insist on the platform.
Timers, webcams, no-docs rules, custom editors and forced narration all filter for traits the job does not require. Take them out and the difficulty stays while the noise goes.
The single cheapest change: put one sentence in your invitation offering a different format, with no explanation required. It takes a minute and it recovers people you are currently losing without ever knowing you lost them.
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
At high volume the real constraint is engineer attention, not candidate quality. Here is what automation genuinely handles at each stage, what it quietly makes worse, and how to find out whether your funnel is throwing away good people.
Recruiters are asked to make a technical call they were never equipped to make, then blamed for the shortlist. Here are questions that need no technical knowledge to evaluate, and the one artifact worth handing to the hiring manager.
Read more
Generated code fails in a different pattern from human code, which is why normal review habits miss it. Here is the review order that catches the most in the least time, and the hiring task built from it.
Read more
