In this article
Before you start
This page sits in the behavioral interview guide. It builds on the habit of answering with a real story, covered in how to answer interview questions.
Why interviewers ask this
A weak answer to this question costs you the chance to show judgment, because the interviewer has nothing to score except the size of your project. Interviewers use the question to see how you choose when no option is clearly right. Candidates report variants of it in interviews at large technology companies, for example a risky decision, the largest decision you owned end to end, or an architecture choice that turned out wrong.
A weak answer describes a technology ("we moved to a new database") and stops. A strong answer names the options, says what each one cost, and says what you did to limit the damage if you were wrong. A Staff-level answer also shows how you reached agreement with people who disagreed, and what you changed in how you work afterwards.
The hardest technical decision from first principles
- Architecture decision record (ADR)
- An architecture decision record (ADR) is a short written note that captures one significant technical decision, with the context that forced it, the decision itself, its status and its consequences, so that a later reader can see why it was made.
- Reversible decision
- A reversible decision is a choice you can undo at a cost you can name in advance, such as switching back to the previous system within a day; an irreversible decision cannot be undone, or only at a cost larger than the original project.
- Downside bound
- A downside bound is a limit you put on how much a wrong decision can cost, for example by exposing only a small share of traffic to the change and keeping a rollback switch, so that if the choice proves wrong you can name the worst loss in advance and undo the change quickly.
In plain words
Picture choosing a route for a long drive. You compare roads by time, tolls and risk of a jam. You pick one and keep a phone ready to reroute. The analogy breaks in one place: on a real project, rerouting often costs weeks, so some choices you cannot take back.
In one precise sentence, the hardest technical decision you made is one where the options were close, being wrong was expensive, and the information was incomplete.
Michael Nygard's post on documenting architecture decisions gives a useful shape for the story: the context, the decision, and the consequences. Your answer is an oral version of that note.
Step-by-step description
- Choose a decision with real alternatives.
- Compare options on shared measures.
- Limit the cost of being wrong.
- Give the result and one change.
- Pick one decision with real options.
- State the context and the options, then bound the downside.
- Close with the result and what you would change.
Step 1: Pick a decision with real options
The right decision to talk about has at least two defensible options and a cost you can describe. "Hardest" means the decision was difficult, not that the project was large. A choice between a cron job, a managed queue and a custom stream is a better story than "we adopted a famous framework", because it has options that each lose something.
Input: your list of past decisions. Output: one decision where you can name the alternatives and what you gave up. Choose one you owned or strongly influenced, and one where you can state the outcome honestly, including a cost. If you cannot name a rejected option, the decision was not hard, and the interviewer will hear that. You now have the story; the next step gives it a frame.
Step 2: State the context and the options with numbers
Context is the pressure that forced the decision, and the options are the choices you compared on the same measures. Say what was broken, who felt it, and which measures mattered. Then give each option a number or a plain-words rating on those measures.
Here is an illustrative case. A nightly sync job leaves dashboard data stale; the team compares keeping the job, a managed queue, and a custom stream, on freshness lag (p95 in minutes), a monthly cost index, and migration weeks. With weights of 0.5 on lag, 0.2 on cost and 0.3 on effort, the scores are 0.571, 0.562 and 0.611.1 They sit within 0.05 of each other. With weights of 0.2, 0.4 and 0.4, the keep-the-job option wins at 0.829 and the custom stream falls to 0.403.1 The matrix did not decide anything; it showed that the weights were the real argument.
| Option (illustrative) | Freshness lag p95 (min) | Cost index | Migration weeks | Score, lag-heavy weights |
|---|---|---|---|---|
| Keep cron job | 42 | 100 | 0 | 0.571 |
| Managed queue | 9 | 130 | 3 | 0.562 |
| Custom stream | 6 | 240 | 10 | 0.611 |
Text description of the diagram
- With lag-heavy weights the custom stream scores 0.611 and the managed queue 0.562.
- With cost-heavy weights keeping the job scores 0.829 and the custom stream 0.403.
Step 3: Bound the downside before you commit
A downside bound turns a risky choice into a controlled one, and it is the part of the answer that shows seniority. Ask one question of each option: if I am wrong, what does it cost and how fast can I undo it? In the example, the custom stream needs 10 weeks of producer rewrites and a new storage format, so switching back means undoing that migration. The managed queue sits beside the existing job, so turning it off restores the old path in a day. The team picks the option it can reverse.
A canary release is a rollout that sends a small share of real traffic to the new path first while the old path stays live, and it is the tool here. In the illustrative case the system handles 40,000 jobs a day. A canary at 5 percent exposes 2,000 jobs a day, so a two-week trial puts 28,000 job runs at risk instead of 560,000, which is 5 percent of the exposure.1
Say this aloud: "I limited the cost of being wrong to this much, and I could undo it by doing that." Reversible choices can be made faster; for irreversible ones, spend more time gathering evidence. The 2016 shareholder letter makes this point with its "two-way doors" passage. The next step is how to end the story.
Step 4: Decide, then give the result and what you would change
Close with what you chose, what happened, what it cost, and what you would do differently. Interviewers listen hardest to the last two. A result with only good news sounds rehearsed, so name one real cost, such as higher infrastructure spend or a team that had to learn to operate a queue.
If people disagreed, say how it was resolved. Amazon lists Have Backbone; Disagree and Commit among its leadership principles, and its 2016 shareholder letter discusses deciding without full information and committing once the choice is made. A candidate can borrow the idea without naming a company: say what you argued, what you agreed to, and how you checked afterwards. The Amazon Leadership Principles page covers the wider set, and influencing without authority covers winning agreement.
The "what I would change" sentence is the one that separates levels: it shows you learned something specific and acted on it.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
What is the hardest technical decision you made?
Our nightly sync left dashboards forty-two minutes stale at p95, and I had to choose between keeping the job, a managed queue, or a custom stream. I compared them on freshness, cost and migration effort, and the scores were too close to decide, so I asked which choice I could undo. Two senior engineers wanted the stream.
The queue sat beside the old job and could be switched off in a day, while the stream needed producer rewrites we could not cheaply undo. We agreed to run the queue canary and revisit with its data. Five percent of traffic for two weeks cut lag to nine minutes. The cost was higher spend and a team learning queue operations. Since then I set up alerting before any canary starts.
The numbers in this answer are illustrative and come from the worked case above. What makes it Staff-level: it picks the option by reversibility rather than by score, it bounds the downside, it resolves a disagreement with data, it names a real cost, and it ends with a practice already changed.
The spoken structure: the pressure, the options, the way you limited the risk, the result, the cost, the change.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Options | Describes a tool choice with no alternatives | Names two or more real options | Compares options on shared measures |
| Depth | States the final choice only | Says why the chosen option won | Shows the weights or constraints behind the choice |
| Trade-offs | Claims no downside | Names one cost | Bounds the downside and picks the reversible path |
| Communication | Rambles, no structure | Context, decision, result | Adds disagreement handling and a clear close |
| Follow-up readiness | Cannot say what went wrong | Can say what they would change | Has already changed a practice because of it |
This table is advice about what a strong answer shows. It is not a score sheet from any company.
Three variants of this question
Tell me about a time you had to kill a project.
Use the same frame: the evidence that the project would not pay off, the options (continue, shrink, stop), how you limited the sunk cost, and how you told the people involved. The decision is hard because stopping feels like failure; name what the team kept.
Describe a time a major architectural decision of yours turned out to be wrong.
Say how you found out (a metric, an incident, a user complaint), how fast, and how you walked it back. A reversible choice shows its value here. Own the mistake in one sentence and spend the rest on the fix and the change in practice.
Walk me through the largest technical decision you've owned end to end.
Add scope: who you brought in, how you wrote the decision down (an ADR works), how you rolled it out, and how you measured the result months later. The interviewer wants ownership across the whole lifecycle, not only the moment of choosing.
Common mistakes
- "We picked the best technology." (wrong) It names no alternatives. (right) "We compared three options on freshness, cost and effort, and chose the one we could undo."
- "The matrix said option B." (wrong) Weights flip close scores, as the worked case shows. (right) "The scores were close, so I decided on reversibility and checked with a canary."
- "There was no downside." (wrong) It sounds rehearsed. (right) "The cost was higher spend, and I would add alerting earlier."
- "I waited until I was certain." (wrong) Certainty rarely arrives. (right) "I decided with the evidence I had and bounded the risk so being wrong was cheap."
- Describing only the team's work. (wrong) The interviewer cannot see your role. (right) "I proposed the options, ran the comparison and owned the rollout."
Follow-up questions
How do you describe a risky decision you made?
Name the risk in one sentence, compare the options, then say how you bounded the downside (a canary, a rollback switch, a time limit) and what you decided. The decision making questions page covers neighboring prompts.
How do you pick which technical decision to talk about?
Pick one with real alternatives, a cost you can state and an outcome you can describe honestly. A smaller decision you understand deeply beats a famous one you only watched. A decision that changed the course of a project or a feature works well, because the before and after are easy to describe.
What if the decision turned out to be wrong?
Say it plainly, say how you found out and how you recovered, and finish with the practice you changed. Candidates often find this answer stronger than a clean success, because it shows judgment under error.
What if the bottleneck was not where you expected?
Tell it as a decision: your first hypothesis, the measurement that disproved it, and the pivot. The measurement is the hero of that story, not the fix.
What if you never owned a big decision?
Use a decision you influenced and say exactly what you contributed. Scope matters less than clear options and honest reasoning. The common interview questions guide shows how to adapt one story to several prompts, and the greatest weakness page uses a similar "what I changed" close.
How long should the answer be?
About a minute for the first answer, with detail held back for follow-ups. Say the pressure, the options, the bound, the result, the cost and the change, then stop.
- Pick a decision with real options and a cost you can name.
- Compare options on the same measures, and know that close scores depend on weights.
- Bound the downside and prefer the reversible path when the evidence is thin.
- End with the result, one honest cost and what you would change.
- Never describe only the tool; describe how you chose.
Sources
- Documenting Architecture Decisions — Cognitect (Michael Nygard), 15 Nov 2011
- Amazon 2016 Letter to Shareholders — Amazon, 12 Apr 2017
- Amazon Leadership Principles — Amazon (accessed 2026-10-26), 26 Oct 2026
