描述一次你在代码评审中收到过极其严厉的批评意见。你当时是如何反应的？

考察要点

这道题主要考察候选人面对冲突和批评时的成熟度与专业性。在 Amazon，这直接对应 Earn Trust 和 Learn and Be Curious 两条领导力原则。你需要证明你能够虚心接受反馈，即使对方的表达方式不佳，并能从中学习，最终为了最好的结果而改进。

高分示范答案（STAR）

Situation（背景） 大约一年前，我在我之前任职的电商公司担任高级工程师，负责订单履约系统。当时我们的团队（5名后端工程师）正在重构一个有5年历史的“订单拆分”服务，这个服务逻辑复杂且是核心链路，性能问题一直很突出。

Task（任务） 我的任务是主导新方案的技术设计与核心代码实现，目标是将订单拆分的 P99 延迟从当时的 800ms 降低到 200ms 以内，并为未来两年的业务增长（预计 3 倍订单量）提供扩展性。

Action（行动） 我设计了一个基于领域事件的异步化方案，并提交了第一版的合并请求（Merge Request），包含了核心的领域模型和状态机逻辑。很快，我收到了一位公司 Principal Engineer（首席工程师）的 Code Review，他的评论非常直接甚至有些刺耳，原话是：“This is fundamentally broken. The state management is naive and will lead to race conditions under load. Did you even consider concurrent updates? This needs a full rewrite, not a patch.” （这个设计有根本性缺陷。状态管理太幼稚，在高负载下会引发竞态条件。你到底有没有考虑过并发更新？这需要完全重写，而不是修修补补。）

• 第一步：管理情绪，寻求澄清。 看到这样的评论，我的第一反应是既尴尬又有点恼火，因为我已经为这个设计熬了好几个晚上。但我强迫自己冷静下来，深呼吸后，我没有在评论区直接辩解。我回复道：“感谢你的深入审查。你提出的竞态条件问题非常关键。为了确保我完全理解你指出的风险点，我们能否快速同步 15 分钟？我想听听你建议的更稳妥的状态管理模式。” 我主动将对抗性的文字沟通转为合作性的语音沟通。

• 第二步：虚心请教，聚焦问题。 在会议中，我完全以请教的姿态开始，我说：“我想学习一下你提到的场景，比如在哪些并发操作下，我当前的状态机会出现数据不一致？” 他解释了在“用户取消”和“仓库缺货”两个事件并发到达时，我设计的基于数据库行锁的简单机制会失效。他建议我研究一下 "Optimistic Locking"（乐观锁）或者引入分布式锁。

• 第三步：研究并提出新方案。 会后，我花了一下午时间研究他提到的两种方案。我发现乐观锁（在数据表中增加 version 字段）非常适合我们的业务场景，因为它比分布式锁更轻量，性能损耗小。我快速编写了一个小型的 PoC（概念验证）来验证其可行性，并更新了我的技术设计文档，明确阐述了为什么选择乐观锁以及它如何解决之前的竞态条件问题。

• 第四步：重构并闭环。 我基于新方案重构了我的代码，并在新的 MR 中，特别感谢了那位首席工程师的指导。我写道：“根据上次的讨论，我采用了乐观锁机制来处理并发更新，并增加了相应的集成测试用例。@首席工程师，能否请你再帮忙看看这个方案是否解决了你之前提出的顾虑？” 这种做法既展示了我的改进，也表达了对他的尊重。

Result（结果） 新的设计最终顺利通过了审查并上线。

• 量化结果：上线后，订单拆分服务的 P99 延迟稳定在 150ms，低于 200ms 的目标。在后续的大促中，系统平稳支撑了 3.5 倍于日常的订单峰值，没有出现一例由竞态条件导致的数据不一致问题。
• 个人成长：这次经历让我深刻理解了在设计分布式系统时，永远要对并发问题保持敬畏。更重要的是，我学会了如何将尖锐的批评转化为成长的催化剂。那位首席工程师后来也成为了我非常敬佩的一位导师。

低分陷阱（常见扣分点）

1. 情绪化或指责对方：“那位同事沟通方式很有问题，非常不专业。” —— 面试官不关心对方怎么样，只关心你如何应对。
2. 用"我们"模糊个人贡献：“我们团队讨论了一下，觉得他说的有道理，于是我们修改了方案。” —— “我们”是谁？你在这个过程中扮演了什么角色？是领导者、跟从者还是旁观者？
3. 行动描述空洞：“我听取了他的意见，然后改进了代码。” —— 如何听取的？如何改进的？缺少具体的思考和决策过程。
4. 结果没有量化：“项目很成功，性能得到了提升。” —— “很成功”无法衡量。必须用数字说明，比如延迟降低了多少毫秒，支撑了多大的 QPS，节省了多少成本。
5. 故事过于简单：选择一个无关痛痒的反馈，比如“变量名需要修改一下”，这无法体现你在压力下的处理能力。故事的冲突性越强，越能展现你的能力。

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

1. 追问：如果在深入研究后，你发现他的反馈是错误的，你会怎么做？

   • 要点 1 (数据驱动)：我会用数据说话，而不是主观争辩。我会构建一个最小化的测试环境，模拟他担心的场景，用压测数据或日志来证明我的设计在特定条件下是安全或高效的。
   • 要点 2 (尊重与沟通)：我会整理好我的数据和结论，然后再次预约一个简短的会议。我会这样开场：“非常感谢你上次的提醒，它促使我做了更深入的验证。我根据你的建议做了一些测试，发现了一些有趣的现象，想和你分享一下我的发现，并听听你的看法。” 始终保持尊重和探讨的姿态。

2. 追问：这次经历之后，你和这位首席工程师的关系有什么变化？

   • 要点 1 (建立信任)：关系变得更好了。他看到了我不是一个固执、闻过则怒的人，而是一个能够接受批评并积极改进的工程师，从而对我建立了信任。
   • 要点 2 (主动求教)：在此之后，我把他看作一个宝贵的技术资源。在遇到一些复杂的架构问题时，我会主动在早期阶段就去征求他的意见，这让我们的合作更顺畅，也避免了后期的大规模返工。

3. 追问：你是如何在那一刻控制住自己的负面情绪的？有没有什么具体的方法？

   • 要点 1 (认知分离)：我会刻意将“人”和“事”分开。提醒自己，他的批评是针对“代码方案”，而不是针对我“个人”。他的目标和我的目标是一致的，都是为了做出更好的产品。
   • 要点 2 (延迟反应)：我有一个原则，从不立即回复尖锐的负面评论。我会先离开座位，去接杯水，或者散步五分钟。这个短暂的物理抽离能让我从第一时间的应激反应中冷静下来，用更理性的“系统2”去思考如何回复才是最专业的。

故事复用建议

这个故事非常扎实，除了 Earn Trust 和 Learn and Be Curious，还可以根据提问的侧重点进行微调，用于回答以下问题：

• Ownership: 你没有把皮球踢回去，而是主动承担了改进方案的全部责任。
• Disagree and Commit: 虽然没有明确的“Disagree”，但可以调整为“我最初有不同看法，但经过探讨和验证，我最终 commit 到了更好的方案上”。
• Tell me about a time you failed: 可以把最初的“幼稚”设计看作一次小型的技术失败，重点讲述你如何从失败中学习和恢复。
• How do you handle conflict with a coworker?: 这个故事是处理技术观点冲突的绝佳范例。