Describe a situation where you had to make a tough decision and what factors you considered
Asked at:
Amazon
Automata
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess judgment under pressure: how you evaluate tradeoffs when there is no obviously perfect answer. They want to understand whether you can balance speed, quality, risk, people impact, and business needs in a way that matches your level. A strong answer shows not just what you decided, but how you reasoned, what alternatives you considered, and how you handled the consequences.
“Tell me about a time you had to choose between two imperfect options.”
“What's an example of a high-stakes decision you made when the right answer wasn't obvious?”
“Describe a decision you made that involved significant tradeoffs. How did you approach it?”
“Have you ever had to make a call that was unpopular or risky? What went into your thinking?”
“Walk me through a situation where you had limited information but still had to decide.”
Key Insights
- You do not need a dramatic crisis story. What matters is that the decision was genuinely consequential for your level and involved real tradeoffs rather than an obvious right answer.
- Do not spend all your time describing the situation and the final choice. Interviewers are listening for your decision framework: what options existed, what risks you weighed, and why one path was better than the others at that moment.
- You should show that tough decisions include second-order effects on people, maintainability, trust, or future execution, not just immediate delivery pressure.
What interviewers probe atlevel
Top Priority
You do not need to be the most senior person in the room, but you should still show initiative in gathering input and acting responsibly.
Good examples
🟢I brought my analysis to my lead, recommended delaying by a day, and then owned the follow-up work to fix and retest the issue.
🟢I asked for a quick second opinion, but I made a clear recommendation and handled the communication and implementation once we aligned.
Bad examples
🔴My manager told me to delay it, so that was the tough decision we made.
🔴I sent the issue to my teammate because they had more experience, and then I waited for them to decide.
Strong answers show agency within appropriate bounds; weak answers outsource the hard part and claim proximity as ownership.
Pick a decision that mattered within your area of ownership and had real tradeoffs, even if the scope was small.
Good examples
🟢I had to decide whether to ship my part of a feature with a known edge-case bug before a campus launch or delay my portion and miss the event.
🟢I had to choose between patching a flaky test to unblock a release quickly or spending extra time finding the underlying issue and risking a one-day slip.
Bad examples
🔴I had to decide whether to use dark mode or light mode for a demo, and I picked dark mode because it looked more modern.
🔴I had to choose whether to ask my teammate a question right away or spend another ten minutes debugging first, and I decided to ask.
Strong answers involve a decision with meaningful consequences inside the candidate's actual scope; weak answers mistake any choice for a tough decision.
Valuable
Even for small-scope decisions, show awareness of how your choice affected teammates or users.
Good examples
🟢I considered that shipping the bug would create extra work for support and confusion for users, which pushed me toward a short delay.
🟢I knew delaying would affect my teammate's test plan, so I communicated early and adjusted the order of work to reduce disruption.
Bad examples
🔴I shipped it because my part was done, and if support found issues later we could deal with them.
🔴I delayed the work without telling QA until after I had already made the choice.
Strong answers show perspective-taking; weak answers optimize only for the candidate's immediate convenience.
You do not need a perfect ending, but you should show what happened and what you learned about making decisions.
Good examples
🟢The delay let us fix the issue before users saw it, and I learned to quantify the impact of an edge case before treating it as minor.
🟢We shipped with a workaround and monitored it closely; when the issue appeared less often than expected, I still followed through on the permanent fix so we would not normalize temporary patches.
Bad examples
🔴We delayed and it worked out fine, so that confirmed it was the right call.
🔴I shipped it, nothing immediately broke, and that was basically the end of it.
Strong answers show reflection and follow-through; weak answers use a lucky outcome as proof of good judgment.
Example answers atlevel
Great answers
On a small feature for our onboarding flow, I found a bug where users with a certain account state could get stuck after submitting the form. We were a day away from a student-focused launch, so the tough decision was whether to ship on time and fix it later, or ask for a short delay on my part of the release. I checked how often that account state occurred, confirmed there wasn't a safe fallback, and realized support would have no easy workaround if those users hit it. I recommended delaying my piece by a day, walked my lead through the tradeoff, and took ownership of fixing and retesting it that afternoon. We launched one day later without the issue, and it taught me to think beyond whether a bug is rare and instead look at how recoverable it is if users hit it.
I was the primary owner of our team's continuous integration and test suite, and two weeks before a scheduled release I had to choose between spending a week stabilizing a set of flaky end-to-end tests or building a small, high-visibility UI polish the product manager wanted. I weighed how often those tests failed (several times a day), how much developer time was wasted rerunning jobs, the risk that flaky tests would mask real regressions in the release, and the product team's timeline and expectations. I decided to prioritize the test stability, but I communicated the tradeoffs to the PM and agreed to ship a minimal visual improvement that wouldn’t risk the release. After stabilizing the suite, our CI failures dropped substantially, which sped up the next three releases and reduced context switching for everyone. I learned to balance short-term stakeholder visibility with long-term developer productivity and to make my decision together with the team so no one was blindsided.
Poor answers
I had a tough decision during an internship when I was building a settings page and had to decide whether to keep debugging a strange edge case or just merge my code so the sprint work stayed on track. I chose to merge because the main flow was working and the edge case seemed pretty unlikely. My mentor agreed that we could always patch it later if anyone noticed. The feature shipped on time, so I think that was the right call.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late May, 2025
Automata
Senior
Late April, 2025
Amazon
Mid-level
Late April, 2025
Amazon
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.