LeetCode scores tell you one thing: how much the candidate has prepared for LeetCode. That is not nothing. Preparation signals interest and conscientiousness. But it is a narrow signal, and over-weighting it in the screen stage produces a candidate pool that is good at algorithm recall under time pressure and uncorrelated with on-the-job engineering performance.
We have spent a lot of time thinking about what the screen stage should actually be trying to learn. The answer, for most backend and platform engineering roles, is not whether the candidate can reverse a linked list in fifteen minutes. It is whether they have sound engineering judgment: the ability to reason about tradeoffs, navigate ambiguity, and arrive at decisions that hold up under scrutiny.
Why judgment is harder to evaluate than algorithms
Algorithm problems have correct answers. Judgment problems do not. When you ask a candidate to implement a binary search, you can check the output. When you ask them how they would decide between building a caching layer and improving database query performance to solve a latency problem, there is no single right answer. You are evaluating the quality of their reasoning process, the variables they surface, the questions they ask, the tradeoffs they name.
This makes judgment harder to score and easier to skip. The LeetCode pass/fail gate is easy to administer, cheap to calibrate, and produces a clean yes/no. Judgment evaluation requires the screener to have enough technical depth to distinguish a thoughtful answer from a confident-sounding one. That is a higher bar for the screener, which is partly why LeetCode-style screens proliferated in the first place.
The cost of that tradeoff is significant. Engineers with strong operational instincts and real system design experience often fail or opt out of algorithm-heavy screens. They know what those screens are actually measuring, and they assess whether the company is worth the preparation time. The teams that rely most heavily on algorithm screens tend to attract candidates who are optimizing for job offers rather than candidates who are optimizing for interesting work.
Signals that actually predict on-the-job performance
Over many hiring cycles, a pattern emerges in which signals at the screen stage are predictive. These are the ones worth investing in evaluating.
Reasoning transparency. Ask the candidate to walk through how they approached a past technical decision. Listen for whether they can surface the constraints they were operating under, the alternatives they considered, and why they chose what they chose. Candidates with good judgment articulate their reasoning in a way that makes sense to someone who was not there. Candidates with poor judgment tend to describe what they did without explaining why, or they describe the outcome without describing the decision.
Failure analysis. Ask about a system or design decision that did not work out the way they expected. How do they characterize what went wrong? Are they specific about the failure mode, or are they vague? Do they take ownership of their contribution to the failure, or do they externalize it entirely? The quality of someone's failure analysis is a strong signal for how they will behave when things go wrong on your team, which they will.
Scope intuition. Give the candidate an underspecified problem and observe how they scope it. Do they immediately write code, or do they ask clarifying questions? Do they identify the right clarifying questions, or do they ask about implementation details before they understand the problem constraints? Good engineers have an instinct for what to clarify before investing effort. That instinct shows up quickly in a well-designed screen problem.
Operational awareness. For roles that involve systems that run in production, ask about monitoring, failure modes, and rollout strategies. Many candidates who are technically competent on paper have almost no operational intuition because their experience is in greenfield environments with minimal production exposure. Operational awareness is hard to build quickly on the job; it is better to screen for it explicitly.
What about technical depth?
We are not arguing that you should stop evaluating technical ability. You should absolutely verify that the candidate understands the systems they claim to have built and the languages they claim to know deeply. The question is how much of the screen to allocate to algorithmic challenges versus technical judgment.
For most mid-level to senior engineering roles, we think the split should be heavily weighted toward judgment. A 30-minute screen that is 20 minutes of system discussion and 10 minutes of a simple implementation problem will tell you more than a 30-minute LeetCode session. The implementation problem should verify that the candidate can write code at a basic competency level, not that they can solve a medium-hard dynamic programming problem on demand.
The exception is roles where algorithmic performance is genuinely core to the work: compiler engineers, ML infrastructure, high-frequency trading systems, search ranking. In those cases, algorithm proficiency is job-relevant and should be screened accordingly. But that is a small fraction of engineering roles, not the default.
Designing the screen around the actual role
One thing we see consistently is that screen design is often decoupled from the role's actual requirements. The screen is a template: here are the questions we ask everyone, here is the LeetCode problem of the month. That template persists because designing a custom screen for each role is time-consuming, and because most people involved in hiring have not thought carefully about what the specific role actually requires at a cognitive level.
A platform engineering role needs operational judgment and systems reasoning. A backend API role needs careful thinking about data modeling and contract design. A staff engineer role needs judgment about organizational tradeoffs and technical strategy. These are different evaluations, and they should be designed differently.
At Fonzi, part of what we think about is how to encode the actual cognitive requirements of a role into the matching and screening process. If the role requires someone who will operate independently and drive decisions without close oversight, the signals we look for in a candidate's history are different than if the role requires someone who will go deep in a specific technical area under a more experienced lead. The screen should reflect that.
The candidate experience argument
There is a second-order effect worth naming: how the screen experience shapes candidates' assessment of your team.
Senior engineers who have been through many hiring processes notice quickly what the screen is designed to evaluate. A well-designed judgment-focused screen signals that the team values the kind of thinking the candidate has spent years developing. An algorithm-heavy screen signals that the team either has not thought carefully about its hiring process or is optimizing for signals that correlate poorly with what the candidate cares about.
The best candidates are evaluating you as much as you are evaluating them. The screen is not just a filter; it is also a first impression of how the team operates. Designing it thoughtfully is worth the time.
