The scorecard we use to turn down 97 developers out of 100. Take it. Use it on us.

Rule out the mismatches before anyone spends an hour on a call.

Catches: The résumé written by someone other than the person who would do the work.

• Unprepared writingWe reply to the application with one open question and read the answer they had no time to polish. Fluency in a rehearsed CV proves nothing about what a Monday morning thread will read like.
• Ownership, not attendanceThey can name one thing they personally built and what it changed. “Worked on the payments team” is attendance. “Took checkout failures from 4% to under 1%” is ownership.
• Output someone outside the company can openA repo, a live URL, a published package, a commit history. We do not need it to be impressive. We need it to exist.
• A real overlap numberHours they commit to in writing, not “flexible”. We record it here and ask the same question again in stage 04 without warning.

Find the floor of what they actually know, not the ceiling of what they can name.

Catches: The candidate fluent in the vocabulary of twelve technologies and the behavior of none.

• Depth in one thingWe take the deepest item on their CV and keep going until they reach the edge of what they know. Everyone reaches it. We are measuring where it is, not whether it exists.
• A decision and what it costA real architectural choice they made, what it bought, what it cost, and what they would do differently now. The last part separates people more reliably than any other question we ask.
• The worst bug they shippedHow it got through, how it was found, and what changed afterwards. A senior engineer with no bad bug has either not shipped or is not telling us.
• Willingness to say “I don't know”At least one question lands outside their stack on purpose. The answer we want is “I don't know, but here's how I'd find out.”

Watch them work. Everything before this is a description of working.

Catches: The developer who interviews considerably better than they ship.

• A timed, real task in their own stackScreen shared, our brief, their editor, their tools. Not a puzzle. A slice of the work they would actually be handed in week one.
• The line that cannot be built as writtenEvery brief we issue contains one requirement that is genuinely ambiguous. We are waiting to see whether they ask or whether they guess. It is the highest-signal thirty seconds in the entire process, because guessing quietly is how a project arrives late and wrong.
• What happens when they get stuckStuck is fine and expected. Stuck and silent for twenty minutes is the thing we are actually testing for.
• Commits as they goMessage quality and commit size tell us more about how someone will behave inside your repository than the finished file does.

Decide whether we would put this person in front of a client we like.

Catches: The yes-man: agrees with everything, and delivers the wrong thing on the last day.

• Pushback on a bad ideaWe propose a technical approach that is genuinely a bad idea and defend it lightly. Agreement is a fail. We are looking for “that will hurt us in six months, and here's why.”
• How bad news travelsWe ask how they would tell you a two-week task has become four. We are listening for “on day two”, not “once I had tried everything”.
• The overlap number, againThe same question from stage 01, weeks later, with no warning. The two numbers match or they don't.
• Curiosity about the businessDo they ask what the product is for and who uses it, or only what the ticket says? The first kind catches the requirement you forgot to write down.