Tell me about a time when you made an unpopular decision
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you handle situations where doing the right thing required disappointing or opposing other people. They want to see whether your decision was grounded in sound judgment, whether you understood why others disagreed, and whether you took responsibility for both the decision and its consequences. At higher levels, they are also checking whether you can balance conviction with empathy and maintain trust while making hard calls.
Key Insights
- You do not need a dramatic fight. A strong answer often involves competing priorities, risk tolerance, or timeline pressure rather than emotional conflict.
- You should explain why the decision was unpopular from other people's perspective, not just why you thought you were right. That is often the clearest signal of empathy and judgment.
- Do not make the story about 'I stood firm and won.' The strongest answers show how you listened, adapted where appropriate, communicated clearly, and still owned the final outcome.
What interviewers probe atlevel
Top Priority
Do not just say you made the call; explain how you raised it, discussed it, and followed through.
Good examples
🟢I brought the issue to my mentor and the on-call engineer, shared the evidence I had gathered, and helped prepare the smaller safe release so we could still ship something on time.
🟢I explained the failure clearly, suggested a narrower fallback option, updated the testing notes, and stayed available while we verified the revised plan.
Bad examples
🔴I told the team in chat that we should delay it and left it there.
🔴I removed the risky part from the release branch and then explained afterward why I had done it.
Weak answers make the decision feel abrupt or unilateral beyond the candidate's remit; strong answers show timely communication, appropriate consultation, and practical follow-through.
Valuable
Example answers atlevel
Great answers
In my first year, I was helping with a small settings feature that was supposed to go out at the end of the sprint. While testing, I found a bug where under a specific sequence, a user could lose saved preferences. The product partner and another engineer were hoping to ship anyway because the feature had already been mentioned in release notes, but I recommended pulling just that part of my change and keeping the rest of the release. I showed the bug, explained how often I thought a real user could hit it, and suggested a smaller safe release so we didn't block everything. We shipped the reduced version, fixed the issue the next week, and didn't see the support problems we were worried about. What I learned was that when I bring evidence plus an alternative plan, it's much easier to make a hard recommendation even if it's not what people want to hear.
At my last internship, I was helping the team update a weekly operations report that a lot of people used, and I noticed the numbers looked cleaner if I left out a column that was often blank. I suggested removing it because it made the report easier to read, but my manager pushed back since that column showed whether a shipment delay had been confirmed or was still just a risk. It was unpopular because the shorter version looked better and a few teammates thought the extra detail would confuse people. I kept the column in and instead added a short note at the top explaining how to read it, even though that made the report less polished. A week later, one of the coordinators said that column helped her catch a problem early and avoid giving the wrong update to a customer. That taught me that being helpful isn't always about making something look simpler; sometimes it's about preserving the information people actually need.
Poor answers
One time I made an unpopular decision to delay a release because I had a bad feeling about it. People were frustrated because we had been aiming for that date, but I thought it was better to be safe than sorry. I told the team we should just wait and they agreed after some discussion. It turned out fine, and I think it showed that I'm willing to stick to my judgment even when others disagree.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late November, 2025
Title is self-explanatory . You may find this question hard to come up with a story initially. However, one way to think about this problem is that for example you could think about a case where you made a process improvement that the team was so used to, focusing on the following pieces: - how did you detect the inefficiency? - how did you advertised your plan? - who did you collaborate with? - how did you manage the communication with stakholders and teams?
Hello Interview Premium
Your account is free and you can post anonymously if you choose.