题目重点：Onsite 来源问 handle conflict、push back、给当前团队建议；本文把对齐目标、展示取舍、决策与复盘串成可验证行为案例。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 候选人选一个真实工作冲突，能明确说明自己的责任、另一方合理诉求和最终结果；不把正常技术分歧编成戏剧化人际故事。
- 所述数据、会议、决策记录和影响均须可追问；不得泄露前公司内部敏感资料。
解题路线
- 开场交代共同目标、各方不同约束和为什么必须决策，例如上线速度与可靠性冲突；先还原对方观点，避免稻草人。
- 说明自己如何获取证据：线上数据、实验、成本模型、客户反馈或风险清单；把不同方案放在相同评价指标下比较。
- 描述一次具体 pushback：说了什么、提出的替代方案和可接受条件，而不只是‘我坚持原则’。
- 交代决策机制与执行：谁有最终决定权，自己在决定后如何支持实施、设监控与回滚点。
- 结果除了指标，还要说合作关系与复盘；若方案失败，说明何时发现、承担哪部分责任和怎样修正。
- ‘给当前团队建议’可引用同一案例的系统性改进，但建议必须可执行、可测量且承认权衡。
手动走一遍
模板：‘我们要在 [真实期限] 上线，但 A 团队担心 [具体风险]，我主张 [方案]。我先复述他们的约束，再用 [真实数据] 比较两条路径，提议 [小范围验证/灰度]。最终决策是 [事实]，我负责 [执行]，监控 [指标]。结果 [真实结果]；若重来，我会更早让 [相关团队] 参与。’
规模与取舍
2 分钟故事可分 20 秒背景、40 秒分歧与证据、40 秒行动、20 秒结果；Staff 追问需准备跨团队决策文档、长期影响与未被采纳方案的代价。行为题无算法复杂度。
易错点与追问
容易失分的边界
- 把对方说成完全不懂技术，却没有说明其业务或风险约束。
- 只说最终赢了争论，不说共同目标与执行结果。
- 描述 pushback 却没有替代方案、证据或升级路径。
- 用不真实的量化结果包装普通会议。
- 给团队建议时只批评人，没有明确流程/技术改进和衡量指标。
继续深挖
- 如果决策者最终选了你反对的方案，你会怎样执行并控制风险？
- 你何时会升级冲突，何时先做小实验？
- 这次分歧中你的判断哪部分后来被证明不准确？
- 给团队的建议如何验证确实改善了交付？
