说说你曾与难相处队友合作的经历。

考察要点

这道题旨在考察你在面对专业冲突或协作障碍时，是否能保持专业、以目标为导向、并最终解决问题。对于 Amazon，它重点考察 Earn Trust (赢得信任)，同时也涉及 Have Backbone; Disagree and Commit (敢于谏言，服从大局) 和 Deliver Results (达成业绩)。

高分示范答案（STAR）

Situation（背景） 去年 Q3，我在我司（一家电商公司）的订单履约团队（约 8 名工程师）担任高级工程师。当时我们正在进行一个核心系统的重构项目，目标是拆分一个有 5 年历史的单体库存服务。团队里有一位资深工程师，我们叫他李工，他是这个老系统的主要作者和维护者，对系统的每个角落都了如指掌。

Task（任务） 我的任务是设计并主导新的库存预扣模块，我提议使用事件驱动架构（Event Sourcing）来替代原有的数据库事务模型，以提升系统的扩展性和性能。但李工坚决反对，他认为新技术引入风险太高，且现有模型虽然老旧但稳定可靠。我们的目标是将大促期间的库存计算延迟从峰值的 500ms 降低到 100ms 以内。

Action（行动） 面对僵局，我意识到强行推进是行不通的，必须先赢得他的信任。我采取了三个关键步骤：

1. 主动倾听，尊重专业： 我首先没有在团队会议上公开反驳他，而是在会后单独约他喝了杯咖啡。我先是承认并感谢他对现有系统稳定运行多年的贡献，并请教他当初设计时的一些考量和踩过的坑。这让他感受到他的经验是被尊重的，而不是被挑战的。
2. 数据说话，化解顾虑： 针对他“风险高”的顾虑，我没有空谈理论。我花了两天时间，基于我们生产环境的真实流量录制并回放，搭建了一个小型的 PoC (Proof of Concept)。我用压测数据向他展示：在模拟大促峰值流量下，新架构的 P99 延迟稳定在 80ms 左右，而老架构则飙升到 480ms，并且新架构在节点故障时能通过事件回放快速恢复，可靠性更高。
3. 化敌为友，共创方案： 在看到数据后，他的态度明显软化。我没有说“你看，我是对的”，而是邀请他成为新方案的“质量守护者”。我请他负责设计数据迁移和回滚预案，因为这方面他是绝对的权威。这样一来，他从一个反对者，变成了新方案成功的关键贡献者，我们共同完成了最终的技术设计文档。

Result（结果） 我们的联合方案获得了架构委员会的批准，项目顺利推进。

• 新系统上线后，在大促期间，库存预扣服务的 P99 延迟稳定在 85ms，成功支撑了 QPS 增长 200% 的业务压力。
• 由于架构清晰，新功能的迭代周期从平均 2 周缩短到了 3 天。
• 更重要的是，我和李工成了非常好的技术搭档，他后来还主动在新项目中推广事件驱动架构。我学到了，解决技术分歧最好的方法，往往不是技术本身，而是建立信任和共同目标。

低分陷阱（常见扣分点）

• 将同事描述成“坏人”或“蠢人”：“那个同事就是思想僵化，不愿意学习新技术，拖累了整个团队。” —— 这显得你非常不专业，缺乏同理心。
• 用“我们”模糊个人贡献：“我们一起讨论，然后我们做了一个 PoC，最后我们说服了他。” —— 面试官想知道的是“你”做了什么，而不是团队。
• 只有过程，没有结果：“我们最后达成了一致，项目也顺利完成了。” —— “顺利完成”是什么概念？延迟降低了多少？吞吐量提升了多少？没有量化就没有说服力。
• 求助上级太快：“我和他谈不拢，于是我就去找了我的经理来协调。” —— 这表明你缺乏独立解决问题的能力，倾向于上交矛盾。
• 故事过于简单：“我的同事代码风格不好，我让他改了。” —— 这不是一个有足够复杂度的“困难”，无法体现你的能力。

高概率追问（3 个 + 示范回答要点）

1. 追问：如果在你做了 PoC 之后，他依然固执己见，你会怎么办？

   • 要点 1 (坚持原则): 我会坚持“Disagree and Commit”的原则。如果数据和 PoC 依然无法说服他，我会申请一个更大范围的技术评审，比如邀请架构委员会或者其他组的资深专家来一起评估，让决策基于更广泛的共识。
   • 要点 2 (准备后备方案): 同时，我会准备一个 Plan B。如果最终决策是维持现状，我会服从决定，并尽我所能在他原有的方案上进行优化，比如增加更完善的监控和告警，以确保业务目标的达成。我的首要职责是 Deliver Results。
   • 要点 3 (记录与复盘): 我会把我的方案、数据和被否决的原因详细记录下来。这不仅是为未来的决策提供参考，也是一个复盘和学习的机会。

2. 追问：你是如何处理当时自己的负面情绪的？比如感到沮丧或不被理解。

   • 要点 1 (目标导向): 我会提醒自己，我们的目标是解决业务问题（降低延迟），而不是证明“谁对谁错”。把焦点从个人情绪转移到共同目标上，能帮助我保持冷静和专业。
   • 要点 2 (换位思考): 我会尝试理解他反对的深层原因。他不是在针对我，而是出于对系统稳定性的担忧，这是一种负责任的表现。理解了这一点，我的沮丧感就会大大降低，转而思考如何化解他的担忧。

3. 追问：你认为他“困难”的根本原因是什么？

   • 要点 1 (深入分析): 我认为根本原因不是技术上的保守，而是“所有权”和“安全感”的问题。那个系统是他多年心血的结晶，我的新方案对他来说意味着一种颠覆和他专业权威的削弱。
   • 要点 2 (解决方案关联): 正是洞察到这一点，我的行动（Action）才没有停留在技术辩论上。我通过尊重他的经验、邀请他共创方案，实际上是重新给了他一份新的“所有权”和在项目中的核心地位，从而化解了根本的阻力。

故事复用建议

这个故事非常扎实，除了应对“Difficult Teammate”问题，还可以稍作调整，用于回答以下问题：

• Influence without Authority (在没有职权的情况下施加影响): 核心就是你如何说服资深同事。
• Ownership (主人翁精神): 你主动发现问题，并承担起解决技术分歧和推动项目的责任。
• Deliver Results (达成业绩): 故事有非常清晰的量化业务成果。
• Bias for Action (崇尚行动): 你没有停留在无休止的争论中，而是通过快速构建 PoC 来打破僵局。
• Invent and Simplify (创新与简化): 你引入了新的架构来简化和优化现有系统。
• Have Backbone; Disagree and Commit (敢于谏言，服从大局): 你敢于对资深同事的方案提出异议，并用数据支撑。