Engineering decision-making in interviews

Why Interviewers Ask This

Staff+ and principal engineer roles require you to operate in conditions of incomplete information and competing priorities, with consequences that affect many engineers and sometimes many customers. Interviewers probe decision-making to understand: do you have a framework, or do you make it up as you go? Do you distinguish between decisions that can be reversed easily and those that cannot? Do you know how to communicate a decision to people who disagree with it?

Type 1 vs Type 2 Decisions

This framework (popularized by Amazon) is genuinely useful and interviewers recognize it. Reference it explicitly:

Common interview failure: treating every decision as Type 1 (over-process, slow teams, consensus paralysis). Equally common: treating every decision as Type 2 (tech debt, migration costs, architectural regret).

Use Type 1 for: architecture choices that touch every service, data schema design, security model, vendor lock-in. Use Type 2 for: feature implementation approach, library choice within one service, local performance optimization.

How Much Information Is Enough

The goal is not to gather all information — it's to gather enough to be confident the decision isn't obviously wrong. For most Type 2 decisions, 70% confidence is enough and waiting for 90% costs more than the decision risk.

A practical frame: what new information, if you had it, would change your decision? If you can name it, go get it. If you can't, you have enough.

Writing Up Decisions

For anything affecting other teams or hard to reverse, write a short decision document:

## Context
What problem are we solving and why now.

## Options Considered
Option 1: [name] — what it is, pros, cons, risks.
Option 2: [name] — same format.

## Decision Criteria
What properties matter most for this decision: operational simplicity, migration cost, latency, etc.

## Recommendation
Which option and why, mapped to the criteria explicitly.

## Dissenting Views Considered
What the strongest counter-argument is and why we decided not to follow it.

## Success Metrics
How we know the decision was right. What we check at 30/90 days.

This template forces you to be explicit about your criteria, which is what prevents "I just had a gut feeling" answers in retrospect.

Communicating Unpopular Decisions

Some decisions will not be popular. The technique that works:

1. Explain the criteria first, not the conclusion. "We needed the option with the lowest ops cost given our on-call load" is received better than "we're going with Postgres."
2. Acknowledge the tradeoff explicitly. "This does mean the migration will take longer than Option B would have. That's a real cost. Here's why we weighted operational risk higher."
3. Show the review point. "We'll check query latency at 60 days. If we're wrong about the workload pattern, Option B is still available to us."

Never pretend there's no downside to the chosen option. Stakeholders who find out later that you knew about the downside and didn't mention it will not trust you on the next decision.

Common Interview Follow-Ups

"Tell me about a decision you made with incomplete information." Describe the information you had, what you couldn't know, how you framed the uncertainty for stakeholders, and what actually happened. Include what you would do differently if you were deciding again.

"Tell me about a decision you regret." Don't pick something trivial — that reads as evasion. Pick something real where you can clearly articulate what you would do differently and what you learned.

"How do you get buy-in from engineers who disagree with a technical direction?" Answer: involve them earlier (before the decision, not after), document the tradeoffs they care about explicitly, and address their concerns in the decision write-up rather than dismissing them.

Quick Recap

1. Type 1 decisions (hard to reverse) deserve deliberate process: write them up, include dissenting views, be explicit about tradeoffs. Type 2 decisions (easy to reverse) deserve speed: bias toward action, adjust on new information.
2. You never have complete information. Define explicitly what additional information would change your decision — if you can name it, go get it. If you can't, you have enough.
3. Write down important decisions. A short document with context, options, criteria, and recommendation forces criteria clarity and creates an audit trail for future learnings.
4. Communicate unpopular decisions by stating the criteria first, acknowledging the tradeoffs honestly, and giving stakeholders a named checkpoint where you will revisit the decision against real data.
5. "Tell me about a decision you regret" is a question about growth and self-awareness. Answer it with a real decision, a clear articulation of what you missed, and what you would do differently.