Most senior-engineer screens test for trivia. Here's how to screen for judgment instead.

Most senior-engineer screens test for trivia. The candidate who memorized the most API surface wins the phone screen, and six months later the team learns that memorization was never the job.

The job is judgment. Which corner is safe to cut this quarter. Which "quick fix" turns into an incident. When to say no to a deadline out loud instead of missing it quietly. None of that shows up in a question with a right answer.

Here is what I would ask instead, and what a real answer sounds like. If you screen engineers for a living, this list is for you.

1. "Tell me about a decision you made that turned out to be wrong. What did it cost, and who found out from you?"

A senior engineer has a real answer with a real cost attached, and the tell is the last part: they told people themselves. A candidate who has never been wrong at anything has either never owned anything or is not telling you the truth. Both are disqualifying for a senior seat.

2. "What is something you shipped the boring version of, on purpose?"

Juniors reach for the clever version because clever is the point. Seniors have shipped enough clever versions to know who pays for them later. You are listening for a deliberate tradeoff: what they gave up, why it was the right quarter to give it up, and what would have made them choose differently.

3. "Walk me through the hardest bug you ever chased. Not the fix. The chase."

The fix is usually two lines. The chase is the job. I once spent a day and a half finding a bug that only showed up under load, three services deep, in code I had not touched in months. The fix took five minutes. A senior candidate lights up describing the chase: the wrong theories, the instrumentation they added, the moment the evidence stopped fitting the story. A candidate who only remembers fixes has been debugging shallow problems.

4. "What did you refuse to build, and how did you say it?"

Every senior engineer has killed a feature, pushed back on a deadline, or told a founder the integration was a trap. What you want is the how. Did they say it early, to the right person, with an alternative in hand? "I quietly knew it was a bad idea" is a mid-level answer wearing a senior title.

5. Replace the algorithm round with an artifact walk.

Ask for something they own: a repo, a design doc, a postmortem, a production system they can narrate. Then ask why questions until you hit the bottom. Why this boundary. Why this database. What breaks first under 10x load. Memorized knowledge runs out in about three questions. Judgment keeps answering, because the candidate actually made those calls and remembers the pressure they were made under.

The pattern across all five: every question asks for a decision with a cost, made under uncertainty, that the candidate personally owned. That is the actual job description of a senior engineer, whether or not the posting says so.

Recruiters who screen this way send hiring managers a shortlist that survives the onsite. That is the whole game.

If you are screening senior React, TypeScript, or Node engineers and want to see what artifact-first proof looks like in practice, the proof section of this site is exactly that: my own work, narrated, with the decisions visible.