How do you handle conflict at work?

Describe a time you had a conflict with a teammate (e.g., disagreement on technical direction, priorities, code quality, or ownership).

Please cover:

• What was the context and what was at stake?
• What exactly was the disagreement?
• What actions did you take to resolve it?
• What was the outcome and what did you learn?

Follow-ups:

• How do you handle conflict when you’re not the decision-maker?
• How do you handle conflict when you believe the other person is objectively wrong?
• What would you do differently next time?

Solution

What interviewers evaluate

They’re looking for evidence of:

• Direct, respectful communication (no blame, no politics)
• Ability to de-escalate and keep the team moving
• Strong judgment: when to push vs. when to align and commit
• Data-driven decision making (tests, metrics, prototypes)
• Ownership and learning mindset

A strong structure: STAR (+ “Principles”)

Use STAR (Situation, Task, Action, Result) and weave in principles:

• Assume positive intent
• Clarify goals/constraints first
• Separate people from problem
• Use data and small experiments
• Document decision + align + follow through

S — Situation (30–60 seconds)

Include:

• Team/project context
• Timeline pressure
• Who disagreed and why it mattered

Example framing:

• “We were migrating X service; latency budget was 150ms; oncall load was high; we had to choose between approach A and B.”

T — Task (10–20 seconds)

State your responsibility:

• “I owned the service reliability and had to ensure we met SLO while shipping by date Y.”

A — Actions (the core)

Aim for 3–6 concrete actions:

1. Clarify the disagreement

   • Restate both viewpoints neutrally.
   • Identify whether the conflict is about goals, facts, constraints, or preferences.

2. Gather evidence / reduce ambiguity

   • Propose a quick spike/prototype, benchmark, or incident review.
   • Define success metrics (e.g., p95 latency, error rate, dev effort).

3. Collaborate on options

   • Offer tradeoffs: “Option A gets us speed now but risks X; Option B costs 1 week but improves Y.”

4. Align on decision process

   • If you’re not the decider: propose a recommendation, ask for the owner’s call, then commit.
   • If you are the decider: explain reasoning, invite dissent once, then decide.

5. Communicate and document

   • Write a short decision note (1–2 pages) summarizing context, options, and why.
   • Make follow-up tasks explicit.

6. Repair and maintain the relationship

   • After the decision, check in 1:1 if needed.
   • Give credit; keep tone professional.

R — Results (be measurable)

Include:

• What happened (ship outcome, metric movement)
• How the relationship/team changed
• What you learned

Quantify if possible:

• “Reduced p95 from 240ms to 140ms”
• “Cut incidents from 3/week to 1/month”

Handling common follow-ups

If you’re not the decision-maker

• Show influence without authority:
  • Ask clarifying questions, propose metrics, run a small experiment, provide a crisp recommendation.
  • Then: “I disagreed but committed once the decision was made.”

If you think the other person is wrong

• Avoid absolutism.
• Emphasize verification:
  • “Let’s test/measure,” “Let’s review incident data,” “Let’s do a design review.”
• Escalate only when necessary:
  • Safety, compliance, major reliability risk, or repeated unresolved issues.

What you would do differently

Good answers show maturity:

• “I would have involved stakeholders earlier,”
• “I would have written a one-pager sooner,”
• “I would have clarified the decision owner and timeline.”

Pitfalls to avoid

• Blaming or insulting the other person.
• Making it sound like you ‘won’ by politics rather than evidence.
• No concrete actions (only feelings or generic statements).
• No measurable or clear outcome.

A concise template you can reuse

• “The conflict was about X vs Y under constraints C.
• I aligned on the goal, gathered data via test/metrics, proposed options with tradeoffs, and agreed on a decision process.
• We decided Z, shipped, and achieved measurable result.
• I learned lesson and improved process going forward.”