你有没有过需要在技术债务和新功能之间进行平衡的经历？

考察要点

这道题旨在考察候选人在现实工程约束下的务实精神和影响力。面试官想看你是否能理解业务的紧迫性，并能用数据和清晰的逻辑，说服产品、业务等非技术同事，为系统的长期健康投入资源。

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

1. Ownership (主人翁精神)：你是否对代码库的长期健康负责，而不仅仅是完成当前的功能。
2. Deliver Results (达成业绩)：你如何在技术限制和业务压力下，依然找到路径交付成果。
3. Earn Trust (赢得信任)：你如何通过数据和沟通，与产品经理等合作方建立信任，共同做出最佳决策。

高分示范答案（STAR）

Situation（背景） 去年，我在一家电商公司担任推荐算法团队的资深工程师，团队共 6 人。我们的主要任务是提升首页“猜你喜欢”信息流的点击率。当时业务增长很快，产品团队不断提出新的、复杂的推荐策略，导致我们的推荐服务代码（一个 Python Monolith）变得越来越臃肿和脆弱。

Task（任务） 产品经理希望我们在第二季度上线三个全新的、计算密集型的推荐功能（例如“实时协同过滤”、“好友购买相似品推荐”），以应对即将到来的 618 大促，目标是将信息流的 CTR 提升 15%。但我评估后发现，现有系统每增加一个新策略，不仅开发周期长达 1 个月，还会导致整个服务的 P99 延迟增加约 50ms。直接开发新功能，系统很可能在大促前就崩溃。我的任务是，找到一个方法，既能支持业务快速迭代，又不会拖垮整个系统。

Action（行动） 面对这个挑战，我采取了以下几个关键步骤：

• 第一步，我用数据量化了技术债的“成本”。我没有直接说“代码太乱了，需要重构”，而是拉取了过去半年的数据，做了一张图表，清晰地展示：1）新推荐策略的平均上线周期已从 2 周延长到 4.5 周；2）每次上线后，服务的 P99 延迟都会出现一次不可逆的阶梯式上涨；3）过去一个月，有 3 次线上故障是由不同推荐策略间的耦合导致的。我把这张图表发给了产品经理和总监，并标注：“按此趋势，618 大促期间，我们的服务可用性将低于 99%”。

• 第二步，我提出了一个“两条腿走路”的务实方案，而非全盘重构。我建议将新的、计算密集型的策略，剥离到一个独立的 Go 语言微服务中。老的、稳定的策略继续保留在现有系统。我设计了一个轻量级的推荐网关，负责向新、老服务扇出请求，并做结果融合。我强调，这样做的好处是：1）我们可以立即在新服务上开发新功能，不受旧代码束缚；2）新服务的故障不会影响核心推荐，实现了风险隔离。

• 第三步，我主动承担了最难的部分来建立信任。为了打消团队对引入新语言和架构的顾虑，我主动请缨，利用一个周末搭建了新微服务的脚手架（scaffolding）和 CI/CD 流程，并实现了一个最简单的推荐策略作为 Demo。周一晨会，我向团队演示了新服务的毫秒级响应速度和独立的部署能力，大家看到了立竿见影的好处，很快就达成了共识。

• 第四步，我和 PM 重新排定了优先级。我们达成一致：将 Q2 的前三周投入到新服务的建设和第一个新功能的迁移上。我承诺，一旦新服务跑起来，后续两个新功能的开发时间将从 1 个月缩短到 1.5 周。

Result（结果） 这个方案非常成功。我们最终在 618 大促前顺利上线了全部三个新功能。

• 业务指标：大促期间，“猜你喜欢”的整体 CTR 提升了 18%，超出了 15% 的目标。
• 工程效率：新推荐策略的平均开发周期从 4.5 周缩短至 10 天，发布频率提升了 3 倍。
• 系统性能：主推荐服务的 P99 延迟稳定在 150ms，没有因为新功能而恶化。新微服务的 P99 延迟更是低至 20ms。 我学到，将技术问题转化为可量化的业务风险和机遇，是推动正确决策的最有效方式。

低分陷阱（常见扣分点）

