A Developer Screening Rubric That Isn't LeetCode

Most developer screening still leans on a single LeetCode-style algorithm round, and that’s the wrong tool for what an agency actually needs to know before placing someone with a client. A common setup is a straightforward two-round loop: an algorithm screen, then a system design conversation if that goes well. It filters out people who can’t code at all, which is something, but it also passes candidates who struggle the moment they hit an unfamiliar codebase with a bug nobody can immediately explain. The algorithm round measures the wrong thing well instead of the right thing at all. A five-dimension rubric, one that goes well beyond a single coding challenge, catches the problems that loop misses. Here’s how it’s built.

Why a pass/fail coding round isn’t enough

A LeetCode-style problem tests one narrow skill: can you recall or re-derive a known algorithmic pattern under time pressure. That skill is trainable through repetition, which means it correlates with recent practice more than with general ability. A candidate who has clearly drilled practice problems can ace the algorithm round and then visibly struggle an hour later when handed a real, slightly messy file and asked to find why a test is failing. The algorithm round wasn’t lying about what it measured. It just wasn’t measuring the job.

The five dimensions

Each dimension gets scored 1 to 4, written down immediately after the relevant part of the interview, before moving on to the next section.

Problem framing. Give the candidate a deliberately underspecified task and watch what they ask before they start writing anything. A 1 jumps straight to code. A 4 asks two or three sharp clarifying questions that would have materially changed the approach, then states their assumptions out loud before proceeding.

Code judgment. Not “does it work,” but “would you want to maintain this in six months.” Naming, structure, whether they wrote a test for the part most likely to break, whether they left something obviously fragile without flagging it themselves.

Debugging. Hand them a real, unfamiliar file with a genuine, non-contrived bug, ideally from your own codebase with names changed. Watch how they navigate code they didn’t write. Do they read before they guess? Do they form a hypothesis and check it, or start randomly changing lines? This is the dimension most interview loops skip entirely, and it’s the one that says the most about how someone will actually perform three months in, because reading and fixing unfamiliar code is most of the job most days, not writing greenfield features.

Communication. Do they narrate their reasoning as they go, including the parts where they’re unsure, or do they go silent and present a finished answer? A candidate who says “I’m not sure this is right, let me check” and then checks is showing you something a silently-correct answer doesn’t: how they’ll behave on your team when they hit something they don’t know, which happens to everyone, constantly.

Production instinct. Ask what breaks this in real use, not what makes the current test pass. Do they think about the empty list, the concurrent request, the input a user will eventually send that nobody planned for? This is the dimension most likely to separate “can pass an interview” from “won’t page you at 2 a.m. over something predictable.”

The halo effect is the rubric’s real enemy

The single biggest scoring mistake interviewers make isn’t being too harsh or too lenient on any one dimension. It’s letting one standout answer, usually a clean solution to the coding portion, color every other score upward, even in dimensions that candidate hadn’t actually demonstrated strength in yet. Google’s own re:Work research on structured interviewing names this exact pattern as one of the main reasons unstructured interviews predict job performance so poorly, and the fix is mechanical rather than a matter of trying harder to be objective: score the dimension immediately after that portion of the interview ends, on paper or in the tracking tool, before you talk to the candidate about anything else or compare notes with a co-interviewer. Once you’ve formed a general “this person is great” impression, going back and scoring dimensions independently gets a lot harder to do honestly.

Making the scores actually comparable

A rubric only produces useful data if every interviewer is scoring against the same written definition of a 2 versus a 3, not their own private sense of what “good” looks like. Keep a one-paragraph written description of each score level for each dimension, and run new interviewers through a calibration session, scoring a recorded past interview together and discussing where scores diverged, before they run a real loop solo. Skipping that step is how you end up with five interviewers who each ran a real interview and produced five different personal impressions instead of five comparable data points you can actually act on.

If you’re building out a broader vetting process rather than just this one rubric, it sits alongside the questions we cover in how we think about vetting developers generally, and the choice between a take-home and a live session for the code judgment dimension specifically is its own decision worth getting right. None of this requires more interview time than a traditional loop. It requires spending the time you already have on the dimensions that actually predict performance, and a structured hiring platform can build that into screening for you.