Hiring for Judgment

Most hiring processes for engineers were designed for a world where writing code was one of the hardest parts. We give candidates a problem, watch them solve it, and use the result as a signal of how good they are.

That signal is changing. AI can now write a significant amount of the code we used to ask candidates to write, often well and in seconds. But producing code is only part of engineering. Someone still needs to decide whether that code should exist, understand what it will change around it, and determine whether the proposed solution is actually right.

That’s where I believe the difference between engineers is becoming more visible. Judgment was always important. As execution becomes easier, it matters even more. And yet many interviews still spend surprisingly little time evaluating it.

The test that stopped being enough

A coding exercise used to tell us something useful. If someone could solve it cleanly under some pressure, they probably knew the language, understood the basics, and could be trusted with certain kinds of real work.

Those fundamentals still matter. But the same exercise now tells us less about how someone will perform in an environment where AI is part of everyday engineering.

Some candidates use AI during the test, with or without permission. Others don’t, and spend the interview demonstrating skills they may use very differently once they join the team.

None of this means technical knowledge has stopped mattering. You can’t judge a solution you don’t understand. Being able to reason through code, identify problems, and understand how systems work remains essential.

But knowing how to write code is no longer enough to distinguish a good engineer. And we shouldn’t design our interviews as though it were.

What judgment looks like

Judgment is easy to praise and hard to define. In practice, I think it comes down to three things.

Questioning the value

The first is asking whether something is worth doing before asking how to do it. What problem does this solve? For whom? How will we know if it worked?

This was always important. With AI, it becomes critical, because building the wrong thing is now faster and easier. A team can deliver a polished feature in days that nobody needed. Speed without that question only gets us to the wrong place sooner.

Seeing the system

The second is understanding that every change lands somewhere. And the system isn’t only the code and the infrastructure. People and teams are a system too, with their own dependencies, constraints, and ways of working. A new service creates work for the team that will operate it. A shortcut in one place becomes a constraint in another. A small change in a process can shift costs to a department nobody consulted.

In practice, that means asking a different set of questions. Who else is affected by this? What will they have to do differently? Where does the cost or the effort move to? Who should we talk to before deciding?

AI can help explore those consequences, but it doesn’t automatically understand the organizational context or the trade-offs that matter most. Someone still needs to connect the pieces and take responsibility for the decision.

Not accepting everything

The third is healthy skepticism. AI can produce answers that are well structured and sound confident, even when they’re wrong. The easiest thing to do is accept them. Checking takes time and effort, and an answer that arrives instantly and reads well gives us very little reason to slow down.

It’s a strange double standard when you think about it. If a colleague proposed a solution with the same confidence, we’d ask how they got there and what they checked. Yet AI output often gets less scrutiny than we’d give a person. I wrote more about that risk in As Execution Becomes Easier, Thinking Becomes More Important.

Good engineers look for the weak points, including in their own work. They ask what could go wrong, what was assumed, and what would make this fail. That’s what keeps confident mistakes from reaching production.

The more answers we get for free, the more valuable it becomes to know which ones to trust.

How to look for it

If judgment is becoming more important, interviews should be designed to reveal it. A few approaches seem particularly useful alongside assessments of technical fundamentals.

• Start with an open problem. Give a vague business need instead of a precise specification. Notice whether the candidate asks what it’s for and how success will be measured before proposing anything.
• Ask them to review, not just to write. Show a piece of code or a design, generated or not, with a subtle problem. See whether they find it, and how they reason about it.
• Follow the consequences. When they propose a solution, ask what happens next. Who has to maintain it? What does it change for other teams? What breaks when traffic doubles?
• Talk about a real decision. Ask about a trade-off they made in the past, what they gave up, and what they would do differently. Judgment shows up in how people talk about their own choices.
• Let them use AI, and watch how. If AI is part of the job, it can be part of the interview. What matters is whether they question the output, understand the solution, and recognize its limitations.

None of these approaches is perfect. But together, they can tell us more about how someone thinks than whether they can produce the expected solution to a familiar problem.

The harder case: juniors

All of this is easier to assess in experienced engineers. They have decisions to talk about and mistakes they’ve learned from.

Juniors don’t, at least not to the same extent. If judgment develops through experience, we can’t expect them to demonstrate the same judgment as someone who has spent years making difficult decisions.

What we can look for is the beginning of it. Do they ask why? Can they explain their reasoning? Do they notice when something doesn’t add up, even if they can’t yet say what’s wrong? Are they willing to reconsider an answer when presented with new information?

Those signals are subtle, but they tell us something important about how someone might grow. And that matters just as much as what they already know.

What it says about us

There’s an uncomfortable part to this. Hiring for judgment only works if the organization values it once those people arrive.

If teams are rewarded only for output, someone who questions whether a feature is worth building will look slow. Someone who points out the impact on other teams will look difficult. Over time, we’ll lose exactly the people we worked so hard to hire, or teach them to stop asking.

We can redesign interviews to identify critical thinking, curiosity, and the ability to see beyond an immediate problem. But if our performance evaluations, incentives, and leadership practices continue to reward execution without questioning its value, very little will change.

So the question isn’t only how we interview. It’s whether we’ve built an environment where judgment is welcome.