Prompt and context
The interviewer wants to know how you handle technical disagreement, not whether you can say “I enforce my standards.” Consider a pull request where you believe new concurrency complexity, a privacy risk, or a missing test will reduce code health; the author calls it minor and asks to merge first. Explain the facts, discussion, decision, and result.
Google Engineering Practices recommends checking whether the author has better context, then explaining the concern in terms of code health. If complexity will remain in the codebase, it is generally better to address it in the current change; emergencies are an exception. A strong answer grounds the principle in one verifiable collaboration event instead of labeling the author difficult.
What the interviewer evaluates
- You re-check your own judgment and can acknowledge context held by the author.
- You explain the concern with risk, user impact, tests, and maintenance cost rather than status or personal style.
- You separate a correctness, security, privacy, or regression blocker from a follow-up task and a preference.
- You propose the smallest viable change, invite the right reviewer, and define a decision or escalation path.
- You quantify the outcome: avoided defects, fewer rollbacks, review time, team trust, and process improvement.
Questions to clarify first
- Is the disagreement about correctness, security, privacy, performance, maintainability, or a coding preference?
- Which layer does the comment concern: implementation, tests, interface contract, release risk, or team policy?
- Did the author provide new evidence, historical constraints, or a deadline? Who owns the final technical decision?
- Is the change urgent, and can a gray release, rollback, or feature flag reduce risk?
- How will you protect the author’s privacy and keep a public discussion from becoming a personal judgment?
A 30-second answer
“I first reproduce or verify the facts and check whether the author has context I missed. If the issue affects correctness, privacy, or clearly lowers code health, I use the code path, test result, and user risk to explain why it belongs in this change, then propose the smallest fix. If it is preference, I make it non-blocking. If we still disagree, I invite a domain reviewer or technical lead and record the decision and follow-up. I finish by reviewing delivery, quality, and relationship outcomes.”
Step-by-step solution
Step 1: Turn a personal judgment into a testable claim
Replace “this code is dangerous” with “two concurrent updates can overwrite the newer value because there is no version check.” Provide a reproduction, log, test, or benchmark. Keep the comment about code and risk, never the author’s ability. Without evidence, ask a question before blocking.
Step 2: Check your missing context
Ask about the interface contract, compatibility, release window, dependent teams, and rollback. Google’s guidance notes that the author may be closer to the implementation and have better information. If new evidence disproves your suggestion, acknowledge and withdraw it instead of treating persistence as quality.
Step 3: Classify comments and propose the minimum change
Classify feedback as a blocker, non-blocking suggestion, or positive reinforcement. A blocker maps to reproducible correctness, security, privacy, or high-probability regression risk; a style preference can be a Nit or a documented convention. Offer a small patch, test, or feature flag instead of unrelated refactoring in the same pull request.
Step 4: Explain the why through code health
Connect the fix to future maintenance cost, incident prevention, or user experience. Do not paste a rule link without applying it to this change’s path, impact, and acceptance criteria. If the author asks to “clean it up later,” assess whether the complexity will be forgotten or make future reviews harder.
Step 5: Establish a decision and escalation path
Summarize agreement and open questions in the review. If needed, schedule a short discussion or invite a reviewer with domain authority. A technical lead should decide from evidence, code health, and delivery constraints, not rank. Track an unresolved non-blocker with an owner and due date.
Step 6: Verify outcomes and improve the process
Before merge, verify tests, static checks, rollout metrics, and rollback. After merge, observe defects, rollbacks, review rounds, and delivery time. If the same pushback repeats, improve design review, the pull-request template, or documentation instead of relying on persuasion each time. Narrow review for an emergency but record risk and remediation.
A strong sample answer
“During a concurrent cache migration, I commented that writes lacked a version check. The author considered it theoretical and asked to merge. I reproduced an old value overwriting a new value with two concurrent updates and confirmed the endpoint changed order state, so it was a correctness blocker for this change. I acknowledged that the author knew the legacy compatibility fields better, kept those fields, added conditional versioned writes, and added conflict tests and metrics.”
“We asked the order-storage reviewer to verify the design and agreed to watch conflict rate and rollback during a gray release. The author accepted the small patch, and the rollout had no further overwrite. I explained the evidence in the review and tracked the broader cache refactor separately. In retrospect, the team added concurrent-write tests to the pull-request template, reducing similar disputes.”
Common mistakes
- Use seniority or “the standard says so” → the author cannot see the risk → show the code path, evidence, and acceptance test.
- Make every comment blocking → delivery and trust suffer → separate risk, suggestion, and preference.
- Assume the author is wrong → implementation context is missed → re-check and withdraw when evidence changes.
- Treat “clean it up later” as default → complexity tends to remain → fix now or assign an owner and deadline.
- Judge a person in a public review → disagreement becomes conflict → discuss code, impact, and next steps.
- Skip outcome metrics → effectiveness cannot be shown → record tests, rollout, defects, review time, and process changes.
Follow-up questions and answers
What do you do when you discover you were wrong?
State the missing fact, withdraw the blocker, and explain the new evidence publicly. Thank the author for the context and stop defending authority; add a short record if it prevents a repeat mistake.
What if the author says the deadline requires an immediate merge?
Assess whether the risk affects correctness, security, or compliance. Keep a high-risk blocker and propose a smaller scope, feature flag, gray release, and explicit rollback. A low-risk suggestion can be non-blocking with an owned, dated follow-up.
What if neither side reaches agreement?
Write the claim, evidence, acceptable risk, and alternatives. Invite a domain reviewer or technical lead to decide, then record the reasoning in the pull request so future readers do not reopen the same argument.
How do you keep review from becoming a bottleneck?
Discuss design early, split small pull requests, and automate tests and style checks. Review high-risk design first, then local suggestions. For emergencies, keep a minimal review and a remediation record.