Give me an example of a time you committed to a group decision even though you disagreed.
Asked at:
Meta
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can disagree constructively without becoming disengaged, political, or stubborn. Interviewers want to see if you can advocate for your view, understand why others saw it differently, and then fully support the final decision once the group aligns. At higher levels, they also care whether you helped the team make a good decision process, not just whether you personally complied.
“Tell me about a time you disagreed with a team's decision but supported it anyway.”
“Describe a situation where your recommendation wasn't chosen. What did you do next?”
“Have you ever had to get behind a plan you wouldn't have picked yourself?”
“Walk me through a time you pushed for one direction, the group chose another, and you still had to help make it work.”
“Give me an example of a decision you argued against initially but committed to after the team aligned.”
Key Insights
- You do not get credit for quietly losing an argument and emotionally checking out. Show that after the decision was made, you actively helped make it succeed.
- The strongest stories are not about a trivial preference. Pick a disagreement where reasonable people had different tradeoffs, risks, or incentives, and show that you understood those differences.
- You should make clear that you voiced your concerns appropriately before committing. Blind agreement is not maturity; thoughtful dissent followed by aligned execution is.
What interviewers probe atlevel
Top Priority
Show that you spoke up respectfully and tried to understand the decision instead of either staying silent or arguing emotionally.
Good examples
🟢I explained why I thought my approach would be faster, asked what risks the team saw, and learned they were worried about consistency with existing code.
🟢I shared a small comparison of the two options, asked my tech lead to sanity-check my assumptions, and then accepted the team's reasoning.
Bad examples
🔴I knew my idea was better, but since I was new I didn't really say much and just followed the plan.
🔴I pushed my point a few times in the meeting and when people still disagreed, I stopped because there was no point.
Weak answers show passivity or repeated assertion; strong answers show respectful advocacy plus genuine curiosity.
Choose a real decision with some consequence, and show you understood why both options were plausible.
Good examples
🟢I preferred adding a new helper because it felt faster, but the team wanted to reuse an existing pattern to keep the codebase consistent and easier to maintain.
🟢I thought we should keep a feature in the current release, while the group wanted to cut it to reduce risk before a customer deadline.
Bad examples
🔴I wanted tabs instead of spaces, but the team preferred spaces, so I just did what they wanted.
🔴I thought my approach was cleaner, but my senior said to do it another way, so I dropped it because they probably knew better.
Weak answers describe preferences; strong answers describe meaningful tradeoffs like risk, consistency, speed, or maintainability.
Valuable
Show that the experience changed how you handle disagreement, not just that the team moved on.
Good examples
🟢I learned to raise my concerns with evidence and questions earlier instead of forming a private opinion and holding onto it.
🟢It taught me that even when my idea isn't chosen, I still own making the final plan work well.
Bad examples
🔴It taught me that sometimes you just have to do what the team decides.
🔴I learned it's not worth debating too much when more experienced people disagree.
Weak learning is submission; strong learning is better judgment and collaboration.
Show that you saw your teammates as reasonable people with different concerns, not obstacles to your idea.
Good examples
🟢I realized they were the ones who would maintain that code after the release, so their concern about consistency made sense.
🟢The QA engineer was worried about test coverage gaps, which I hadn't fully considered at first.
Bad examples
🔴They were mostly just being cautious and didn't want to try something new.
🔴My teammates didn't really get the benefits, so they chose the safer option.
Weak answers dismiss others' judgment; strong answers recognize legitimate constraints and responsibilities.
Example answers atlevel
Great answers
On one project, I thought we should build a small new utility to handle some repeated validation logic because it seemed faster for me to implement. The rest of the team wanted me to extend an existing shared module instead, even though it looked a little more complicated at first. I explained why I preferred the new utility, and my mentor pointed out that using the shared module would make the behavior more consistent and easier for others to maintain later. Once we made the call, I stopped pushing my version, updated my plan, and asked for help understanding the existing pattern so I could implement it correctly. I also added tests around the areas I had been worried would be harder to change. In the end it worked well, and I learned that consistency across the codebase can matter more than the quickest path for my own task.
On a mobile app sprint I pushed to delay a new recommendation algorithm because I was worried it might surface inappropriate content for some users, but the product manager and most of the team wanted to release it behind a flag to collect real user data. I voiced my concerns, suggested stricter monitoring and a short staged rollout, and when the group decided on the staged release I put my disagreement aside and helped implement the rollout plan. I built a simple dashboard to track key signals (error rates, content reports, and engagement) and volunteered to be on the rotation for rapid response if issues appeared. After a few days we saw one unexpected spike in content reports, caught it quickly, and pushed a small tweak that fixed the problem. I learned that it’s important to raise risks early, but once the team decides, your job is to support the plan and reduce its risks rather than undermine it.
Poor answers
I remember wanting to structure a component differently from the rest of the team because I thought my version was cleaner. They preferred to keep it similar to another component, so we just did that. I didn't think it was worth spending more time on since they had already decided. I finished my part the way they wanted and moved on to the next ticket.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid April, 2025
Meta
Senior
Late March, 2025
Meta
Senior
Late September, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.