请讲讲你拒绝不符合标准工作的经历。

考察要点

这道题主要考察 Amazon 的两条领导力准则（Leadership Principles）：

1. Insist on the Highest Standards：你是否拥有并持续抬高标准？你是否能交付高质量的产品、服务和流程？你是否能确保缺陷不会传递给下游？
2. Have Backbone; Disagree and Commit：你是否敢于表达不同意见，即使这样做会让你感到不舒服或筋疲力尽？你是否会为了团队凝聚力而妥协，牺牲高质量决策？

高分示范答案（STAR）

Situation（背景） 我在上一家电商公司担任推荐系统团队的资深软件工程师（Senior SDE）。当时是 2021 年 Q3，我们团队（约 8 名工程师）正在为即将到来的“黑五”大促紧急开发一个全新的“实时个性化推荐”功能。这个功能是当年 CEO 亲自关注的重点项目。

Task（任务） 我的任务是为这个新功能设计并实现一个高性能的缓存层，用来存储用户的实时行为特征向量。硬性指标要求是，该缓存服务的 P99 延迟必须低于 50ms，并且能够支撑大促期间预估 10 万 QPS 的峰值流量。

Action（行动） 团队里一位非常有经验的同事（也是 Senior）负责了初版方案的设计和代码实现。但在 Code Review 环节，我发现了一个严重的问题，并决定必须驳回这次提交。

• 我首先识别了潜在的巨大风险：他为了快速上线，采用了一个非常简单的设计——在每个推荐服务实例的内存中（In-memory Cache）缓存数据。这个方案在单个实例上测试时延迟确实很低。但我立刻意识到，这存在两个致命缺陷：第一，数据一致性极差，不同实例间的用户特征无法同步；第二，服务一旦重启或扩容，缓存会全部丢失，导致“缓存雪崩”，瞬间压垮后端的数据库。这在大促期间是不可接受的。
• 我用数据和事实来支撑我的反对意见，而非主观判断：我没有直接在 CR 评论里说“你的设计不行”。而是花了一个下午，基于我们现有的流量模型，做了一个简单的压力模拟。我用数据证明，在扩容 50% 的情况下（大促期间的常规操作），他的方案会导致新节点产生超过 30% 的缓存穿透率，这股流量足以在 5 分钟内打垮我们的用户画像数据库。我把这个模拟结果和数据图表附在了我的 CR 评论中。
• 我主动提出了一个更高标准的替代方案并承担了额外工作：在指出问题的同时，我提出了一个更健壮的方案——引入一个分布式的 Redis 集群（Codis）。虽然这会增加约一周的开发和联调时间，但我强调这是保证大促稳定性的“保险”。为了打消项目经理对延期的顾虑，我主动请缨，承诺会利用周末时间完成新方案的核心代码，并制作一个详尽的迁移和回滚预案，确保项目整体风险可控。
• 我坚持原则，并推动团队达成共识：起初，那位同事和项目经理都因为上线压力而倾向于“先上线，后优化”。我在团队评审会上，再次展示了我的数据模拟，并引用了公司历史上两次因为类似缓存设计而导致的 P1 级故障。我强调：“我们不能为了节省一周的时间，去赌上整个黑五大促的稳定性。这不符合我们团队对工程质量的承诺。” 最终，我的坚持和详实的数据说服了团队，我们采纳了新方案。

Result（结果） 我们最终采用了 Redis 集群方案，虽然比原计划延迟了 4 天上线，但在“黑五”大促期间表现完美：

• 整个大促期间，缓存服务的 P99 延迟稳定在 28ms，远低于 50ms 的目标。
• 系统平稳支撑了 12 万 QPS 的历史峰值流量，没有发生任何一次降级或报警。
• 因为架构设计得当，这个缓存层在之后两年内支撑了业务 300% 的增长，无需重构。我因为这次表现，在季度的绩效评估中获得了“杰出贡献”的评价。

低分陷阱（常见扣分点）

