Describe a situation where you had to make a tough decision and what factors you considered
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.
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
Even at junior level, explain the options you saw and the tradeoffs you weighed instead of saying you just picked what felt right.
Good examples
🟢I compared the impact of a one-day delay against the risk of putting a visible bug in front of users, and I checked how often the edge case occurred before deciding.
🟢I looked at how likely the issue was, how hard it would be to roll back, and whether we had a safe workaround for users.
Bad examples
🔴I went with the faster option because it seemed simpler, and I felt that was the best call.
🔴I chose to ship because my lead seemed busy, so I assumed delay would be worse.
Strong answers make the reasoning legible and grounded in facts or explicit tradeoffs; weak answers rely on gut feel or borrowed confidence.
Valuable
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
Late April, 2025
Late April, 2025
Hello Interview Premium
Your account is free and you can post anonymously if you choose.