Tell me about a time you gave an unfavorable solution to solve a problem.
Asked at:
Microsoft
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see whether you can deliver a solution that others may not want to hear while still acting responsibly and effectively. They are usually testing judgment under constraint: did you understand the problem, weigh tradeoffs honestly, communicate the unpopular answer clearly, and stay accountable for the outcome rather than hiding behind process or authority? Strong answers show maturity around saying "no," "not now," or "a less exciting option" when that is the best path.
“Tell me about a time you had to recommend a solution that people did not want to hear.”
“Describe a situation where the best answer was unpopular. What did you do?”
“Have you ever had to say no, not now, or a smaller version when solving a problem? Walk me through it.”
“What's a time when your recommendation disappointed other people but you still believed it was the right path?”
“Tell me about a time you had to deliver a hard answer instead of the answer others were hoping for.”
Key Insights
- You do not need a dramatic conflict story. A strong answer often centers on constraints, risk, timing, or evidence that led you to recommend an option others found disappointing.
- You should explain why the solution was unfavorable to others, not just that it was. Interviewers want to see that you understood the human impact and handled that part deliberately.
- Honesty is rewarded here. If your answer sounds like you conveniently delivered a tough message that turned out perfectly and cost nothing, it can feel polished but not credible.
What interviewers probe atlevel
Top Priority
Even at junior level, you should show that you recognized someone might be disappointed and tried to be respectful rather than blunt or dismissive.
Good examples
🟢I explained that I could not support the requested change before release, and I walked through the specific issue so the other person understood it was a timing and risk concern, not me ignoring their idea.
🟢I knew my answer would frustrate my teammate, so I first asked what outcome they cared about most and then suggested a smaller option that still addressed part of it.
Bad examples
🔴I just told the designer their idea was not realistic and that engineering had already decided on a simpler version.
🔴I sent a message saying we could not do what was requested because it would be too hard, and I left it at that.
Weak answers treat people as obstacles to the decision; strong answers show the candidate tried to understand what mattered to others and communicated with care.
At junior level, interviewers mainly want to see that you did not optimize for pleasing people over solving the real problem safely and correctly.
Good examples
🟢I had to recommend delaying a small feature because our testing kept showing edge cases we did not understand, and I felt shipping it would create more support issues than value.
🟢The team wanted a faster shortcut, but after a short investigation I recommended the simpler existing component because it met the need and avoided introducing behavior we could not maintain.
Bad examples
🔴I knew the feature was probably too risky, but the team really wanted it, so I suggested we build most of it anyway and clean it up later.
🔴I told my lead we should just keep the old approach because changing it would take too long, even though I had not actually checked what the risks or effort were.
Weak answers avoid discomfort or rely on assumptions; strong answers show the candidate faced reality, evaluated tradeoffs, and recommended the less popular option for sound reasons.
Valuable
Interviewers do not expect perfection from junior candidates, but they do expect honesty about what you knew, what you did not know, and how much support you had.
Good examples
🟢I noticed the issue, gathered what evidence I could, and checked my thinking with a more experienced engineer before recommending we scale back the solution.
🟢I was clear that I was contributing to the recommendation rather than making the final call, but I still owned the analysis and communication I was responsible for.
Bad examples
🔴I knew my recommendation was correct, so I did not really need input from my mentor before telling people we should change course.
🔴I described the decision as if I owned it fully, even though my lead had actually done most of the evaluation.
Weak answers overclaim certainty or ownership; strong answers are accurate about contribution and appropriately calibrated about confidence.
Example answers atlevel
Great answers
In my last internship, a teammate asked if we could add a few extra filters to an internal dashboard right before a demo. After looking at the code and testing it, I realized the current data source was already inconsistent in a few cases, so adding more filters would make the results look precise when they really were not. I told my mentor and then explained to the teammate that I did not think we should add the new filters yet, even though that was disappointing because they wanted to show more flexibility in the demo. Instead, I suggested we clean up one high-value filter and add a note about the others being planned, and I helped make that smaller change the same day. The demo went smoothly, and afterward we fixed the data issue properly before expanding the feature.
At a small fintech where I was a junior engineer, we found a subtle rounding bug in a new payment flow the morning a marketing campaign was scheduled to go live. The product lead wanted to push ahead to meet the deadline, but I recommended we delay the launch and roll the change back rather than risk letting incorrect charges reach customers. I walked the team through the scenarios where balances could be off and explained that a temporary delay would protect user trust and avoid complicated refunds later. The engineers and product manager agreed, I helped implement the rollback and draft a short customer notice, and we fixed the root cause in the next few days. It was disappointing to miss the campaign, but avoiding real money errors felt like the right trade-off for our users and the company’s reputation.
Poor answers
A product person wanted one more option in a page I owned, and I told them no because it was too late to change things. I felt it was better to keep the original plan than to risk introducing bugs, and they were not happy but understood. We shipped on time, which showed it was the right call. In general I think it is important not to let late requests derail engineering work.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late January, 2025
Microsoft
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.