How do you handle conflict at work?

Walk me through an occasion when you and a teammate were at odds — say, over which technical path to take, what to prioritize, how good the code needed to be, or who owned a piece of work.

Please cover:

• What was the situation, and what hung in the balance?
• What was the disagreement, specifically?
• What did you do to work through it?
• How did things turn out, and what did you learn?

Follow-ups:

• How do you approach conflict when someone else holds the decision?
• How do you approach conflict when you're sure the other person is simply wrong?
• What would you handle differently if it happened again?

Overview: This question asks about a specific disagreement with a teammate in a software engineering setting, and in doing so it assesses how you handle people: resolving conflict, communicating, owning your part, and leading.

Solution

What interviewers evaluate

They look for signs of:

• Communicating straight and respectfully (without assigning blame or playing politics)
• The knack for calming a situation while keeping the team moving forward
• Solid judgment: knowing when to press a point and when to align and commit
• Decisions anchored in data (tests, metrics, prototypes)
• Ownership and a willingness to learn

A strong structure: STAR (+ "Principles")

Use STAR (Situation, Task, Action, Result) and fold principles into it:

• Start from the assumption that the other person means well
• Get goals and constraints clear up front
• Keep the people separate from the problem
• Lean on data and small experiments
• Write the decision down, align on it, and follow through

S — Situation (30–60 seconds)

Include:

• The team and project you were working in
• Pressure from the timeline
• Who disagreed, and why it mattered

Example framing:

• "We were in the middle of migrating X service; the latency budget sat at 150ms; oncall load was heavy; we had to pick between approach A and B."

T — Task (10–20 seconds)

State what you were responsible for:

• "I was responsible for service reliability and had to keep us within SLO while still shipping by date Y."

A — Actions (the core)

Aim for 3–6 concrete actions:

1. Clarify the disagreement
   • Put both viewpoints back into neutral words.
   • Determine whether the clash concerns goals, facts, constraints, or preferences.
2. Gather evidence / reduce ambiguity
   • Suggest a fast spike or prototype, a benchmark, or a review of incident data.
   • Agree on success metrics (p95 latency, error rate, development effort, for instance).
3. Collaborate on options
   • Lay out the tradeoffs: "Option A buys speed now but carries risk X; Option B takes a week but improves Y."
4. Align on decision process
   • If the call isn't yours: make a recommendation, let the owner decide, then commit.
   • If the call is yours: spell out your reasoning, invite objections once, then decide.
5. Communicate and document
   • Draft a brief decision note (one to two pages) covering the context, the options, and the reasoning.
   • Spell out the follow-up tasks.
6. Repair and maintain the relationship
   • Once the decision lands, have a one-on-one check-in if it seems needed.
   • Share the credit and keep the tone professional.

R — Results (be measurable)

Include:

• What actually happened (shipping outcome, movement in metrics)
• How the relationship or the team changed
• What you took away from it

Quantify if possible:

• "Brought p95 down from 240ms to 140ms"
• "Reduced incidents from 3 per week to 1 per month"

Handling common follow-ups

If you're not the decision-maker

• Show influence without authority:
  • Ask clarifying questions, put metrics on the table, run a small experiment, give a clear recommendation.
  • And then: "I disagreed, but once the decision was made I committed to it."

If you think the other person is wrong

• Steer clear of absolutes.
• Emphasize verification:
  • "Let's measure it," "Let's look at the incident data," "Let's run a design review."
• Only escalate when it's warranted:
  • Safety, compliance, serious reliability risk, or issues that keep going unresolved.

What you would do differently

Good answers show maturity:

• "I'd have brought stakeholders in sooner,"
• "I'd have written the one-pager earlier,"
• "I'd have pinned down who owned the decision and what the timeline was."

Pitfalls to avoid

• Pointing fingers at the other person or belittling them.
• Telling it as though you 'won' through politics instead of evidence.
• Nothing concrete in the actions — only feelings or vague statements.
• An outcome that isn't measurable or clear.

A concise template you can reuse

• "The disagreement came down to X versus Y given constraints C.
• We got aligned on the goal, I gathered data through tests/metrics, laid out options with their tradeoffs, and we settled on how the decision would be made.
• We went with Z, shipped it, and hit a measurable result.
• I came away with a lesson and changed a process as a result."