你如何决定不做什么？

考察要点

这道题旨在考察你的优先级判断能力、数据驱动决策能力和向上管理及横向影响的能力。它想了解你是否能从繁杂的需求中识别出真正对客户和业务有价值的事情，并有勇气和方法对低价值的工作说“不”。

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

1. Customer Obsession (客户至尚): 你拒绝做的事情，是不是因为有对客户更有价值的事情需要你去做？
2. Have Backbone; Disagree and Commit (敢于谏言，服从大局): 你是否有勇气基于数据和逻辑，向上级或同事提出不同意见？
3. Frugality (勤俭节约): 你的决策是否在为公司节约宝贵的资源（工程师的时间是最宝贵的资源之一）。

高分示范答案（STAR）

Situation（背景） 在 2022 年，我当时在一家头部电商公司担任推荐系统团队的资深软件工程师（Senior SDE）。我们团队大约有 8 名工程师，负责维护和迭代首页的“猜你喜欢”信息流。当时，业务侧的增长压力很大，产品经理（PM）提出了一个季度 OKR，要求我们上线一个“推荐商品社交裂变”的新功能，即用户可以一键将推荐的商品组合分享到社交媒体，期望通过社交渠道带来新流量。

Task（任务） PM 的需求文档已经写好，计划投入 3 位工程师开发 6 周。但我通过数据看板发现，我们推荐系统的核心指标——“推荐点击率到加购转化率”在过去两个月已经悄悄下滑了 5%。我认为在核心体验有损的情况下，投入巨大精力去做一个高不确定性的拉新功能，风险很高。我的任务是说服 PM 和总监，将优先级从“社交裂变”功能调整为“核心推荐质量优化”，先止住下滑趋势。

Action（行动） 为了让我的建议有说服力，我采取了以下几个步骤：

• 第一步，我深入挖掘数据，找到问题的根源。 我没有直接说“这个功能不好”，而是花了三天时间分析日志和监控数据。我发现，随着商品库（SKU）数量翻倍，我们的一个关键特征提取服务的 P99 延迟从 200ms 飙升到 600ms，导致部分用户请求超时，只能返回降级的、相关性差的默认推荐结果。这直接解释了为什么转化率在下滑。
• 第二步，我量化了两种选择的投入产出比（ROI）。 我为“社交裂变”功能做了一个粗略的技术评估，确认需要约 90 个人天的工作量。然后，我与 PM 合作，基于行业数据，给出了一个乐观的估计：该功能可能带来 10% 的分享率和 5% 的点击率，但对最终成交的转化率影响未知。对于优化推荐质量，我评估需要约 60 个人天来重构特征服务，但收益是明确的：恢复那 5% 的转化率损失，这直接对应着每天约 20 万人民币的 GMV。
• 第三步，我主动发起沟通，并提供了清晰的替代方案。 我写了一份 2 页的文档，清晰地对比了两个方案：A方案（社交裂变）是“高投入、高风险、收益不明确”，B方案（优化核心体验）是“中等投入、低风险、收益明确”。我没有直接否定 PM，而是在文档中强调“我们都希望提升业务，B 方案能更稳健地帮我们达成目标，并为未来的增长（包括社交裂变）打下坚实基础”。我主动预约了与我的经理、PM 和技术总监的会议。
• 第四步，我在会议上主导了讨论，并处理了阻力。 会上 PM 最初很坚持，因为这是他向上承诺过的功能。我首先肯定了他对业务增长的思考，然后将话题拉回到数据上，强调“我们正在流失现有用户，这是个更大的漏斗”。我向总监展示了 GMV 损失的估算，并承诺如果让我们先做优化，我们可以在一个半月内完成，并能量化地看到转化率回升。

Result（结果） 最终，总监和 PM 都被数据和清晰的逻辑说服了。我们团队的 OKR 被正式调整为优先解决核心推荐质量问题，“社交裂变”功能被推迟。在接下来的一个半月里，我主导了特征服务的重构，将其从单体应用拆分为三个独立的微服务，并将缓存策略从本地缓存升级为分布式 Redis 集群。项目上线后，特征服务的 P99 延迟从 600ms 降至 80ms，推荐系统的整体可用性从 99.8% 提升到 99.95%。更重要的是，“推荐点击率到加购转化率”在上线后一个月内回升了 4.8%，为平台挽回了巨大的潜在损失。这个决定让我赢得了团队和领导的信任。

低分陷阱（常见扣分点）

