讲讲你如何在新的团队中赢得信任的经历。

考察要点

这道题直接考察 Amazon 的领导力准则（Leadership Principle）中的 Earn Trust（赢得信任）。赢得信任不仅仅是待人友好，它意味着：

1. 言行一致，说到做到：你通过可靠的行动和交付，证明你的能力和承诺，让同事相信你是一个靠谱的人。
2. 坦诚谦逊，善于聆听：你尊重他人，仔细倾听不同意见，同时能够坦率地承认自己的错误或知识盲区，而不是不懂装懂。
3. 以身作则，拔高标准：你不仅自己做到最好，还能通过你的专业能力和积极影响，帮助团队一起进步。

高分示范答案（STAR）

Situation（背景） 去年 7 月，我作为高级工程师加入公司核心支付团队。这是一个成立已久、非常有经验的 5 人团队，他们负责一个有 5 年历史的高并发计费系统。系统的技术债比较多，而且团队成员之间已经形成了非常强的默契和工作流程，对于新成员，尤其是像我这样被期望“带来新变化”的空降兵，他们表面客气，但实际上保持着审慎和观望的态度。

Task（任务） 我的首要任务不是立即交付某个新功能，而是融入团队并真正获得他们的信任，以便未来能推动一些必要的技术重构。我给自己设定的一个可量化的隐性目标是：在一个季度内，从一个“任务接受者”转变为团队在关键技术决策上会主动咨询的“意见贡献者”。

Action（行动） 我没有急于表现自己，而是采取了三个关键行动：

1. 主动“扫雷”，承担苦活累活：我发现团队积压了大量关于监控告警优化的低优先级工单，因为处理这些问题费时费力，又没有直接的业务绩效，没人愿意主动碰。我利用熟悉新系统的时间，主动承担了这项工作。我花了三周时间，梳理了全部 200 多条告警规则，将其中 30% 的重复或失效告警（例如，某个 Redis key 已经下线但监控脚本还在跑）进行了清理和归档。
2. 暴露脆弱，坦诚求助：在处理一个告警时，我遇到了一个关于底层分库分表逻辑的难题。我没有自己埋头硬啃，而是在团队的公开频道里提问，并坦诚地说：“这个问题我研究了半天没搞懂，特别是 XXX 这块的历史设计，感觉自己还是太嫩了。团队里哪位元老最清楚这块，求带。” 后来一位资深同事帮我解答了，我不仅公开感谢，还在周会上再次点名感谢他，并分享了我从他那里学到的东西。这让大家觉得我不是一个威胁，而是一个可以合作、懂得尊重他人经验的伙伴。
3. 交付超出预期的价值：在清理告警的过程中，我发现大部分告警的根源是某个上游服务的超时配置不合理。我没有仅仅停留在“修复告警”层面，而是主动拉上那个上游团队的负责人，用我整理的数据（过去一个月内，该问题导致了 15 次 PagerDuty 事件，浪费了团队约 10 个小时的 on-call 时间）说服他们进行了一次联合优化。

Result（结果）

• 量化业务结果：通过我的告警治理和跨团队推动，我们团队的月度 PagerDuty on-call 告警数量从平均 50 次/月下降到 15 次/月，降幅达 70%。核心服务的 P99 延迟也因此稳定在 200ms 以下。
• 赢得信任的证明：大约两个月后，当团队需要为下一个季度的核心架构升级做技术选型时，团队的技术负责人（Tech Lead）在会议上主动说：“XX（我的名字），你对稳定性这块很有经验，这个方案你来牵头调研一下吧。” 这标志着我成功实现了从“新人”到“核心骨干”的转变。
• 我的收获：我深刻理解到，赢得信任最快的方式不是发表宏伟的计划，而是从解决身边最具体、最痛苦的小问题开始，用可靠的行动和谦逊的态度说话。

低分陷阱（常见扣分点）

• 用“我们”代替“我”：
  • 反例：“我们团队觉得告警太多了，所以我们一起优化了系统。”（面试官：你到底做了什么？）
• 结果空洞，没有量化：
  • 反例：“项目很成功，大家都很满意，团队关系也变好了。”（面试官：多成功？怎么证明？）
• Action 只是工作流水账：
  • 反例：“我来了以后，先是看了文档，然后参加了会议，接着开始写代码，最后修复了 bug。”（面试官：这些不是任何一个员工都该做的吗？你的关键决策是什么？）
