万事紧急时，如何确定优先级？

考察要点

这道题考察的是你在高压和信息不明确的情况下，如何做出理性决策并推动执行的能力。它评估你是否具备清晰的判断框架、数据驱动的思维方式以及与团队沟通对齐的能力。

• Amazon Leadership Principles: Deliver Results, Bias for Action, Ownership
• Meta Core Values: Move Fast, Be Bold
• 字节范: 务实敢为 / Always Day 1

高分示范答案（STAR）

Situation（背景） 我在上一家公司（某电商平台）担任支付结算团队的资深工程师。2022 年第三季度，我们团队（约 8 人）正在全力冲刺一个 CEO 级别的重点项目——“先买后付”（BNPL）功能，计划在“双十一”大促前上线。就在我们进入功能冻结、准备全链路压测的前一周，监控系统突然告警，线上核心支付网关的 P99 延迟飙升，并伴有少量支付失败。

Task（任务） 当时我面临两个同样紧急的任务：1) 保证“先买后付”项目按时、高质量上线，这是公司级的战略目标；2) 立即解决线上支付网关的性能问题，因为它正直接影响用户体验和公司收入。我需要快速判断优先级，并制定一个能让所有干系人（产品、老板、团队）都接受的行动计划。

Action（行动） 当时的情况非常混乱，产品经理催促我们不要分心，继续保障 BNPL 项目；而运维团队则不断发来告警，要求我们立刻处理线上问题。我的行动分为三步：

1. 第一步，我先用 15 分钟快速量化问题，而不是凭感觉决策。 我没有立即投入到代码中，而是先去分析监控数据。我通过公司的日志系统（Splunk）和监控平台（Grafana）发现，延迟问题主要集中在某个特定的支付渠道，影响了大约 5% 的交易，错误率约为 0.5%。我根据当时的平均客单价和交易量，快速估算出每小时的潜在损失约为 5 万元人民币。这个数据让我有了决策的基础。

2. 第二步，我建立了一个简单的决策框架并提出方案。 我画了一个简单的“影响-成本”四象限图。BNPL 项目是“高影响、高成本（剩余工作量）”，而修复线上问题是“高影响（立即止损）、中等成本”。基于此，我向我的技术经理和产品经理提出一个具体方案：由我个人牵头，再带一名熟悉该模块的初级工程师，组成一个两人“救火小队”，承诺在 4 小时内定位问题并给出解决方案；团队主力则继续进行 BNPL 项目的压测准备，不受影响。 我强调，如果不立即处理，损失会持续扩大，而且不稳定的核心服务也会让 BNPL 的上线风险倍增。

3. 第三步，我主动承担并推动执行。 在获得经理同意后，我立即创建了一个专门的沟通群组，拉入相关人员，实时同步我们的进展。通过二分法回滚最近的几次变更，我迅速定位到问题是由一个新上的风控规则导致的。我没有直接回滚，而是与风控团队沟通，拿到了一个紧急降级方案，在不完全牺牲风控效果的前提下，通过修改配置解决了性能瓶颈。

Result（结果） 我们“救火小队”在 3 小时内 就将降级方案部署上线，支付网关的 P99 延迟从峰值的 1200ms 降回了 150ms，支付成功率恢复到 99.99%，有效阻止了每小时约 5 万元的潜在损失。由于我的介入和清晰分工，主体团队的 BNPL 项目进度几乎未受影响，最终该功能 仅比原计划延迟了半天 就进入压测，并成功在“双十一”前上线，为大促贡献了约 8% 的交易额。我学到了，面对混乱，第一要务是量化，第二是清晰地沟通你的计划。

低分陷阱（常见扣分点）

