Resolve conflicts during code reviews

The interviewer is assessing your **collaboration style**, ability to handle disagreement, and focus on **team outcomes over ego**. ### Principles for resolving review conflicts 1. **Assume good intent** - Start from the belief that everyone wants good code and a stable system. - Avoid taking comments personally or making it personal. 2. **Clarify the goal and constraints** - What are we optimizing for? Readability, performance, security, deadlines, compatibility? - Sometimes conflict comes from different assumptions; make them explicit. 3. **Use data and standards, not opinions alone** - Refer to: - Team style guides and architecture documents. - Existing patterns in the codebase. - Benchmarks, logs, or production metrics when performance is at issue. 4. **Communicate respectfully and specifically** - Ask clarifying questions: *"Can you help me understand why you prefer this approach?"* - Explain your reasoning: *"I’m concerned this might make future changes harder because…"*. - Offer alternatives, not just criticism. 5. **Pick the right medium** - If a thread is getting long or tense, propose a quick call or pairing session. - Synchronous discussion often resolves misunderstandings faster. 6. **Be willing to compromise** - Recognize when the difference is minor (style, micro-optimizations) vs. major (correctness, security, architecture). - For minor issues, be flexible and follow team conventions. - For major issues, escalate constructively if needed (e.g., involve tech lead) while staying objective. 7. **Focus on long-term team health** - Avoid "winning" the argument at the cost of relationships. - Propose documenting the decision for future reference (ADR, design doc, wiki note). ### Example answer outline > "When I encounter disagreements in code reviews, I first try to understand the other person’s perspective by asking clarifying questions. I focus the discussion on the underlying goals—are we optimizing for readability, performance, or consistency with existing patterns? I reference our style guides or architecture docs where possible, and if it’s a performance question I prefer to use measurements rather than speculation. > > If the discussion gets long, I suggest a short call or pairing session, which usually resolves things quickly. I’m happy to compromise on subjective style issues to keep the team consistent, and I push harder only when I believe there’s a significant impact on correctness, security, or maintainability. In rare cases where we still disagree, I involve a tech lead to help make a decision and make sure we document the outcome so we don’t revisit the same debate repeatedly."