## Question Tell me about a disagreement in code review. Explain the technical issue, the reviewer's concern, how you separated required correctness from preference, what evidence resolved the discussion, and how you preserved both code quality and the working relationship. ### Constraints & Assumptions - Use a substantive review, not a dispute over trivial formatting. - Do not merge around an unresolved correctness or security concern. - Respect repository ownership and escalation rules. - Explain the final code change, not only the conversation. ### Clarifying Questions to Ask - Would you prefer an example where my proposal changed or where the reviewer changed their view? - Should I focus on technical evidence or team process? ```hint Classify the comment Ask whether it identifies a contract violation, measurable risk, maintainability concern, or personal preference. Each category needs a different resolution. ``` ### What a Strong Answer Covers - Fair restatement of the review concern. - Direct discussion grounded in code, requirements, tests, or benchmarks. - Willingness to change the patch and explain trade-offs. - Appropriate use of a third decision owner when needed. - A later convention or test that reduces repeated debate. ### Follow-up Questions 1. What if the reviewer blocked the change without new evidence? 2. Did the discussion reveal a gap in the design document? 3. How do you handle “nit” comments under deadline? 4. What would you do differently now?