B2B · 2026
Hiring
signal.
AI technical assessment infrastructure: turns a job description into a proctored assessment, executes real candidate code in 14 languages, scores it against a transparent rubric and produces an anti-cheating integrity score.
- Role
- Sole engineer, designer and operator
- Timeline
- 2026 — ongoing
- Live at
- thequizmaster.io ↗
The problem
Technical hiring runs on take-home tests that nobody fully trusts. The candidate does not know what is being measured, the reviewer does not know whether the code is theirs, and the score at the end is a number with no argument behind it.
The three failures are separable. Assessments are generic because writing a good one per role is expensive. Scoring is opaque because it happens in a reviewer's head. And integrity is unknowable because the work happens somewhere the platform cannot see.
Constraints
Untrusted code, real execution
Scoring code you have not run is guesswork, so candidate submissions execute for real, in fourteen languages. That means running hostile code on infrastructure I own — with time limits, memory limits, no outbound network, and no path from a submission to anything else on the host.
The rubric has to be arguable
A score a hiring manager cannot defend to a candidate is worse than no score. Every rubric line has to be visible, attributable to something in the submission, and disputable.
Proctoring that informs, not accuses
Assessments are proctored and produce an integrity score, but the product surfaces signals rather than verdicts. Whether someone cheated stays a human judgement, because the cost of being wrong falls entirely on the candidate.
One person operating it
Every design decision had a second question attached: what does this cost me to run at 2am when I am the only one on call.
Decisions
- 01
Generate from the job description, not from a template bank
The assessment is derived from the actual role — coding exercises, code review, a knowledge quiz, a spoken system-design prompt, a video intro. A template bank would have shipped faster and produced the same generic tests the product exists to replace.
- 02
Execution is server-side and isolated, always
Running submissions in the browser would have been cheaper and would have removed the hardest part of the system. It would also have made every result unverifiable, which is the whole product.
- 03
Python and FastAPI for the assessment engine, Next.js for everything else
The scoring and execution path lives where the model tooling is best supported. The rest — dashboard, auth, billing, delivery — stays in the stack that gets a feature to a customer fastest. Two runtimes is a real cost, paid deliberately.
- 04
Redis as the seam between the two
Assessment runs are queued work with a lifecycle, not request-response. Treating them that way from the start avoided the rewrite that a synchronous first version always needs.
Where it landed
- Languages executed
- 14
- Assessment formats
- 5
- Engineer
- 1
- Assessment engine
- Python · OpenAI APIs (parallelized calls) · Sandboxed execution
- Application
- Next.js · React · TypeScript
- Delivery & lifecycle
- GitHub Actions · Stripe · Brevo · Resend