How do you handle disagreements on technical approach within a team
Lead with curiosity not advocacy — understand their reasoning first. Anchor on shared goals and objective criteria (data, prototypes, constraints). Disagree-and-commit once a decision is made. Use a STAR story showing you changed your mind or supported a decision you lost.
This question tests collaboration and ego, not who's technically right. The interviewer wants to see you can disagree productively and commit gracefully.
The framework
1. Seek to understand first. Before arguing your position, get curious: "Help me understand why you'd go with X." Often you're missing context — a constraint, past incident, or requirement they know about. Sometimes you change your mind here, and that's a win.
2. Anchor on shared goals. Re-center on what you both actually want: ship reliably, maintainable, on time. Most "disagreements" are really different weightings of the same goals.
3. Make it objective, not personal. Move from opinion to evidence:
- Data — benchmarks, error rates, bundle size.
- A spike/prototype — when it's cheap, build a small version of each and compare. Evidence ends most debates fast.
- Explicit criteria — agree on what "better" means (performance? velocity? risk?) before judging options.
4. Time-box it. Don't let it stall the team. If it's reversible and low-stakes, just pick one and move on — the cost of debating exceeds the cost of being wrong.
5. Escalate cleanly if needed. If you genuinely can't converge and it matters, bring in a tech lead or architect — framed as "we want a tie-breaker," not "tell them they're wrong."
6. Disagree and commit. Once the team decides — even against you — you commit fully. No "I told you so," no half-hearted execution. Voice the concern, document the risk if real, then row in the same direction.
A STAR story (have one ready)
Situation: Teammate wanted to adopt a new state library; I thought our existing approach was fine. Task: Decide without stalling the feature. Action: I asked what pain they were solving, realized it was real (prop-drilling in a specific area). We agreed on criteria and time-boxed a spike. The data showed it helped that area but wasn't worth a full migration. Result: We adopted it scoped to that module. I was partly wrong, partly right — and the decision was evidence-based, not a turf war.
The strongest version of this story is one where you lost the argument and committed, and it worked out fine — that shows the ego is in check.
The framing
"I lead with curiosity — understand their reasoning before defending mine; sometimes that ends it. Then I make it objective: shared criteria, data, or a quick spike instead of dueling opinions. I time-box it so it doesn't stall the team, escalate for a tie-breaker only if it truly matters, and once we decide, I disagree-and-commit — full execution even if it wasn't my pick."
Follow-up questions
- •Tell me about a time you were wrong in a technical debate.
- •How do you commit to a decision you disagreed with?
- •When would you escalate vs. just letting it go?
- •How do you disagree with someone more senior than you?
Common mistakes
- •Framing it as winning vs. losing instead of finding the best outcome.
- •Making it personal or questioning competence.
- •Refusing to commit after a decision goes against you.
- •Letting the debate drag and block the team.
- •Telling a story where you were right and everyone else was wrong — reads as arrogant.
Performance considerations
- •Not applicable — behavioral. The 'performance' angle is team velocity: unresolved disagreements and re-litigated decisions are a real drag on delivery.
Edge cases
- •Disagreeing with a manager or staff engineer — be respectful but still bring evidence.
- •A decision that's hard to reverse — worth more rigor before committing.
- •A teammate who won't engage with the evidence — escalate.
Real-world examples
- •Settling a 'REST vs GraphQL' debate with a scoped prototype and agreed criteria.
- •Committing fully to a teammate's architecture choice after voicing concerns in the design review.