Use case
Screen developers on code that actually runs
A screening round exists to answer one question: is this person worth an engineer’s hour. ProctoHire answers it with executed code, a proctored sitting you can watch back, and a scorecard the next interviewer can actually read.
- Execution languages
- 22
- Counted from the runtime map in this product’s source, not rounded up.
- Question types
- 5
- Coding, SQL, multiple choice, spreadsheet, written.
- Auto-graded
- 4 of 5
- Written answers get an AI first pass and always a human decision.
- Free tier
- 25 / month
- Assessments started, on the free plan. Enough for a real pilot.
What a paper contains
A screening test is a document, and the product treats it as one: you build it, preview it exactly as a candidate will see it, then publish it.
Questions live in a bank you build up over time, so the second role you hire for starts from the first one rather than from a blank page. Sections carry their own timing and weighting, and a candidate sees a preview of the environment before the clock starts — which removes the single most common source of an unfair result, a candidate spending the first six minutes working out the interface.
Code that runs, in twenty-two languages
With the runtime versions stated, because a candidate whose answer turns on a language feature deserves to know what it will be judged on.
A submission is executed against the test cases you wrote, and the candidate sees the same console output the grader does — which matters more than it sounds. A candidate who fails on a trailing newline and cannot see why concludes the platform is broken, and they are not entirely wrong.
What is graded automatically, and what is not
Coding, SQL, multiple-choice and spreadsheet answers are scored by the machine. Written answers are not, and neither is a coding question whose test cases are placeholders — an API design question, or anything where the interesting part is the approach rather than the output. Those are routed to review with an AI first pass attached: a proposed mark and the reasoning behind it, per question and for the paper as a whole.
Integrity, without accusing the honest majority
An unproctored coding test in 2026 measures whether somebody has a second window open. A proctored one measures something, provided the flags mean anything.
- Pastes the editor never reported. The server replays the edit stream and measures how many genuinely new characters one event added, rather than trusting a browser flag that misses drag-and-drop, middle-click and programmatic insertion entirely.
- Answers that match another candidate's. Compared as normalised token streams rather than as text, so renaming variables and reformatting does not defeat it — with three guards that strike out the question's own template, the boilerplate your corpus shows is universal, and answers too short to carry information.
- The signals that prove nothing, kept at zero. An unfocused window, a recording gap, a camera showing nothing: recorded, shown, never scored. That is what stops a reviewer drowning in noise and missing the one finding that mattered.
- Every finding is watchable. Click it and the replay shows the code as it stood at that keystroke, with a clip where a recorder was running.
The full mechanism, including what it cannot detect, is on proctoring and integrity evidence, and the review experience is on session replay.
Answers copied from a public solution
A worked solution on a public page is not evidence about a candidate. The same solution reproduced in their answer is.
Where a public solution to a question has been collected, a submitted answer can be compared against it: not a resemblance score, but a fingerprint of the normalised code and the longest run of it the two share. The reviewer sees which page, how much of the answer it accounts for, and how long the matching run was.
It says nothing at all where no public solution has been collected, and it says so in those words rather than showing a reassuring empty result — a check that has not run is not a check that passed, and this product will not let the two look alike.
One limit, stated plainly: collecting public solutions is not something we currently offer. This check runs read-only over solutions already on file, so on a new workspace there is nothing for it to compare against and it will say so. It is here because the comparison itself is sound and the evidence it produces is worth having — not because it will find something on your first hire.
What happens after the score
A structured round, not a chat
The next interview runs from a scorecard: the same questions, the same rating scales, a written reason and a clear recommendation, so two interviewers are judging the same thing.
The interview happens here
Video and audio in the browser, screen sharing, an editor both people can type in, and a whiteboard — so the candidate is not sent to a third tool with a fourth login.
The pipeline moves itself
Stages, what happens automatically at each one, and the funnel behind it. A candidate who passes a screen can be invited to the next round without anyone remembering to do it.
The offer is part of the same record
Offer letters are generated from a template and accepted through a link, so the decision and the paperwork are not in two systems.
For teams that already have systems of record: there is a scoped public API — candidates, assessments, invitations, sessions and their integrity summaries, interviews, pipeline runs and offers — plus webhooks, with keys that are read-only unless you deliberately say otherwise. There are no pre-built connectors to specific applicant tracking systems today. That is a real gap and it is better to say so than to let you find out during a trial.
When a timed test is the wrong instrument
Said here rather than buried, because sending the wrong assessment is the most expensive mistake in this category and it is usually the platform’s fault for selling one shape of thing.
- Senior and staff roles. An hour of algorithm puzzles tells you almost nothing about someone who is hired to make architectural calls. Use a written design question, or a take-home, and spend the time on the conversation.
- Roles where the work is inherently multi-day. If the job is building features in an existing codebase, a multi-file project against a deadline is a closer proxy than anything a countdown can measure.
- Candidates who need adjustments. Extra time, rest breaks, screen-reader mode and integrity exemptions are granted per candidate with a written reason and an append-only record of who approved what. If a platform makes that awkward, it will not happen.
- Anywhere the result would be the whole decision. A screening test is a filter, not a verdict, and everything in this product is arranged around that being true.
If the second or third case is yours, read take-home projects.
Elsewhere on this site
Take-home projects
A multi-file repository against a deadline, reviewed as a diff — and an honest account of what a take-home cannot prove.
Campus and volume hiring
A roster, an assessment window, and one live console that answers the only question that matters on the morning: how many turned up.
Remote and distributed hiring
One-way video screening, live interviews in the browser, and scheduling that works in the candidate’s clock rather than yours.
Security and data protection
Tenant separation, retention, erasure, sub-processors — and the certifications this product does not hold.
Build one paper and send it to one candidate
Nothing has to be configured first. Write a question, preview the environment exactly as a candidate will see it, and send a link. The free plan covers twenty-five assessments a month, which is a real pilot rather than a demo.