Skip to content
Client Login Start a project
{{ p.cat }} · {{ p.readLabel }}

{{ p.title }}

{{ p.dek }}

{{ p.initials }}
{{ p.author }} · {{ p.authorRole }}{{ p.ameta }}

Our product promises that every decision it makes can be explained. It would be odd to build that with a team whose own decisions could not be. Technical skill is necessary for the work, and it is the easier quality to assess. Judgment, the ability to make a sound call with incomplete information and say why, is harder to see in an interview, and most of our work depends on it.

What we mean by judgment

In practice, judgment shows up as a small set of habits:

  • naming the assumption a decision rests on;
  • saying what evidence would change it;
  • choosing the simpler approach when the more sophisticated one does not earn its complexity;
  • noticing when a metric is moving for the wrong reason.

Each of these is a small act of explanation, and each is visible in how a person talks through their work.

How we look for it

We rely less on puzzles and more on conversations about real work. Candidates walk us through a decision they made on a past project: what they knew, what they did not, what they chose and what happened. The most useful part is usually the end, where they describe how they found out whether it worked and what they would change.

We also ask candidates to explain a technical idea to someone outside their field. Our engineers write reasons that shoppers read and explanations that merchandisers and compliance reviewers rely on, so translating without distorting is part of the job.

And we watch how people change their minds. When we offer a counterexample, a strong candidate takes it seriously, updates where it is right, holds their position where it is not, and can say which is which.

How it shows up in the work

The same habits run through how we build. Significant technical decisions are written down with the alternatives considered and the reason for the choice, so someone joining later can follow them. Experiments are planned before they run, with the metric and the threshold stated in advance, and results are reported with their uncertainty. Good engineering teams often work this way. For a company whose product is explanation, it is the minimum.

Trade-offs

Hiring for judgment is slower and less standardized than hiring by checklist. Conversations about past decisions depend on the interviewer’s skill, and they can favor fluent storytellers over people who are thoughtful but quiet. We offset that with structured questions, more than one interviewer, and a written alternative for candidates who prefer it. It also narrows the pool: some excellent specialists would rather do the work than explain it, and for a few roles we accept that trade.

The test we apply is simple. If a person can explain a decision clearly enough that a colleague could disagree with it on the merits, they are likely to build systems whose decisions can be explained too.

Read about the team

The takeaway

A company that sells explainable decisions has to hire people who can explain their own. Look for it in how candidates reason about real work, translate for other audiences and change their minds, and keep the same habits in how decisions are made and recorded.

New posts, straight to your inbox.

Thanks. We’ll email {{ subEmailShown }} when a new post is out.

{{ subErrorText }}

Unsubscribe at any time.