• 抱怨产品经理或公司文化：反例：“我们公司的 PM 就喜欢拍脑袋，根本不懂技术，天天逼我们加功能，导致技术债堆积如山。” —— 这表现出你缺乏影响力和解决问题的能力。
• 行动归功于“我们”：反例：“我们觉得系统有问题，所以我们决定重构，然后我们开发了一个新服务。” —— 面试官无法判断你个人的贡献，是你提出的方案，还是你只是一个执行者？
• 结果没有量化：反例：“项目很成功，系统变快了，大家都很满意。” —— 多快？效率提升多少？业务指标涨了多少？没有数字就没有说服力。
• 方案过于理想化：反例：“我告诉 PM，我们必须停掉所有业务需求半年，花时间把整个系统用最新的技术栈重写一遍。” —— 这显示出你缺乏商业头脑和务实精神，在真实商业环境中几乎不可行。
• 只谈技术，不谈影响：反例：“我把单体应用拆分成了几个微服务，用了 gRPC 通信，部署在 K8s 上。” —— 为什么要这样做？它解决了什么业务问题？带来了什么商业价值？

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

1. 追问：当你把数据图表发给产品经理时，他的第一反应是什么？如果他坚持要按原计划开发，你会怎么办？

   • 要点 1 (共情与对齐)：我会首先表示理解他的压力，强调我们的目标是一致的——确保 618 大促的成功。
   • 要点 2 (聚焦风险)：我会把讨论的焦点从“技术好坏”转移到“业务风险”上。我会说：“我担心的不是代码不好看，而是我们有 80% 的概率无法在 618 前稳定地交付这三个功能，甚至可能导致大促期间服务宕机，这个风险我们能接受吗？”
   • 要点 3 (提供备选方案)：如果他仍然坚持，我会提出一个折中方案，比如：“我们是否可以先集中资源，用老方法实现一个最重要的新功能，同时我利用 20% 的时间验证我的新架构。如果我们第一个功能就延期了，那就证明老路走不通，届时我们再全面转向新方案。” 这是一种用最小成本验证问题的方式。

2. 追问：你选择了新建一个 Go 微服务，当时有没有考虑过其他方案，比如在现有 Python 系统内进行重构？为什么最终选择了前者？

   • 要点 1 (展示权衡过程)：是的，我考虑过两种主要方案。方案A：在 Python 单体内部进行模块化重构。优点是技术栈统一，团队成员没有学习成本。缺点是重构过程和新功能开发耦合在一起，风险高，无法做到真正的资源和故障隔离。
   • 要点 2 (解释决策逻辑)：我最终选择方案B（新建 Go 微服务），主要基于三点考虑：1）性能：新的推荐策略是计算密集型的，Go 的并发性能远超 Python，能从根本上解决延迟问题。2）隔离性：新服务可以独立部署、扩缩容和失败，彻底切断了风险。这对于保障 618 大促的稳定性至关重要。3）团队成长：引入一个高性能语言，可以提升整个团队的技术视野和能力。虽然有短期学习成本，但长期收益巨大。

3. 追问：这个新服务上线后，运维成本和复杂性是否增加了？你是如何处理的？

   • 要点 1 (承认复杂性)：是的，引入新服务确实增加了系统的复杂性。我们从管理一个单体变成了管理两个服务和一个网关，监控、部署和排查问题的链路都变长了。
   • 要点 2 (展现主动性)：在项目初期我就预见到了这个问题。因此，我主导制定了一套“标准化运维SOP”。具体来说，我为新服务搭建了独立的 Grafana Dashboard，整合了关键业务和系统指标；我编写了统一的部署脚本，实现了一键部署和回滚；并且，我组织了两次培训，让团队所有人都熟悉新服务的监控和应急处理流程。通过这些标准化的手段，我们把额外的运维成本降到了最低。

故事复用建议

这个故事的核心是“用数据驱动、务实的、有影响力的技术决策”，可以灵活复用于回答以下问题：

• Tell me about a time you took ownership of a problem outside your defined role. (你主动分析了技术债的商业影响)
• Describe a time you had to influence someone without authority. (你说服了产品经理和总监)
• Give me an example of a complex problem you solved. (技术选型、架构设计、项目管理的综合问题)
• Tell me about a time you had to make a decision with incomplete data. (在项目初期，你对新架构的收益做了预判和承诺)
• Describe a time you simplified a complex process. (你用新架构简化了新功能的开发和发布流程)
• Tell me about a time you disagreed with your manager or a stakeholder. (如果你和 PM 在初期有分歧)