请举一个你曾向同级同事提供负面绩效反馈的例子。

考察要点

这道题旨在考察候选人是否具备坦诚沟通、建立信任和驱动团队表现的能力。它要求候选人既要有发现问题的眼睛，也要有解决问题的勇气和方法，而不是回避冲突或将问题上报。

对于 Amazon，这道题重点考察以下 Leadership Principles (LP):

1. Earn Trust: 你能否以尊重、直接且有同理心的方式给出负面反馈？
2. Have Backbone; Disagree and Commit: 你是否有勇气指出同行的问题，即使这会引起不适？
3. Deliver Results: 你给出反馈的最终目的是否为了帮助团队达成更好的结果？

高分示范答案（STAR）

Situation（背景） 去年 Q3，我在电商推荐团队担任资深工程师（SDE II）。我们团队共 5 名工程师，正在负责一个核心项目：构建新一代的实时用户画像系统。这个项目对公司提升广告精准投放转化率至关重要，是 CEO 关注的重点。

Task（任务） 我注意到团队一位新同事，小王，虽然技术能力很强，但他提交的代码评审（Code Review）质量不高，经常缺少单元测试，导致他负责的模块在集成测试环境中频繁出现 bug。这直接影响了我们整个团队的迭代速度，我们的目标是在季度末将系统稳定性提升至 99.95%，但当时因为这些问题，我们连 99.9% 都难以保证。

Action（行动） 我决定必须直接和他沟通来解决这个问题。我的行动分为三步：

1. 我首先没有直接下结论，而是花了两天时间收集客观数据。 我整理了过去一个月内所有线上事故单（tickets）和测试环境中的严重 bug，发现有近 40% 都和小王提交的代码模块相关。我还具体分析了 5 个他的代码合并请求（Merge Requests），发现普遍存在测试覆盖率不足 50% 的问题，而我们团队的标准是 80%。
2. 我主动邀请小王进行一次 1-on-1 沟通，并提前告知他我想聊聊关于项目协作和代码质量的话题，让他有心理准备。 在沟通中，我先肯定了他快速学习和解决复杂问题的能力，然后展示了我整理的数据，客观地指出了代码测试覆盖率不足和引发 bug 之间的关联。我强调说：“这不是针对你个人，这个问题影响了我们整个团队的发布节奏，我希望我们能一起找到方法来解决它，确保项目成功。”
3. 我没有止步于指出问题，而是提出了具体的帮助计划。 我建议我们每周花一个小时进行结对编程（Pair Programming），特别是在他写核心模块的单元测试时。我还分享了我们团队沉淀的最佳实践文档，并把我之前写的一个高测试覆盖率的模块（测试覆盖率 92%）作为范例发给了他，让他有具象的参考。

Result（结果） 这个方法非常有效。在接下来的一个月里，小王提交的代码测试覆盖率平均达到了 85% 以上。由他代码引起的严重 bug 数量从每月 4-5 个下降为 0。我们团队的迭代速度也恢复了正常，最终在季度末成功实现了系统稳定性 99.97% 的目标，超越了预期。小王也在季度的绩效评估中获得了积极的评价，我们成了很好的合作伙伴。我学到了，基于数据的坦诚沟通是建立信任和解决团队问题的最有效方式。

低分陷阱（常见扣分点）

• 将问题上报给经理（甩锅）："我发现小王有问题，于是我向我的经理报告了，经理找他谈了话。" —— 这完全没有体现你的 Ownership 和沟通能力。
• 反馈过于主观和情绪化："我感觉他的代码质量很差，拖累了我们团队，我就直接跟他说你这样不行。" —— 缺乏数据支撑，容易引发冲突而非解决问题。
• 只提问题不给方案："我告诉他，他的代码 bug 太多了，让他自己注意点。" —— 这是批评，不是建设性反馈。资深员工应该帮助同事成长。
• 结果含糊不清："后来情况就好转了，项目也成功了。" —— "好转"是多好？没有量化结果，说服力大打折扣。
• 故事过于简单："我同事开会老迟到，我提醒了他一下。" —— 这种故事无法体现你在复杂工作场景下的职业素养和影响力。

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

1. 追问：如果当时小王对你的反馈反应很激烈，甚至是否认，你会怎么办？

   • 要点 1 (保持冷静和同理心)：我会先暂停对话，让他表达自己的情绪和观点，并认真倾听。我会说：“我理解这个话题可能让你感到不舒服，我愿意先听听你的想法。”
   • 要点 2 (重申数据和共同目标)：在他表达完后，我会再次将讨论拉回到客观数据上，强调我的目的不是指责他个人，而是为了我们共同的项目目标。我会问：“对于这些 bug 数据和测试覆盖率，你是否有不同的看法？”
   • 要点 3 (寻求第三方介入)：如果他依然完全否认，我会建议：“也许我的沟通方式有问题，不如我们邀请 Tech Lead 或者经理一起参与讨论，从一个更中立的视角来看看如何解决这个问题？” 这表明我不是在搞针对，而是真心想解决问题。

2. 追问：你为什么选择自己去沟通，而不是直接告诉你们的经理？

   • 要点 1 (效率和团队信任)：我认为同事之间直接、坦诚的沟通是最高效的解决方式。这能快速解决问题，并且在团队内部建立起互相负责、彼此信任的文化。
   • 要点 2 (Ownership 和职责)：作为一名资深工程师，我的职责不仅仅是写好自己的代码，也包括维护整个团队的工程质量和项目进度。发现问题并帮助同事改进，是 Ownership 的体现。
   • 要点 3 (判断问题的性质)：这件事属于协作和技术执行层面的问题，是可以通过 peer feedback 解决的。如果涉及到职业道德或屡教不改等更严重的情况，我才会第一时间上报给经理。

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

   • 要点 1 (初期阶段)：坦白说，在沟通后的几天里，气氛确实有一点点尴尬。这是人之常情。
   • 要点 2 (关系重建)：但我严格遵守了我的承诺，主动发起结对编程，耐心分享经验。当他看到我的确是在真心帮助他，并且他的工作成果确实得到改善后，这种尴尬很快就消失了。
   • 要点 3 (长期结果)：最终，我们的工作关系变得比以前更牢固。他把我当成一个可以信赖的导师和伙伴，之后遇到技术难题也愿意主动找我讨论。这次经历证明了建设性的负面反馈是建立深度信任的催化剂。

故事复用建议

这个故事非常扎实，可以灵活调整重点，用于回答以下问题：

• Ownership (主人翁精神)：强调你主动发现问题，并将其视为自己的责任去解决，而不是等待别人处理。
• Deliver Results (达成业绩)：强调你的行动如何移除了团队的障碍，最终确保了关键业务目标的达成。
• Develop the Best (培养他人)：强调你如何通过辅导和分享，帮助同事提升了技能，使整个团队变得更强。
• Tell me about a time you had a conflict with a colleague. (描述一次和同事的冲突)：可以将故事的重点放在如何通过数据和沟通来化解潜在的冲突。
• How do you influence others without authority? (你如何影响没有汇报关系的人？)：这个故事完美展示了通过专业能力、数据和沟通技巧来影响同级同事。