行為面試：講一次你帶同事完成第一次生產變更的經歷

題目

請講一次你指導一位同事完成第一次生產變更的經歷。說明如何識別學習目標、拆解風險、安排審查和逐步放權，並給出結果與後續能力變化。

場景與限制

故事應包含真實服務、變更範圍、對方當時缺少的經驗和明確上線窗口。你可以是正式導師、程式碼審查者或臨時搭檔，但不能把代替對方完成任務當成指導成果。

核心考點

考察能否把幫助從「給答案」轉為「建立能力」。Google 程式碼審查指南把教學視為審查的重要作用；GitLab 導師實踐強調配對、目標和持續回饋。高品質回答要同時保護生產安全與對方決策空間。

參考回答結構

使用 STAR-L：Situation 說明變更與學習背景；Task 說明要保護的服務目標與導師邊界；Action 說明如何共同拆解、準備回滾、小步審查、安排觀察期並逐步讓對方主導；Result 給出上線、事故、交付時間和能力指標；Learning 說明改進了哪些輔導方式。

關鍵細節

說清護欄，例如預發布驗證、雙人審批、灰度比例、監控和回滾演練；也說明哪些決定由同事自己做。結果可用獨立完成變更、減少審查往返、值班信心或後續帶教衡量，不能只說「關係更好了」。

常見誤區

把指導變成代寫程式碼；只講對方不足；在生產壓力下跳過護欄；把成功歸因於自己；沒有說明回饋如何改變下一步行為；把導師關係寫成單向命令。

評估標準

優秀答案有明確學習目標、逐步授權、安全護欄和可核驗結果，能解釋何時介入、何時退後，以及如何讓知識沉澱到文件或團隊流程。一般答案只有一次結對程式設計，沒有對方能力變化。

追問

如果同事堅持採用你認為有風險的方案怎麼辦？

先要求雙方寫出假設、風險和驗證方法，設計最小可逆實驗；仍超過權限或風險預算時，按團隊審查路徑升級，而非私下替換方案。

如何判斷已經可以放手？

觀察對方能否解釋設計、選擇指標、執行回滾和回應異常；讓對方在低風險步驟中連續主導，再減少你的審批和提示。

這次指導如何影響團隊？

把重複問題整理成運行手冊、檢查清單或審查範本，邀請對方補充，並追蹤後續變更是否更快、更安全或減少重複求助。