Build1 publisher3 min readPublished
One interviewer's thirty-minute format hands candidates six seeded defects and grades the order they reach for them, which puts a reviewer's attention budget on the record in a way a whiteboard problem cannot.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Defect three is the part worth stealing. There is a limiter, it stores `lastAttemptAt`, and it compares against a window; the bug is that it rewrites the timestamp on every request, including the ones it rejects, so the window slides forward on each rejection and a user who hits the limit once never gets back in [11]. Reading the code tells you a limiter exists. Tracing a second request through it tells you the limiter is a lockout, and the interviewer's tally is that everyone sees the limiter and almost nobody traces the second request [12].
Defect four is tuned the same way, to deployment rather than control flow. The old code still reads `verification_token`, the migration drops it, and the PR removes the reads, so unless those land in that exact order you get a few minutes of 500s, and they will not land in that order because instances roll one at a time [13]. He reports that backend candidates who have actually shipped catch this and nobody else does [14]. That is a fixture calibrated on rolling deploys. Cut over atomically and defect four stops being a defect, which also means it stops discriminating.
Six lines a minute is the reading budget: 180 lines, 30 minutes [2]. The candidate who opened with camelCase on line 43 spent ten minutes, a third of the slot, on one nit [1], and the account's own framing is that the failure mode is spending your best minutes on formatting nits an autoformatter would have caught, rather than missing a bug [20]. The sixth seeded item, a leftover `console.log` and one inconsistent name, is bait for precisely that reflex [16].
Context is the other lever. Half the seeded defects only look like defects once you know the endpoint is public and unauthenticated, and the interviewer says he answers that honestly when asked but will not volunteer it [18]. Severity here is not a property of the diff. It is a property of the diff plus a fact the candidate has to go and get.
The base rate is where the account is thinnest. Two candidates out of many have ever named the user enumeration issue unprompted, the 404 for unknown accounts against the 200 for real ones, which he ranks as the highest-severity thing in the file [8][9]. Two out of what, though. For that to say something about engineers rather than about one pipeline, you would need the denominator, the seniority mix, and whether the status-code asymmetry is visible in the diff at all or only by reading the handler. None of that is in the write-up. He has run the format for three years and prefers it to any algorithm question he has asked [3][22]; no hire outcomes are attached to the preference.
What ports is the constraint he names, a real review with fourteen PRs in the queue and finite attention [21]. Without a written ranking checked against an incident from your own repo, the score measures how closely a candidate guesses the interviewer's priorities.
Ranked by verification strength, evidence, and original report placement.
The candidate in the opening anecdote had thirty minutes and a 180-line pull request.
Sixty seconds in, the candidate said "Line 43, this variable should be camelCase", and it was the only thing they said for the next nine minutes.
The interviewer switched to the code review interview three years ago and has not gone back.
A code review interview hands the candidate a pull request with seeded defects and asks them to review it out loud as a teammate would; nobody writes new code.
The format scores severity ranking, not defect count: three issues ranked correctly beats six issues thrown out in random order.
The fixture is always the same shape: a PR adding a "resend verification email" endpoint to a service the candidate has never seen, with a route handler, a small service class, one migration and two tests that pass, and green CI.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One practitioner's account, checkable in parts
Everything traces to a single dev.to author describing his own interview round, and none of it has been independently checked. The technical half withstands that: a 404 for unknown addresses beside a 200 for real ones does disclose which accounts exist, a limiter that rewrites lastAttemptAt on rejected requests does slide its own window forever, and dropping verification_token while instances restart one at a time does leave old code reading a missing column. The human half does not. 'Two candidates out of many' has no denominator, and 'backend candidates who've actually shipped catch this' is a recollection rather than a record.
A single interview room
Three years of use by one interviewer is the entire footprint on the record. No hiring team, employer, second company or candidate account appears, and the fixture itself is described rather than shared, so nobody outside that room can run it or compare results.
The comparison claim outruns the tally
The defect descriptions are sober and specific; the claim about what the format proves is not. 'Separates people faster than any algorithm question I've ever asked' and 'much harder to fake' would need pass rates and some downstream signal on the engineers hired, and neither exists here, while the piece's most concrete statistic counts two people against an unstated total. The overstatement sits in the case for the round, not in the six things wrong with the pull request.
The post ends where the product begins
The closing lines disclose that the writer built a tool for practising narrated technical reasoning, which is precisely the skill the round is said to measure and the thing he says candidates only ever practise in interviews. dev.to publishes authors directly, so no editor sits between the argument and what it leads to. The disclosure is made openly, which counts, but the piece still spends 2,000 words establishing a need it then answers.
Coherent, specific, unaudited
Internally the account holds together and is unusually concrete — a named column, a named field, six items in a fixed order, three scored dimensions — which is hard to invent and easy to test against a service you actually operate. What it cannot support is any statement about hiring practice at large, since one interviewer's memory is the only instrument anywhere in the material.
build
Fixed-window rate limits hand an attacker 200 requests in two seconds1 publisher
build
Two workers, one limit: a rate limiter's storage adapter is its outage policy1 publisher
build
Three manual interventions in a month, and every guard was working as designed1 publisher
build
Per-tenant Claude clients belong in the dependency graph, not in middleware1 publisher
Publishers with included, body-backed reporting in this cluster.
1 article · September 7, 2026