• 没有决策框架，凭感觉排序：反例：“我觉得线上问题更紧急，用户体验最重要，所以我就先去修 bug 了。” —— 这显得非常不专业，没有体现出资深工程师的结构化思维。
• Action 变成“我们”的流水账：反例：“我们团队开会讨论了一下，然后我们分工，一部分人修 bug，一部分人继续做项目。” —— 面试官想知道“你”在其中扮演了什么角色？是你提出的方案吗？还是你只是个执行者？
• Result 只有定性描述，没有量化：反例：“问题很快解决了，项目也成功上线了，大家都很满意。” —— 多快？成功到什么程度？“满意”无法衡量。
• 将问题简化为二选一：反例：“我和老板说，我们只能二选一，要么做项目，要么修 bug。” —— 资深候选人应该展现出寻找双赢或多赢方案的能力，而不是简单地把压力抛给上级。
• 故事过于平淡，没有冲突：反例：“我手头有两个任务，我问了下老板先做哪个，然后就去做了。” —— 这无法体现你的判断力和 Ownership。

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

1. 追问：如果你的经理或产品经理当时坚持让你专注于新功能，你会怎么做？（考察你的影响力、向上管理和坚持原则的能力）

   • 要点 1 (重申数据)：我会再次强调我估算出的量化损失（每小时 5 万元），并指出核心服务不稳定的风险会直接危及到新功能的上线稳定性。这不是一个观点问题，而是一个数据问题。
   • 要点 2 (提供选项和权衡)：我会提供几个清晰的选项，比如“我单人花 2 小时快速排查，如果搞不定再重新评估”、“我们能否向兄弟团队借调一人来处理？”。清晰地摆出每个选项的利弊（trade-off），让决策者做选择题而不是问答题。
   • 要点 3 (Disagree and Commit)：如果经过充分沟通，上级仍然基于更高维度的信息（比如投资人压力、市场竞争）要求我暂停，我会明确记录下风险，然后坚决执行决定，这体现了 Amazon 的“Disagree and Commit”原则。

2. 追问：你是如何能在 15 分钟内估算出损失的？这个估算的准确性有多大？（考察你的业务敏感度和技术洞察力）

   • 要点 1 (说明数据源)：我会解释公司有成熟的数据看板，我可以快速查询到关键指标，如 GPM（每分钟总交易额）、核心支付渠道的流量占比、当时的平均客单价等。
   • 要点 2 (说明估算逻辑)：我的计算公式是：GPM * 支付渠道流量占比 * 受影响交易比例 * 支付失败率 * 平均客单价。我会强调这是一个“费米估算”，目的不是 100% 精确，而是快速判断问题的数量级，为决策提供依据。精确到万位级就足够了。

3. 追问：你提到成立了一个“救火小队”，但如果另一个初级工程师不愿意放下手里的工作来帮你怎么办？（考察你的领导力和团队协作能力）

   • 要点 1 (寻求共同目标)：我会向他解释当前情况的严重性，并强调线上服务的稳定性是我们整个团队的共同责任，也是新功能成功上线的基石。让他明白这不是“帮我”，而是“帮我们团队”。
   • 要点 2 (明确分工和收益)：我会告诉他，我会负责主导排查和沟通，他只需要配合我对特定模块进行分析，这对他来说也是一次宝贵的线上问题处理经验。我会帮他向经理说明情况，确保他的本职工作不会因此受到负面评价。
   • 要点 3 (快速升级)：如果他仍然有顾虑，我会立即将情况同步给技术经理，由经理来进行协调。在紧急情况下，不能在内耗上浪费时间。

故事复用建议

这个故事非常经典，可以根据面试官的提问侧重点进行微调，复用于以下问题的回答：

• Ownership: "Tell me about a time you took ownership of a problem outside your defined responsibilities." (你主动承担了非计划内的线上问题)
• Deliver Results: "Describe a time you had to make a decision to deliver results on time." (你在资源冲突下，确保了两个关键任务都成功交付)
• Bias for Action: "Tell me about a time you faced a difficult situation that required you to act quickly." (你没有等待，而是主动分析、决策、行动)
• Earn Trust: "How do you earn trust from your colleagues/manager?" (你通过数据、清晰的计划和可靠的执行赢得了信任)
• Tell me about a time you dealt with a crisis. (整个故事就是一个标准的危机处理案例)
• Tell me about a time you used data to make a decision. (你用数据量化问题，并以此为基础制定策略)