讲讲你项目中途计划不得不改变的经历。

考察要点

这道题考察候选人在复杂项目中应对突发变化时的适应性（Adaptability）、解决问题的能力（Problem Solving）以及影响力（Influence）。它想看你是否能在压力下保持冷静，做出数据驱动的决策，并说服团队和利益相关者接受新的方向。

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

高分示范答案（STAR）

Situation（背景） 去年，我在一家电商公司担任“促销引擎”团队的资深工程师（团队共 6 人）。我们的核心任务是为即将到来的“黑五”大促（3个月后）开发一个全新的“限时秒杀”功能。这是一个公司级的重点项目，因为管理层期望它能成为当天 GMV 的主要增长点。

Task（任务） 我的任务是负责后端架构设计和核心逻辑开发，确保系统能在大促洪峰期间稳定支撑至少 100,000 QPS 的商品库存查询，且 P99 延迟必须低于 150ms。我们最初的技术方案是基于公司现有的 MySQL 数据库集群，前面加一层 Redis 做常规缓存。

Action（行动） 项目进行到一半，大约在上线前 6 周，我遇到了一个致命问题：

• 我主动进行早期压测，发现根本性缺陷：在完成了核心功能约 70% 时，我没有等到 QA 介入，而是自己用 k6 搭建了高并发压测环境。结果发现，当并发请求超过 20,000 QPS 时，数据库的连接池就被打满，导致大量请求超时，P99 延迟飙升到 2000ms 以上。我意识到，依赖数据库的方案在秒杀场景下根本行不通，因为库存扣减会引发大量写操作和锁竞争，缓存穿透的风险极高。
• 我提出颠覆性替代方案并进行论证：我立刻叫停了基于该方案的后续开发。我花了一天时间研究并提出了一个全新的、完全基于内存的方案：将秒杀商品的库存完全预加载到 Redis 中，利用 Lua 脚本来执行“读取库存并扣减”的原子操作，从而完全绕开对后端数据库的实时写入压力。我写了一份简短的技术文档，用压测数据清晰地对比了新旧两种方案的优劣，并估算了改造所需的工作量。
• 我说服产品和管理层接受计划变更：最大的阻力来自产品经理，他担心推翻重做会影响“黑五”上线。在方案评审会上，我向他和总监展示了压测数据，强调“按原计划上线 = 100% 的线上故障”。同时，我给出了一个详细的、可并行执行的新排期，并主动承担了最核心的 Redis Lua 脚本开发。我还建议剥离一个次要的“实时购买动态”功能作为二期发布，以确保核心的秒杀交易流程能按时交付。最终，他们被我的数据和清晰的计划说服了。

Result（结果）

• 我们团队在剩余的 5 周内成功完成了新方案的开发和测试，并提前 3 天上线。
• 在“黑五”当天，秒杀系统峰值 QPS 达到了 135,000，P99 延迟稳定在 50ms，整个大促期间 0 故障。
• 该功能带来的直接销售额占当天总 GMV 的 20%，远超管理层预期。通过这次经历，我最大的收获是：对于核心系统，必须尽早进行极限压测来验证架构，而不是等到功能全部开发完。

低分陷阱（常见扣分点）

• 归咎于外因，缺乏主人翁精神："产品经理突然改了需求，导致我们不得不重做..."。这会让你听起来像一个被动的执行者，而不是一个主动解决问题的 Owner。
• 行动描述模糊，用"我们"代替"我"："我们发现了一个问题，然后我们决定换个方案，最后我们成功了。" 面试官无法判断你在这其中扮演了什么角色，是领导者、贡献者还是跟随者。
• 结果没有量化，空洞无力：反例：“项目最后很成功，新功能表现很好。” 这毫无说服力。你需要给出具体的业务或技术指标。
• 选择的故事过于简单：比如“我们遇到了一个 Bug，我花了两天时间修复了它”。这无法体现你在复杂情况下的决策和权衡能力。
• 没有体现权衡（Trade-off）：一个好的故事通常包含取舍。比如为了保住 deadline，你砍掉了哪个功能，或者增加了哪些技术债并有计划地偿还。说“我们加班加点，最后什么都没耽误”听起来不真实。

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

1. 追问：当你提出要推翻原有方案时，团队内部有不同意见吗？你是如何处理的？

   • 要点1（承认阻力）: 直接承认，比如“有的。我的技术组长就比较保守，他担心引入新的技术栈（Redis Lua）会带来未知风险，而且团队成员对 Lua 并不熟悉。”
   • 要点2（用数据说话）: 强调你如何用压测数据证明旧方案的不可行性，将讨论从“观点之争”转变为“事实之争”。
   • 要点3（提供解决方案）: 说明你如何降低新方案的风险，比如“我主动承担了 Lua 脚本的编写和测试，并组织了一个 1 小时的分享会，讲解其原理和使用方法，打消了团队的顾虑。”

2. 追问：你提到砍掉了一个“实时购买动态”功能，如果产品经理坚持要保留，你会怎么办？

   • 要点1（重申风险和目标）: 我会再次把讨论拉回到我们的首要目标上——确保核心交易链路在“黑五”的绝对稳定。我会重申，在当前时间线下，同时追求稳定性和完整功能集的风险极高。
   • 要点2（提供分阶段方案）: 我不会直接说“不行”，而是提供一个清晰的、分阶段的交付方案。例如：“我们可以先上核心交易功能，确保万无一失。然后，我们可以在大促后的第一周，通过一次小版本迭代，快速把这个动态功能补上来。这样既保证了大促的成功，也没有完全放弃功能。”
   • 要点3（寻求上级支持）: 如果产品经理依然坚持，我会建议将这个决策升级，让技术总监和产品总监一起来基于风险和收益做最终判断。

3. 追问：除了你提到的 Redis 方案，当时还考虑过其他备选方案吗？为什么最终选择了这个？

   • 要点1（展现技术广度）: 当然。我当时还快速评估了另外两个选项：一是使用像 TiDB 这样的分布式数据库，它能水平扩展；二是引入专门的消息队列（如 Kafka）来削峰填谷，异步处理库存扣减。
   • 要点2（深入分析权衡）: 解释你为什么没有选它们。例如：“TiDB 虽然能解决扩展问题，但引入成本太高，需要 DBA 深度介入，我们没有足够的时间。消息队列方案会增加系统复杂度和数据一致性的挑战，且用户需要等待更长时间才能知道秒杀结果，体验不佳。”
   • 要点3（突出当前方案的优势）: 最后强调 Redis + Lua 方案的优点：“它技术栈简单，团队上手快，能提供亚毫秒级的响应，完美契合秒杀场景对‘快’和‘准’的极致要求，是当前约束条件下性价比最高的选择。”

故事复用建议

这个故事非常扎实，除了回答“计划变更”，还可以稍作调整用于回答以下问题：

• Tell me about a time you took ownership. (你主动发现问题并力挽狂澜)
• Tell me about a time you used data to make a decision. (你用压测数据说服了所有人)
• Describe a time you had to influence others. (你说服了产品经理和团队接受新方案)
• Tell me about a time you faced a significant technical challenge. (你解决了一个高并发架构难题)
• Give an example of a time you had to make a trade-off. (你砍掉了次要功能以保证核心功能上线)
• Tell me about a time you disagreed with your manager or a stakeholder. (如果你和 TL/PM 的分歧是故事的重点)