We interview seniors with binary trees on a whiteboard, then hire them to argue about API shapes.

We interview senior engineers by asking them to invert a binary tree on a whiteboard, then hire them to spend the next three years writing forms, fixing flaky tests, and arguing about API shapes.

The mismatch is so normalized that naming it sounds naive. But look at it plainly: the interview tests recall of algorithms under a timer, with an audience, and no tooling. The job requires judgment across months, with full tooling, where the hard problems are ambiguity, legacy constraints, and other people. The two skill sets barely overlap, and the overlap shrinks with seniority.

You cannot LeetCode your way to judgment. Judgment is knowing which of the six ways to build the feature will still be the right way in a year. It is reading a diff and sensing that the edge case nobody mentioned is the one that pages someone at 2 AM. It is telling a stakeholder no early instead of missing the date quietly. Nothing about a timed puzzle measures any of that, and the people best at timed puzzles are often simply the people who most recently practiced timed puzzles.

The defense is always standardization: algorithm rounds are consistent and cheap to grade. True. So is measuring candidates by height. Consistency of a measurement means nothing if the measurement does not predict the job.

What predicts the job is watching someone do the job's actual moves. Walk through a system they own and ask why until you hit bottom. Have them review a realistic diff with a planted subtle bug. Give them an ambiguous requirement and watch what questions they ask before writing anything. None of this is exotic. It is just harder to grade than a binary tree, and hiring processes consistently choose easy grading over predictive power.

If you hire engineers: what is the one thing in your process that actually predicts who is good? If you cannot answer, the process is measuring something else.