作为AI，我没有个人经历或同事，因此无法讲述向同事提供负面反馈的具体经历。但我可以分享关于如何提供建设性反馈的原则：应具体说明问题、关注行为而非个人、提供改进建议，并选择私下沟通以保持尊重。

考察要点

这道题考察的是候选人坦诚沟通和建立信任的能力。面试官想知道你是否敢于为了团队和产品的更高标准而进行艰难的对话，并且是以一种有建设性、尊重对方、最终能加强合作关系的方式进行。

对于 Amazon，这道题重点考察 Earn Trust 和 Insist on the Highest Standards 这两条 Leadership Principles。

高分示范答案（STAR）

Situation（背景） 去年我在一家电商公司担任支付结算团队的资深工程师（Senior SDE）。我们团队有 6 名工程师，正在开发一个战略级项目——“先享后付”功能，允许用户在收到货后再付款。这个项目技术复杂度高，且直接影响公司核心收入和坏账风险，稳定性要求极高。

Task（任务） 我负责 Code Review 团队一位新同事小张写的核心账单生成模块。我发现他的代码虽然能跑通主要流程，但在并发控制和数据库事务处理上存在严重的设计缺陷：他使用了简单的行锁，在高并发场景下会造成死锁，导致用户支付失败。我必须向他提出这个负面反馈，并让他重构这部分关键代码，同时要保证不打击他的积极性，也不能影响项目上线日期。

Action（行动） 整个过程我主要做了三件事：

1. 我先私下沟通，而非公开指责：我没有在 Code Review 工具里直接写下“设计有严重缺陷，请重写”这种生硬的评论。而是通过 Slack 私信小张：“嘿，你账单模块的代码我看了，主体逻辑很清晰！有几个关于并发的点我想和你当面聊一下，看看我的理解对不对，大概需要 15 分钟。” 我特意强调了“看看我的理解对不对”，把姿态放平，让他感觉这是一次技术探讨，而不是一次批判。

2. 我用数据和场景说话，而非主观臆断：在会议中，我首先肯定了他完成功能的效率。然后，我画了一张时序图，向他演示了在双十一大促峰值 QPS 达到 5000 的情况下，他当前的锁机制有 90% 以上的概率会触发数据库死锁。我接着展示了另一段我之前写的代码，用的是乐观锁+状态机模式，并解释了为什么这种模式能更好地处理高并发下的数据一致性。我把重点放在“如何让我们的系统扛住大促流量”这个共同目标上，而不是“你的代码不行”。

3. 我提供支持，并共同承担结果：指出问题后，我没有把烂摊子直接丢给他。我说：“这个改动可能需要两天时间，我知道项目排期很紧。如果你需要，今天下午我可以 block 出 2 个小时，我们一起做 Pair Programming 把核心的乐观锁部分先实现出来。我们一起对这个模块的稳定性负责。”

Result（结果） 小张欣然接受了我的建议，我们一起花了一个下午重构了核心代码。最终，这个模块不仅按时上线，而且在后续的双十一大促中，平稳支撑了峰值 5200 QPS 的支付请求，整个大促期间账单模块 0 故障，0 死锁，相比去年大促支付成功率提升了 0.5%。更重要的是，我和小张建立了非常好的信任关系，他后来在其他技术难题上也经常主动找我讨论。我学到了给予负面反馈的最好方式是：尊重、共情、并提供切实的帮助。

低分陷阱（常见扣分点）

• 用“我们”代替“我”：反例：“我们团队发现他的代码有问题，我们就让他改了。” 这完全没有体现你的个人作用。应该说：“我在 Code Review 中发现了... 我主动约他... 我向他解释了...”
• Result 缺乏量化：反例：“后来项目很成功，他的代码也没出问题。” 这太空洞了。必须量化：“支撑了峰值 5200 QPS，故障率为 0，支付成功率提升 0.5%。”
• Action 变成抱怨或指责：反例：“他那人就是不仔细，写的代码总是有问题，我不得不花时间给他擦屁股。” 这会让你显得像一个爱抱怨、无法与人合作的同事。
• 反馈过于软弱或问题太小：反例：“我提醒他代码注释格式不对。” 这种故事太琐碎，无法体现你在面对关键问题时的勇气和领导力。
• 只有问题没有解决方案：反例：“我告诉他代码有死锁风险，让他自己想办法。” 一个优秀的同事不仅会指出问题，更会提供支持和引导。

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

1. 追问：他在听到你的反馈时，第一反应是什么？他是如何被你最终说服的？

   • 要点 1 (观察与共情)：他一开始有些惊讶和沮丧，因为他认为功能已经完成了。我立刻表示理解：“我知道你为了按时交付花了很多心思，功能层面确实没问题，我们现在讨论的是如何让它在极端情况下也一样稳定。”
   • 要点 2 (聚焦事实与目标)：他被说服的关键在于我准备的“时序图”和“QPS 数据”。这让问题从一个主观的“好坏”评价，变成了一个客观的、必须解决的技术风险。当他看到数据和图示后，立刻就明白了问题的严重性。

2. 追问：如果当时他非常固执，坚持认为自己的方案没问题，你会怎么办？

   • 要点 1 (寻求第三方验证)：如果他依然不认可，我会建议：“没关系，技术方案有争议很正常。要不我们把架构师或者团队另一位资深同事也请过来，一起快速地 review 一下？我们的目标是选择对产品最稳妥的方案。” 这表明我不是为了证明“我对你错”，而是为了项目的最终成功。
   • 要点 2 (数据驱动决策)：我还会建议做一个小范围的压力测试。用压测数据来验证在高并发下哪种方案表现更好。让数据说话，是解决技术分歧最有效的方式。

3. 追问：这次沟通之后，你和这位同事的关系发生了什么变化？

   • 要点 1 (建立信任)：我们的关系变得更紧密了。因为他认识到我不是在找他麻烦，而是真心在帮助他成长，并且愿意投入我自己的时间来支持他。
   • 要点 2 (正向循环)：从那以后，他把我当成了一个可以信赖的 Mentor。在后续的项目中，他会更早地在设计阶段就来找我讨论方案，而不是等到代码都写完了才发现问题。这大大提升了我们整个团队的开发效率和代码质量。

故事复用建议

这个故事的核心是“通过有技巧的沟通来坚持高标准”，因此它可以灵活地应用在考察以下能力的问题中：

• Insist on the Highest Standards: 故事主线就是拒绝接受有缺陷的代码，坚持更高的质量标准。
• Earn Trust: 整个 Action 部分都在描述如何通过尊重、共情和支持来建立信任。
• Ownership: 你主动承担了保证整个功能模块质量的责任，而不只是你写的部分。
• Develop the Best / Mentorship: 你投入时间帮助同事成长，提升了他的技术能力。
• Are Right, A Lot: 体现了你准确的技术判断力和有效的人际沟通策略。