1. 把“抬杠”当“有骨气”：仅仅说“我不同意”，但没有提供数据支撑或更好的替代方案。反例：“我觉得他的方案不好，太简单了，肯定会出问题，所以我让他重新做。”
2. 故事平淡，风险过低：选择一个无关紧要的例子，比如纠正一个文档的拼写错误，或者一个小的代码 bug。这无法体现你对“高标准”的坚持。反例：“我发现一个同事的代码没有写单元测试，我让他补上。”
3. 将功劳归于“我们”：在行动部分大量使用“我们”，让面试官无法判断你的个人贡献。反例：“我们觉得这个方案有风险，所以我们一起想了个新办法，最后我们成功了。”
4. 结果没有量化：只说“项目很成功”，没有具体数字。反例：“新方案上线后，系统稳定多了。”
5. 不敢承担责任：指出问题后，把解决问题的皮球踢给别人。反例：“我指出了他的设计缺陷，然后让 leader 去决定该怎么办。”

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

1. 追问：当你提出反对意见时，那位资深同事的反应是怎样的？你如何处理你们之间的关系？

   • 要点1（承认冲突）: 坦诚他一开始确实有抵触情绪，认为我的担忧是多余的，并且强调了项目的时间压力。
   • 要点2（对事不对人）: 强调我的沟通方式。我始终把焦点放在数据、风险和对业务的最终影响上，而不是批评他个人。我会说：“我非常理解你的方案在开发速度上的优势，但我们能否一起看看这个压力模型的数据，评估一下长期风险？”
   • 要点3（合作共赢）: 在新方案被采纳后，我主动邀请他一起参与设计和编码，并在项目成功后，在团队复盘和周报中公开感谢他对项目核心逻辑的贡献。这表明我的目标是项目成功，而不是证明“我对你错”。

2. 追问：如果你的经理当时为了赶进度，最终还是决定采用那个有风险的方案，你会怎么做？

   • 要点1（Disagree and Commit 的后半部分）: 首先，我会确保我的担忧和潜在风险已经被清晰地记录在案（比如通过邮件或文档），让决策者明确知道他们所承担的风险。这是我作为工程师的职责。
   • 要点2（全力执行并准备预案）: 一旦决策做出，我会立即停止争论，并 100% 投入去执行。同时，我会基于我预见的风险，主动去设计和准备应急预案。例如，为数据库增加更严格的限流、准备一键降级开关、和运维团队进行紧急扩容演练等。
   • 要点3（展现职业精神）: 这样做表明，我既有坚持原则的骨气，也有服从团队决策的职业素养和主人翁精神，会尽最大努力为最终结果负责。

3. 追问：你是如何快速做出那个压力模拟来证明你的观点的？

   • 要点1（体现技术深度和主动性）: 说明我没有使用什么复杂的工具，而是利用了现有的系统监控数据（比如过去一个月的平均 QPS 和峰值 QPS），结合一些开源的压测工具（如 k6, JMeter）编写了一个简单的脚本。
   • 要点2（简化问题，抓住核心）: 重点在于模拟“扩容导致缓存命中率下降”这一核心场景，而不是做一个全链路的完美压测。我会解释我如何设定变量（如实例数、请求分布），并快速得到能说明问题的趋势图。
   • 要点3（体现效率）: 强调整个过程只花了几小时，这体现了我的 Bias for Action（行动力），能快速动手验证自己的想法，而不是停留在口头争论。

故事复用建议

这个故事非常扎实，可以轻松改编用于回答以下问题：

• Ownership: 你主动承担了超出你本职的风险分析和方案设计工作。
• Deliver Results: 面对阻力，你依然交付了一个高质量、高可用的结果。
• Are Right, A Lot: 你基于经验和数据做出了正确的判断，避免了重大事故。
• Think Big: 你没有局限于眼前的开发任务，而是从系统长期健康和业务发展的角度思考问题。
• Tell me about a time you had a conflict with a coworker.
• Tell me about a time you took a risk. (风险在于挑战同事和可能导致项目延期)
• Describe a complex technical challenge you faced.