1. 只说“不”，不说“为什么”和“做什么”：反例：“当时 PM 提了个需求，我觉得不合理，就跟老板说我们人手不够，做不了。” —— 这只是拒绝，没有体现你的思考和担当。
2. 用“我们”模糊个人贡献：反例：“我们团队觉得应该先优化性能，所以我们就去做了。” —— 面试官想知道的是“你”在其中扮演了什么角色？是你发现的问题吗？是你做的分析吗？是你去沟通的吗？
3. 缺乏量化证据，只有主观判断：反例：“我觉得那个新功能没什么用，肯定不如优化老功能效果好。” —— 没有数据支撑的“我觉得”毫无说服力。你需要像范例中一样，量化投入、风险和预期收益。
4. 将“不做”的原因归结于技术难度：反例：“那个需求技术上实现太复杂了，要改很多底层代码，所以我们决定不做。” —— 这会让面试官觉得你是在逃避挑战，而不是从业务和客户价值出发做决策。
5. 选择的故事过于简单：反例：“我决定不做那个给按钮换颜色的小需求，因为我在忙一个更重要的 bugfix。” —— 这体现不了战略思考和影响力，只是日常工作的普通优先级排序。

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

1. 追问：你和那位 PM 的后续合作关系怎么样了？他有没有因为你“搅黄”了他的项目而对你有意见？

   • 要点 1 (建立同理心): 回答时要强调，我理解 PM 的处境和压力。我的目标不是为了证明他错了，而是为了帮助“我们”共同的业务目标取得成功。
   • 要点 2 (持续沟通与合作): 我在项目进行中，会定期（比如每周）同步给他优化的进展和一些正向的数据信号，让他也能感受到这个决策的正确性，并能向上汇报。
   • 要点 3 (赋能对方): 在核心问题解决后，我主动找到他，讨论现在是否是做“社交裂变”的好时机，并基于新的系统能力，提出更优的实现方案。这表明我不是反对他，只是反对在错误的时机做。

2. 追问：如果当时你的总监仍然坚持要先做“社交裂变”功能，你会怎么做？

   • 要点 1 (Disagree and Commit): 我会再次强调数据表明的风险，并以书面形式（邮件）记录我的担忧和潜在的负面影响，确保决策层清楚地了解可能的后果。这是“Disagree”的最后一步。
   • 要点 2 (全力执行): 一旦最终决定做出，我会立即停止争论，并全身心投入到“社交裂变”功能的开发中，尽我所能把它做到最好、最快。这是“Commit”的核心。
   • 要点 3 (持续监控): 在开发新功能的同时，我会持续监控核心转化率指标。如果它继续恶化，我会用新的数据再次提出问题，但这将是下一轮的讨论，而不是对当前已定决策的挑战。

3. 追问：你是如何估算优化核心体验能挽回 5% 的转化率的？这个估算准确吗？

   • 要点 1 (归因分析): 我会解释我的分析方法。我通过日志将请求分为“正常返回”和“降级返回”两组。我发现“正常返回”组的转化率一直稳定在 X%，而“降级返回”组的转化率只有 Y%（远低于 X%）。
   • 要点 2 (量化影响范围): 我统计了“降级返回”请求在总请求中的占比，发现这个占比（比如 10%）和整体转化率下滑的 5% 曲线高度相关。我的假设是，只要消灭了“降级返回”，这部分流量的转化率就能从 Y% 恢复到 X%，从而拉高整体转化率。
   • 要点 3 (承认不确定性并验证): 我会坦诚任何预估都有误差。我会说：“这当然是一个基于历史数据的推断，但我认为这是当时我们能做出的最合理的、数据驱动的预测。最终结果（恢复了 4.8%）也验证了我的模型基本准确。”

故事复用建议

这个故事非常扎实，除了回答“决定不做什么”，还可以根据提问的侧重点进行微调，用于回答以下问题：

• Ownership (主人翁精神): 你主动发现了一个未被分配的任务（转化率下降），并负责到底，最终解决了问题。
• Deliver Results (交付结果): 你顶住压力，专注于能带来最大业务价值的工作，并交付了可量化的、巨大的业务成果。
• Dive Deep (深入细节): 故事的核心在于你如何通过深入分析日志和数据，找到了问题的根本原因。
• Bias for Action (崇尚行动): 你没有停留在担忧和抱怨，而是迅速行动，收集数据，建立模型，推动决策。
• Influence without Authority (在没有直接汇报关系的情况下施加影响): 完美展示了你如何说服 PM 和总监，改变了团队的路线图。
• Tell me about a time you disagreed with your manager/PM. (与经理/PM 意见不合的例子): 这个故事本身就是这个问题的完美答案。