行为面试：讲一次你带同事完成第一次生产变更的经历

题目

请讲一次你指导一位同事完成第一次生产变更的经历。你需要说明如何识别学习目标、拆解风险、安排评审和逐步放权，并给出结果与后续能力变化。

场景与边界

故事应包含真实的服务、变更范围、对方当时缺少的经验和明确的上线窗口。你可以是正式导师、代码评审者或临时搭档，但不能把替对方完成任务当成指导成果。

核心考点

考察你是否能把帮助从“给答案”转为“建立能力”。Google 的代码评审指南把教学视为评审的重要作用；GitLab 的导师实践强调配对、目标和持续反馈。高质量回答应同时保护生产安全和对方的决策空间。

参考回答结构

使用 STAR-L：Situation 说明变更与学习背景；Task 说明你要保护的服务目标和导师边界；Action 说明如何共同拆解、准备回滚、进行小步评审、安排观察期并逐步让对方主导；Result 给出上线、事故、交付时间和能力指标；Learning 说明你改进了什么辅导方式。

关键细节

说清护栏，例如预发布验证、双人审批、灰度比例、监控和回滚演练；也要说明哪些决定由同事自己做。结果可用独立完成变更、减少评审往返、值班信心或后续带教来衡量，不能只说“关系更好了”。

常见误区

把指导变成代写代码；只讲对方哪里不足；在生产压力下跳过护栏；把一次成功归因于自己；没有说明反馈如何改变下一步行为；把导师关系写成单向命令。

评估标准

优秀答案有明确学习目标、逐步授权动作、安全护栏和可核验结果，能解释何时介入、何时退后，以及如何让知识沉淀到文档或团队流程。一般答案只有一次结对编程，没有对方能力变化。

追问

如果同事坚持采用你认为有风险的方案怎么办？

先要求双方写出假设、风险和验证方法，设计最小可逆实验；如果仍超过权限或风险预算，按团队评审路径升级，而不是私下替换对方方案。

如何判断已经可以放手？

观察对方能否解释设计、选择指标、执行回滚和回应异常；让对方在低风险步骤中连续主导，再减少你的审批和提示。

这次指导如何影响团队？

把重复问题整理成运行手册、检查清单或评审模板，邀请对方补充内容，并跟踪后续变更是否更快、更安全或减少重复求助。