Tell me about a time when you made a difficult decision with input from many different sources.
Asked at:
Amazon
Meta
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you make decisions when the answer is not obvious and multiple people have valid, competing input. They want to see whether you can gather perspectives, separate signal from noise, make a clear call, and own the outcome. At higher levels, they are also testing whether your decision process scales beyond your own work and whether people could trust you with consequential tradeoffs.
“Describe a situation where you had to make a call after getting conflicting advice from several people.”
“Tell me about a time when many people had input, but you still had to decide on a direction.”
“What's an example of a decision you made where the stakeholders all wanted different things?”
“Have you ever had to choose between competing recommendations from teammates or partners? What did you do?”
“Walk me through a hard decision where you had to weigh a lot of perspectives and then make the final call.”
Key Insights
- You do not get credit just for collecting lots of opinions. You need to show how you evaluated conflicting input, what principles or goals you used, and why your final decision was reasonable.
- Many candidates accidentally tell a consensus story instead of a decision story. If everyone already agreed, the interviewer learns less; the strongest answers involve real tension, incomplete information, or competing priorities.
- You should make clear how you communicated the decision and what happened after. A mature answer shows not just the choice itself, but how you brought people along and validated whether it worked.
What interviewers probe atlevel
Top Priority
Even early-career candidates should show some reasoning framework, not just 'I asked around and picked one.'
Good examples
🟢I wrote down the key concerns people raised, compared them against our deadline and bug risk, and chose the path that reduced user impact even though it meant cutting a small part of scope.
🟢I noticed the input conflicted because people were optimizing for different things, so I checked what our main goal was for that release and used that to decide.
Bad examples
🔴People had different views, so I went with the opinion from the most senior person.
🔴I listened to everyone and then chose the option that felt simpler without doing much to compare the tradeoffs.
Weak answers outsource judgment or rely on instinct alone; strong answers show the candidate used explicit criteria to make sense of competing input.
For junior candidates, the bar is not huge organizational scope; it is showing that the decision mattered within your area and that you understood why it was difficult.
Good examples
🟢I had to decide whether to delay a small feature to fix a reliability issue after getting different input from my mentor, QA, and the product owner, because shipping on time and reducing user-facing bugs were in tension.
🟢On a project I owned a clear piece of, I had to choose between reusing an older component or building a simpler new one after hearing conflicting advice about speed, maintainability, and risk.
Bad examples
🔴I had to choose which color scheme to use for an internal page after asking a few teammates, and I picked the one most people liked.
🔴I asked a few people whether to write tests before or after coding, and since opinions were mixed I just followed what I was already doing.
Weak stories involve low-stakes preference choices; strong stories involve a real tradeoff that affected delivery, quality, or users within the candidate's actual scope.
Valuable
You do not need to sound managerial, but you should show curiosity about others' concerns instead of treating disagreement as friction.
Good examples
🟢I followed up one-on-one because I realized the disagreement was about prior bugs they had dealt with, not because they disliked my approach.
🟢I asked each person what risk they were most worried about, and that helped me see that they were focusing on different failure modes.
Bad examples
🔴One teammate kept pushing back, but I assumed they were just being overly cautious.
🔴I heard different suggestions and didn't dig into them because I mostly needed an answer quickly.
Weak answers flatten other people into obstacles; strong answers show the candidate understands the reasoning behind the input.
It is not enough to decide; show that you explained the decision clearly so others knew what would happen next.
Good examples
🟢I summarized the options, the reason for my recommendation, and the next steps in a short message so my mentor, QA, and product owner were all aligned.
🟢I explained specifically what we were doing now, what we were not doing, and when we would revisit the deferred piece.
Bad examples
🔴I made the choice and updated the code, so people could tell what I decided from the result.
🔴I mentioned the decision in our chat thread and assumed that was enough.
Weak answers treat communication as incidental; strong answers show the candidate made the decision legible and actionable.
A good answer does not stop at 'I decided'; it shows whether the choice worked and what you learned from making it.
Good examples
🟢After release, I checked whether the bug rate and support questions dropped as expected, and that gave me confidence the tradeoff was right.
🟢I learned that asking for input earlier would have made the decision easier, so I started doing that on later tasks.
Bad examples
🔴After I made the decision, we moved on, so I assumed it was the right call.
🔴The project finished, which told me the decision process was fine.
Weak answers use completion as proof; strong answers verify impact and extract a repeatable lesson.
Example answers atlevel
Great answers
During my first year, I owned a small part of a reporting feature and had to decide whether to keep a planned export option or delay it to fix a reliability issue we found late in testing. I got different input from my mentor, who thought we could patch it later, from QA, who was worried users would hit repeated errors, and from the product owner, who wanted to keep the release date. I wrote down the tradeoff as user impact versus feature completeness and suggested we remove the export option from this release, fix the reliability issue first, and add the export in the next sprint. I shared that recommendation in our project chat with the reasoning and the updated plan, and my mentor agreed with the approach. We released on time with fewer bugs than expected, and support didn't get the questions QA had been worried about. What I learned was that when people disagree, it helps to ask what risk each person is actually trying to avoid instead of just comparing opinions.
At my previous job I was asked to choose the authentication provider for a small pilot app and had to balance very different inputs. The security engineer favored Provider A for its compliance features and audit logs, finance warned that A’s per-user fees would blow the pilot budget, product and our pilot customers wanted the quick SSO support Provider B offered, and my mentor pushed me not to delay the rollout. I created a short decision matrix scoring compliance, cost, implementation speed, and migration effort, and recommended we use Provider B for the pilot because it met the immediate needs and allowed a clean migration path later. I also proposed concrete mitigations—strict key rotation, enhanced logging, and a tested migration plan—and documented the trade-offs in an email to get explicit sign-off from security and finance. The pilot launched without auth incidents, and I learned the value of a simple, evidence-based comparison plus a contingency plan when stakeholders disagree.
Poor answers
I had a case where a few people gave me different suggestions on how to build a page for an internal tool. One engineer wanted me to reuse an older component, another said I could just write a quick new version, and design had a few preferences too. I decided to build the new version because it seemed easiest and I wanted to keep momentum. I sent the link when it was done and everyone used it, so it worked out well. I think the main thing is not to overcomplicate decisions when a team needs something quickly.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early September, 2025
Meta
Senior
Early November, 2024
Amazon
Mid-level
Tell me about a time when you made a difficult decision with input from many different sources (customers, stakeholders, partner teams, and so on). What was the situation and how did you arrive at your decision? Did the decision turn out to be the correct one? Why or why not?
Mid October, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.