How do you handle conflict at work?

## 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.”