请举一个例子，说明你何时不得不在一个冲刺周期（sprint）进行到一半时，因为业务目标发生变化而调整你的技术方案。

考察要点

这道题考察的是你的适应性、技术判断力和客户导向。在快速变化的业务环境中，工程师不能只埋头于既定计划，而要能理解业务目标，并迅速做出最务实的技术决策。

对于 Amazon，这道题重点考察 Bias for Action (崇尚行动), Customer Obsession (客户至上), 和 Are Right, A Lot (决策正确)。

高分示范答案（STAR）

Situation（背景） 去年 Q3，我在一家电商公司担任高级后端工程师。我们团队（5名工程师）正在为一个新的“个性化推荐”信息流开发后端服务。当时 Sprint 已经进行到一半，我们正在按计划用 Python 构建一个基于用户协同过滤的复杂推荐模型。

Task（任务） 原任务是在 Sprint 结束前，完成推荐模型的核心算法，并能根据用户历史行为生成初步的推荐列表。但突然，业务侧决定在两周后上线一个大型的“夏季清仓”促销活动，要求我们的推荐系统必须优先、高比例地展示高利润的清仓商品，而不是纯粹的个性化商品。这意味着原有的技术方案无法直接满足这个有时效性的、强业务导向的新需求。

Action（行动） 时间紧迫，我知道从头训练一个包含业务规则的新模型是不可能的。我的行动分为四步：

1. 我立即叫停了正在进行的模型开发工作，并主动拉上产品经理和数据分析师开了一个 30 分钟的紧急会议。我需要快速澄清“优先”、“高比例”这些模糊的业务词汇，并将其翻译成明确的、可执行的工程规则。我们最终确定：在活动期间，推荐流中至少 60% 的商品必须是清仓商品，且按利润率倒序排列。

2. 我分析了现有系统并提出了一个轻量级应急方案。我发现，虽然我们的推荐模型还在开发，但商品服务（Product Service）的数据库里已经有了 is_on_sale 和 profit_margin 字段。我提出，与其修改复杂的模型，不如在推荐服务的下游增加一个“规则引擎”作为中间件。这个引擎会先从协同过滤模型获取一个较长的候选列表（比如 200 个商品），然后用我新写的逻辑进行强制重排和注入：先用清仓商品填满 60% 的位置，再用原有的个性化推荐结果填充剩余位置。

3. 我主导了技术方案的快速实现和风险控制。为了说服团队，我用一个下午构建了一个最小可行原型（MVP），证明这个方案可以在两天内完成开发。我亲自编写了核心的重排（re-ranking）逻辑，并将配置接口（用于调整清仓商品比例）的开发任务交给了团队里的一位初级工程师，并为他提供了清晰的接口文档。最关键的是，我引入了功能开关（Feature Flag），让我们可以随时一键切换回纯个性化推荐，将线上风险降到最低。

4. 我主动与下游团队沟通，确保端到端交付。我提前通知了前端和客户端团队，我们的推荐接口返回结果的业务逻辑会有变化，并提供了一个临时的 Mock API 供他们提前适配 UI 展示，确保了在联调时没有阻塞。

Result（结果） 最终，这个新的推荐逻辑比原计划提前 2 天上线，完美支持了夏季清仓活动。活动为期一周，数据显示：

• 由新规则推荐的清仓商品，其点击转化率比站内其他入口高出 30%。
• 整个活动的商品交易总额（GMV）超出了预期目标的 15%，约合 500 万人民币。
• 活动结束后，我们通过功能开关无缝切换回了原有的个性化推荐逻辑。这次经历让我深刻体会到，技术方案的优雅固然重要，但能快速响应业务变化、创造商业价值的架构更具生命力。

低分陷阱（常见扣分点）

