Home How it works
One Run.
Fifty minutes.
One sitting.
A Run is the unit a college buys, and the unit a recruiter reads. Everything below happens in one supervised session, on a machine we brought and reset, in the college's own room.
What happens, and when.
A real task, not a puzzle
Forty-five minutes of scoped engineering work in a prepared environment, on a machine we reset before anyone sat down. No algorithm riddles — the kind of thing the job actually asks for.
Build a register endpoint. Validate the email, reject duplicates, return proper status codes.
The requirement changes, out loud
At minute twenty the proctor announces something nobody was told in advance. This is the only stage that cannot be prepared for, and it is the one a recruiter actually cares about — finishing a task can be taught, but what someone does when it breaks cannot.
Email can now arrive null. Your code must not crash. Ten minutes.
Five minutes, face to face
In the room, never over video. The questions are about the candidate's own code, on the screen in front of them. Code you did not write is code you cannot defend.
Line 34 — you used a loop instead of map. Why?
A record, not a rating
The DoerPass is a handling report with the recording attached: what they were given, what they did when it broke, and how the viva went. Deliberately not a score out of a thousand — a number gets optimised for, and a recording does not.
Fault resolved in 6m 20s · defended own code · recording attached
The stages are the defence.
Someone can have a model write the sprint code. They still have to handle a fault announced aloud, in a room, against code they do not understand — and then explain line 34 to a person who is looking at the same screen.
That is the design. It does not depend on expensive proctoring hardware, keystroke surveillance or a webcam watching a bedroom. It depends on a change nobody could rehearse for and a conversation nobody can outsource.
The honest limit
It is much harder to cheat than a take-home test. We do not claim it is impossible, and we would rather say so here than have a recruiter discover it later. Our goal is to raise the cost of cheating well above the cost of simply doing the work.
Anatomy of a DoerPass.
Every completed Run produces one. It is the candidate's to share — with any recruiter, as many times as they like, at no cost, forever.
- The brief — the exact task, so a recruiter can judge the difficulty for themselves
- The fault — what changed at minute twenty, and whether it was resolved
- The approach — reproduce first, or start changing lines and hope
- The viva — whether they could defend their own code under questioning
- The recording — attached, so nobody has to trust our summary
Illustrative. The first pilot has not run, so no real DoerPass exists yet.
Four variants, every campus day.
Laid out in a checkerboard so no neighbour ever shares a task, with the seating chart printed before we arrive. Every task runs fully offline — in-memory data, no API calls, no package downloads — which is what makes campus wifi irrelevant.
| Track | The sprint | The fault at minute 20 |
|---|---|---|
| Backend | Build a register endpoint that validates email and rejects duplicates | Email can now arrive null, and nothing may crash |
| Data | Clean an anomaly-filled dataset and produce a summary | A column silently changes type mid-sprint |
| Full-stack | Wire an authentication flow end to end | Token refresh starts failing intermittently |
| Backend | Put a cache in front of a slow read | The cache and the source begin to disagree |
Variants rotate between campuses. A fully leaked task still does not leak the curveball, because that is announced live and changes every session.