为什么您想在[公司]工作？

考察要点

这道题表面上问你为什么想来我们公司，实际上是在考察你的长期承诺（Long-term Commitment）、**文化契合度（Cultural Fit）**以及你是否对公司有深入的、超越表面的研究。你需要证明你的加入是深思熟虑的结果，而非海投。

对于 Amazon，这道题重点考察：

• Customer Obsession: 你是否理解并认同我们对客户的极致关注。
• Learn and Be Curious: 你是否对我们的业务、技术和挑战有足够的好奇心和深入研究。
• Think Big: 你是否将自己的职业抱负与公司宏大的愿景联系在一起。

高分示范答案（STAR）

Situation（背景） 在我的上一家公司（一家中等规模的生鲜电商平台），我担任后端技术主管，带领一个 5 人团队负责核心的交易履约系统。该系统处理从用户下单到仓库分拣、配送的全流程状态同步，是公司的业务中枢。

Task（任务） 随着公司业务量在过去一年增长了 300%，我们的单体架构履约系统遇到了严重的瓶颈。特别是在大促期间，订单状态更新的延迟会从平时的 50ms 飙升到 2-3 秒，导致用户端频繁看到“处理中”的过时状态，客诉率增加了 40%。我的任务是主导一次彻底的架构重构，目标是将系统 P99 延迟降至 200ms 以下，并能支撑未来 2-3 年 10 倍的业务增长。

Action（行动） 为了设计一个真正面向未来的高可用、高扩展架构，我采取了以下几个关键行动：

1. 深入研究业界标杆：我没有直接开始画架构图，而是花了整整一周时间研究业界顶尖公司是如何解决类似问题的。我重点阅读了 Amazon 关于其订单和物流系统的几篇公开技术博客和 AWS re:Invent 的演讲。其中，Amazon 将庞大系统拆解为目的单一、高度自治的微服务（如订单服务、支付服务、库存服务），并通过 SQS/SNS 进行异步解耦的“细胞化架构”思想，给了我极大的启发。我意识到，我们遇到的问题，Amazon 在十年前就已经在以千百倍的规模面对并解决了。

2. 制定并宣导方案：基于这些研究，我设计了一套新的事件驱动架构。我主张将原有的单体应用拆分为 4 个核心微服务：订单管理、库存扣减、支付链接、物流通知。我引入了 Kafka 作为事件总线，替代了原来数据库轮询的笨重方式。起初，我的 CTO 对引入 Kafka 有顾虑，担心团队技术栈复杂度增加。我通过制作一个 POC（概念验证）原型，用真实数据证明新架构能将峰值吞吐量提升 20 倍，并准备了一份详细的运维和监控计划，最终说服了他。

3. 主导落地与灰度：我将重构任务拆解成多个阶段，带领团队先从影响最小的“物流通知”服务开始剥离。我建立了详尽的监控看板，实时追踪新旧系统的业务指标一致性。在为期一个月的灰度发布过程中，我每天早上组织 15 分钟站会，快速解决前一天发现的问题，确保了整个迁移过程对业务零影响。

Result（结果） 新系统上线后，效果立竿见影：

• 在最近一次“618”大促中，系统平稳运行，订单履约 P99 延迟稳定在 80ms，远低于 200ms 的目标。
• 系统的吞吐能力提升了 20 倍，为后续的市场推广活动彻底扫除了技术障碍。
• 因订单状态延迟导致的客户投诉率下降了 95%。

最重要的是，这次经历让我深刻体会到，在我的前公司，我是在“解决”问题；而在 Amazon 这样的地方，我将有机会“定义”解决问题的方法，并将其应用到服务全球亿万用户的场景中。我渴望从一个应用先进理念的人，变成一个创造和推广这些理念的人，这就是我为什么想加入 Amazon 的根本原因。

低分陷阱（常见扣分点）

• 空洞的赞美：“我一直很欣赏亚马逊，它改变了世界，是一家伟大的公司。”
  • 反例：这种回答毫无信息量，任何人都可以说。面试官会认为你根本没做功课。
