说说你有没有一次因为队友的论点而改变了主意。

考察要点

这道题考察的是候选人的心胸、学习能力和对事不对人的协作精神。面试官想看你是否能为了团队和产品的最优解，而放弃自己最初的想法，并能基于数据和逻辑做出判断，而非屈服于权威或情绪。

对于 Amazon，这道题直接考察 Have Backbone; Disagree and Commit（敢于谏言，服从大局）和 Are Right, A Lot（决策正确）。一个优秀的领导者会寻求不同观点，并愿意基于更优的数据或逻辑改变自己的立场。

高分示范答案（STAR）

Situation（背景） 我在上一家公司（某电商平台）担任推荐算法团队的技术负责人（Tech Lead），团队有 6 名工程师。2022 年 Q3，我们接到了一个任务，要重构已经服役 3 年的“猜你喜欢”推荐系统。这个老系统是基于用户离线画像和协同过滤的，更新周期是 T+1。

Task（任务） 业务方提出的核心要求是实现实时推荐，即用户在 App 内的点击、加购、收藏等行为，必须在 10 秒内反映到下一次推荐结果中。我最初的技术方案是基于我们熟悉的 Spark Streaming 做微批处理（Micro-batch），每 30 秒触发一次计算，我认为这在技术风险和开发成本上是最低的。

Action（行动） 这是我如何被说服并改变方案的全过程：

• 我提出初始方案并遭遇挑战：在技术评审会上，我详细阐述了基于 Spark Streaming 的方案，强调其稳定性、团队技术栈的熟悉度以及可控的开发周期。然而，团队里一位资深工程师小王提出了异议。他认为 30 秒的延迟对于追求极致体验的电商场景来说还是太长，无法捕捉到用户的“冲动消费”瞬间。他提议我们应该采用更激进的方案，使用 Apache Flink 这一真正的流式计算引擎。
• 我最初的抵触与要求：我当即表示了担忧。首先，团队里没人有 Flink 的大规模生产环境经验，学习成本和项目风险都很高；其次，引入新组件会增加运维的复杂度。但我没有直接否定他，而是提出：“如果你认为 Flink 更好，我需要数据来证明。你能不能用两天时间做一个 PoC (Proof of Concept)，对比 Flink 和 Spark Streaming 在我们核心场景下的端到端延迟？”
• 被数据说服的过程：两天后，小王拿出了 PoC 结果。他模拟了用户行为日志流，数据显示 Flink 的 P99 延迟稳定在 1.5 秒以内，而 Spark Streaming 最优也只能做到 25 秒左右，差距非常明显。同时，他还调研了业界另外两家头部电商的实践，都已从 Spark 迁移到了 Flink。这些客观数据和业界趋势，让我意识到我最初的判断过于保守，过于关注“规避风险”而忽略了“创造价值”。
• 我公开认同并全力支持新方案：在下一次团队会议上，我首先公开承认我之前的方案考虑不周，并感谢小王提出的挑战和详实的数据支撑。我宣布，我们将技术方案正式切换为 Flink。为了管理风险，我重新制定了项目计划：1）安排了为期一周的 Flink 技术突击培训和编码实践；2）我亲自负责 Flink 核心计算逻辑的架构设计，并让小王担任 co-pilot，确保知识传递；3）我与 SRE 团队沟通，为 Flink 集群争取了独立的监控和告警资源。我从方案的“反对者”变成了最核心的“推动者”。

Result（结果） 最终，我们比原计划提前一周上线了基于 Flink 的新推荐系统。

• 核心指标：推荐流的端到端 P99 延迟从过去的 T+1 缩短到了 2.8 秒，远超 10 秒的目标。
• 业务影响：“猜你喜欢”场景的点击率（CTR）在上线后第一个月提升了 12%，GMV 转化率提升了 5%。
• 个人成长：我深刻体会到，作为 Leader，我的职责不是永远“正确”，而是引导团队做出最正确的决策，即使那意味着否定自己。

低分陷阱（常见扣分点）

• 没有真正的分歧：选择一个无关痛痒的小事，比如“我本来想用 a 库，他说服我用 b 库”，这无法体现你的判断力和心胸。
• 屈服于权威而非逻辑：“我的老板/架构师让我改，我就改了。” 这体现的是服从，而不是基于逻辑的判断和思想转变。
• Action 过程模糊：只说“经过讨论，我们决定用新方案”，而没有说清楚你是如何被说服的，你看到了什么数据？你做了什么验证？你内心的思考转变是怎样的？
• 没有体现“Commit”：仅仅说“我同意了他的方案”，但没有展示你后续是如何全身心投入，并为新方案的成功负责的。一个好的答案必须体现你不仅“Disagree”，更重要的是“Commit”。
• 故事主角是“我们”：“我们讨论后觉得...”、“我们一起做了 PoC...”。面试官想知道你在这个过程中的思考和行动。

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

1. 追问：如果当时那位同事没有拿出强有力的数据，你还会改变主意吗？

   • 要点1（坚持原则）：我会坚持我的初始方案。因为在没有明确数据优势的情况下，选择风险更低、成本更可控的方案是更负责任的决策。我会向他解释，创新的热情值得鼓励，但工程决策必须基于证据。
   • 要点2（提供机会）：但我不会就此关上大门。我会告诉他，这个项目我们先用 Spark 保证交付，但我支持他利用 20% 的时间继续探索 Flink，或者在下一个项目中立项做更充分的预研。如果未来能证明其价值，我们随时可以进行技术升级。

2. 追问：这次分歧有没有影响你和这位同事的后续合作？

   • 要点1（正面影响）：恰恰相反，这极大地增进了我们的信任。他看到我是一个对事不对人、尊重数据和逻辑的 Leader，这让他未来更敢于提出建设性的反对意见。
   • 要点2（文化建设）：我也借此机会在团队中公开表扬了他，并强调了“用数据说话”的文化。这让整个团队的沟通都变得更加高效和坦诚，大家知道挑战我的想法是被鼓励的，只要有理有据。

3. 追问：你作为 Tech Lead，方案被下属挑战和推翻，会不会觉得有损你的权威？

   • 要点1（权威的来源）：我认为技术权威不来自于“永远正确”，而来自于能带领团队持续做出正确决策的能力。这包括了识别和采纳比自己更好的想法。
   • 要点2（职责的定义）：我的职责是为项目结果负责，而不是为我个人的某个想法负责。当团队成员能帮我找到更好的路径时，我应该感到高兴而不是威胁。拥抱更好的想法，并带领团队把它实现，这恰恰是技术领导力的体现。

故事复用建议

这个故事非常扎实，除了 Have Backbone; Disagree and Commit，还可以根据提问角度进行微调，用于回答以下问题：

• Ownership：你对最终的项目结果（包括风险）负全责，即使方案不是你首创的。
• Deliver Results：面对目标（10s 延迟），你没有满足于“差不多就行”的方案，而是追求最佳结果，并最终超额交付。
• Are Right, A Lot：你通过吸纳不同意见和关键数据，最终做出了正确的决策。
• Tell me about a time you took a risk. (采纳 Flink 是一个计算过的风险)
• Tell me about a time you empowered your teammates. (你给了小王机会去证明他的想法)
• Tell me about a time you handled a conflict within your team. (技术路线分歧是一种典型的良性冲突)