What's your approach when an engineer disagrees with a technical decision?
Why This Is Asked
Interviewers want to see that you value technical input and don't shut down dissent. They're assessing whether you create space for debate, consider the engineer's perspective seriously, and make a decision that the team can support—even if not everyone agrees—while explaining your reasoning.
Key Points to Cover
- Listening to the engineer's perspective and understanding their reasoning
- Evaluating the disagreement on merit (data, trade-offs, risk)—not hierarchy
- Making a decision when needed and explaining the rationale
- Ensuring the engineer feels heard and can commit to the decision
STAR Method Answer Template
Describe the context - what was happening, what team/company, what was at stake
What was your specific responsibility or challenge?
What specific steps did you take? Be detailed about YOUR actions
What was the outcome? Use metrics where possible. What did you learn?
💡 Tips
- Show that you're open to being wrong—sometimes the engineer has the better idea
- Emphasize that disagreement is healthy; the goal is a good decision, not consensus at all costs
- Give an example where an engineer's dissent changed your mind
✍️ Example Response
STAR formatSituation: I'd decided we'd use a particular database for a new service—it was what we used elsewhere, and I wanted consistency. A senior engineer pushed back: "That database doesn't fit this use case. We need something with better read scaling." I was initially resistant—I didn't want to add another technology to our stack.
Task: I needed to evaluate the disagreement on merit and make a decision the team could support.
Action: I asked the engineer to present their case: what were the trade-offs? What would the alternative require? They came with benchmarks and a migration path. I listened. I realized they were right—our chosen DB would require significant workarounds for the read pattern. I changed my mind. I said in the team meeting: "I was wrong. [Engineer] made a strong case, and we're going with their recommendation." I made sure the engineer got credit. I also explained my initial reasoning so the team understood the decision process. For future decisions, I started explicitly asking "Who disagrees? What am I missing?" in architecture reviews.
Result: We used the recommended database and it performed well. The engineer felt heard and later told me they appreciated that I could change my mind. I learned that the best decisions come when you create space for dissent and are willing to be wrong. Hierarchy shouldn't override good judgment.
🏢 Companies Known to Ask This
| Company | Variation / Focus |
|---|---|
| Amazon | Have Backbone Disagree & Commit, Are Right a Lot — "How do you handle technical disagreement?" |
| Technical excellence, collaboration | |
| Meta | Impact at scale, hard calls |
| Microsoft | Growth mindset, collaboration |
| Stripe | Technical judgment |
| Apple | Excellence, deep collaboration |