• 只谈个人索取：“我想来这里学习成长，和最优秀的人一起工作，提升我的技术视野。”
  • 反例：这只说明了公司能给你什么，没有说明你能为公司带来什么。动机听起来很自私。
• 将产品使用体验等同于工作动机：“我每天都用 Prime 会员，体验非常好，所以想来工作。”
  • 反例：这只是一个普通用户的感受，无法体现你作为专业人士对公司技术、文化或战略的深度思考。
• 对公司业务和技术一无所知：“我听说你们在用微服务，我也做过，所以我觉得很适合。”
  • 反例：过于浅薄。你应该能说出具体是哪个业务（如 Prime Video, AWS Lambda, Alexa）的哪种技术挑战吸引了你。

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

1. 追问：你提到了亚马逊的“细胞化架构”，除了异步解耦，你认为这个架构思想还有哪些核心优势是你想学习和实践的？

   • 要点1（故障隔离）：强调细胞化架构的最大好处是“爆炸半径”控制。一个“细胞”（Cell）的故障不会影响到其他细胞，这对于构建全球性高可用服务至关重要。可以举例说，AWS 的可用区（AZ）设计就是这种思想的物理体现。
   • 要点2（独立部署与演进）：每个细胞可以独立部署、升级和扩展，使得不同团队可以快速迭代自己的服务，而无需进行大规模的、高风险的协同发布。这完美契合了 Amazon 的 "Two-Pizza Team" 理念和 Ownership 原则。

2. 追问：你提到说服了对引入新技术有顾虑的 CTO。如果他当时坚决反对，你会怎么办？

   • 要点1（寻找替代方案，坚持目标）：首先，我会再次确认 CTO 的核心顾虑是什么。如果确实是团队对 Kafka 的运维能力不足，我会寻找一个更简单但同样能实现异步解耦的替代方案，比如使用 RabbitMQ 或者云厂商提供的托管消息队列服务。我的目标是解决问题（解耦和削峰），而不是执着于某个具体的技术。这体现了 Deliver Results。
   • 要点2（分阶段证明价值）：如果无法一步到位，我会提议一个更小的试点项目。比如，只将最没有风险的“短信通知”服务剥离出来，用新技术栈实现。通过这个小项目的成功，建立团队的信心和经验，再逐步推广到更核心的模块。这体现了 Bias for Action 和务实的精神。

3. 追问：除了技术挑战，Amazon 的文化（Leadership Principles）中，哪一条最让你产生共鸣？为什么？

   • 要点1（选择一个 LP 并用故事证明）：选择一个你最有感触且有故事支撑的 LP，比如 Ownership。你可以说：“我最认同 Ownership。在我刚才提到的项目中，我没有把自己当成一个‘执行者’，而是把系统的成败当成自己的事。从发现问题、研究方案、说服决策者，到带领团队落地，我全程负责到底。我享受这种端到端的责任感。”
   • 要点2（连接到未来工作）：将这个 LP 与你期望在 Amazon 的工作方式联系起来。“我了解到 Amazon 的工程师被期望成为他们服务的真正主人，这正是我所追求的工作方式。我希望拥有一个我能全身心投入、持续打磨并对其最终客户价值负责的产品或服务。”

故事复用建议

你刚才分享的这个“重构履约系统”的故事是一个非常强大的核心故事，至少可以用于回答以下问题：

• Tell me about a time you took ownership. (你从头到尾主导了整个项目)
• Tell me about your most technically challenging project. (架构设计、技术选型、迁移过程都很有深度)
• Tell me about a time you had to influence others without authority. (说服 CTO 接受新技术方案)
• Deliver Results (结果有明确的、超预期的量化指标)
• Dive Deep (你深入研究了业界方案，并做了 POC 验证)
• Invent and Simplify (你用事件驱动架构简化了复杂的单体系统)
• Bias for Action (面对系统瓶颈，你没有等待，而是主动发起了重构)