• 抱怨业务方：“产品经理又乱改需求，我们没办法只能加班做。” —— 这体现了被动和缺乏主人翁精神。应该展现你主动理解和解决问题的态度。
• 技术方案模糊：“我们调整了一下架构，很快就做完了。” —— 面试官想听的是你具体怎么调整的。是加了一层缓存？改了数据库 schema？还是像范例中一样加了一个规则引擎中间件？细节决定成败。
• 混淆“我”和“我们”：“我们决定采用新方案，然后我们一起把它开发出来了。” —— 我无法判断你的个人贡献。你应该说：“我提出了 A、B 两个方案，并分析了利弊，最终说服团队采纳了方案 A，然后我负责了核心模块的开发。”
• 结果没有量化：“项目很成功，业务方很满意。” —— 这是无效的结果。必须用数字说话，比如“GMV 提升 15%”、“P99 延迟降低 100ms”、“支持 QPS 从 500 提升到 2000”。
• 没有体现权衡（Trade-off）：这个问题的核心就是权衡。一个好的答案必须体现出你在“完美方案”和“快速交付”之间的思考和取舍。比如范例中放弃修改模型，而选择更快的中间件方案。

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

1. 追问：你提到的这个“规则引擎”听起来像个临时补丁（quick fix），它带来了什么技术债吗？你后来是怎么处理的？

   • 要点 1（承认并定义问题）：坦诚承认这是一个为了速度而做的妥协，它确实带来了技术债。具体来说，它让推荐逻辑变得分散（一部分在模型，一部分在中间件），增加了新工程师的理解成本。
   • 要点 2（展示长期规划）：说明你在完成紧急任务后，立刻创建了技术债偿还任务（tech debt ticket），并放入了下一个季度的规划中。
   • 要点 3（提出最终方案）：最终的解决方案是将规则配置能力整合进推荐模型平台，让产品和运营可以通过配置界面，动态调整不同推荐策略（如个性化、热门、清仓）的权重，而不是通过硬编码的中间件。这才是根本的解决方案。

2. 追问：当你说服团队放弃原有方案时，有没有遇到阻力？比如有同事认为应该坚持“正确”的技术方向。

   • 要点 1（识别阻力来源）：说明阻力主要来自一位资深同事，他认为临时方案会污染架构的纯粹性，并且担心影响正在开发的模型。
   • 要点 2（用数据和目标说话）：你没有和他争论架构好坏，而是把讨论拉回到业务目标上。你展示了业务方的时间表（两周后上线），并强调如果我们坚持原方案，肯定会错过这个为公司带来巨大收益的机会窗口。
   • 要点 3（寻求共赢）：你向他承诺，这只是一个带功能开关的临时方案，活动结束后就会下线。并且，这次收集到的“清仓品”用户行为数据，可以作为未来模型迭代的重要特征输入。这样既解决了当前问题，也为他的长远工作提供了价值。

3. 追问：你怎么验证你的“规则引擎”是正确工作的？特别是在高并发下。

   • 要点 1（单元和集成测试）：首先，我为新的规则逻辑编写了充分的单元测试，覆盖了各种边界条件（比如清仓商品不够 60% 怎么办，利润率为负数怎么办）。然后，在预发环境进行了完整的集成测试。
   • 要点 2（灰度发布和监控）：上线时，我们没有全量推送。我使用了灰度发布策略，先开放 1% 的流量给新逻辑，并密切观察监控仪表盘。我重点关注了三个指标：接口的 P99 延迟、错误率（Error Rate）、以及推荐结果中清仓商品的实际占比是否符合预期。确认指标平稳后，才逐步放大到 10%、50% 直至全量。

故事复用建议

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

• Tell me about a time you took ownership. (你主动识别问题、推动解决、对结果负责)
• Give an example of a time you had to make a decision with incomplete data. (在信息不全、时间紧迫的情况下做出技术判断)
• Describe a time you simplified a complex problem. (将复杂的“修改模型”问题，简化为“增加中间件”的工程问题)
• Tell me about a time you delivered results under pressure. (时间紧迫，但你依然交付了有影响力的结果)
• How do you handle disagreements with your teammates/manager? (用于回答追问中的“如何说服他人”)
• Bias for Action / Move Fast (你的行动非常迅速，没有拖延)
• Customer Obsession (你的一切决策都围绕着满足业务/客户的需求)