• 故事平淡，缺乏挑战：
  • 反例：“我加入了一个新团队，我跟大家打成一片，很快就融入了。”（面试官：这很好，但你的专业价值体现在哪里？你如何处理专业上的分歧和挑战？）
• 自我吹嘘，不懂谦逊：
  • 反例：“我一去就发现他们的系统很烂，我告诉他们应该怎么做，后来他们都听我的了。”（这不叫 Earn Trust，这叫 Arrogant）

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

1. 追问：你提到有位资深同事一开始对你保持距离，你是如何察觉的？又是如何与他建立信任的？

   • 要点 1 (具体观察)：不要说“我感觉他不喜欢我”。要说具体的行为观察，例如：“在几次会议上，当我提出建议时，他通常会保持沉默，或者用‘我们以前试过，行不通’来回应，但没有提供太多上下文。”
   • 要点 2 (主动破冰)：说明你采取了非正式、非对抗的方式。例如：“我没有在会议上直接挑战他，而是在午饭或喝咖啡时，主动找他请教那个‘行不通’方案的具体历史背景和技术细节。我把他放在‘专家’和‘老师’的位置上。”
   • 要点 3 (价值交换)：展示你如何提供你的价值来换取他的认可。例如：“在理解了他的顾虑后，我结合我的经验提出了一个改进版方案，并明确指出方案中哪部分是为了解决他提到的历史遗留问题。当我把 credit 分给他时，我们的关系就打开了。”

2. 追问：你说你推动了上游团队做优化，如果他们当时拒绝了你的请求，你会怎么办？

   • 要点 1 (理解对方)：首先表示理解，而不是指责。说明你会先去了解他们拒绝的深层原因，是资源不足？优先级不够？还是技术上不可行？
   • 要点 2 (升级数据)：如果只是优先级问题，你会把影响进一步量化和升级。例如：“我会把‘浪费我们团队 10 小时 on-call 时间’这个数据，转化为‘因为这个问题，我们支付成功率下降了 0.1%，相当于每月 X 万美元的潜在损失’，然后把这个数据同步给双方的经理，从更高的业务视角来争取资源。”
   • 要点 3 (备选方案)：展示你有 Plan B。例如：“如果他们实在无法修改，我会为我的服务增加一个更智能的熔断或降级策略，在我的系统内部消化掉他们带来的不稳定，确保我的核心业务不受影响。这体现了 Ownership。”

3. 追问：你提到清理了 30% 的失效告警，你是如何判断哪些告警是“失效”的？有没有出现误判的情况？

   • 要点 1 (清晰的方法论)：展示你做事的严谨性。例如：“我定义了三类‘失效’告警：1. 监控对象已下线；2. 告警阈值与当前业务水位严重不符（如，过去 100 QPS 是高危，现在 1000 QPS 是常态）；3. 告警信息模糊，无法指导 on-call 工程师进行任何有效操作。我主要清理第一类和第三类。”
   • 要点 2 (风险控制)：说明你如何避免误判。例如：“对于阈值类告警，我没有直接删除，而是标记为‘待观察’，并与团队中最了解该业务的同事进行 1-on-1 确认。对于所有删除操作，我都在 Confluence 上做了详细记录，并保留了备份，确保万一误删可以快速恢复。”
   • 要点 3 (承认失误与学习)：如果真的有误判，诚实地讲出来，并说明你学到了什么。这是加分项。“初期确实有一次，我误删了一个看似无用，但实际用于季度财务审计的告警。我立即恢复了它，并把这次失误加入到我的操作文档中，增加了一条规则：任何与财务、合规相关的监控，必须与相关方交叉确认后才能变更。这让我学会了对不熟悉的领域保持敬畏。”

故事复用建议

这个故事的核心是“通过解决实际问题来建立影响力”，因此它可以灵活应用在考察以下能力的问题中：

• Ownership (主人翁精神)：你主动承担了不属于你核心职责的“烂摊子”。
• Deliver Results (交付成果)：你交付了可量化的、超出预期的业务成果（告警减少 70%）。
• Bias for Action (崇尚行动)：你没有停留在观望和学习阶段，而是迅速找到切入点并采取行动。
• Dive Deep (深入钻研)：你没有止步于表面问题，而是深挖告警根源，并推动了跨团队解决。
• Learn and Be Curious (学习与好奇)：你通过请教和实践，快速学习了新团队的技术和痛点。
• Disagree and Commit (敢于谏言，服从大局)：如果故事中加入与同事或上级的不同意见，并最终达成一致，也可以用于此。