题目重点：用对方起点、具体反馈、逐步放手和后续独立成果回答 mentor 经历，不把头衔当结果。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 没有正式 mentor 头衔也可诚实讲一次 pair programming、onboarding 或 review 支持，但不可称自己正式带过多人。
- 案例要保护被带教者隐私，不拿对方早期困难贬低其能力。
- 带教结果关注对方能否独立完成任务和获得发展，而不只看自己投入时间。
解题路线
- 说明对方的起点与希望达到的能力，例如能独立值班、提交 API 改动或解释故障路径；与对方共同确认目标，而不是直接给答案。
- 讲具体方法：示范一次、共同完成一次、让对方主导、在 code review 给可执行反馈；根据学习速度调整节奏。
- 说明难点和自己的调整：反馈过密造成依赖、进度冲突或任务过难时怎样修正。若需要正式 manager 支持，何时拉入。
- 用独立成果和持续性验证：对方后来独立交付、能向别人解释设计、事故处理更稳，或反向给自己反馈。尊重不能量化的成长，不捏造晋升功劳。
手动走一遍
虚构训练例：新同事第一次维护支付重试路径，你先共同画状态机，第二周让其自己修一个低风险错误分支，你只在 review 中追问幂等边界。几周后其能独立写回归测试并主导一次上线。候选人应换成真实里程碑。
规模与取舍
非算法题。可用目标→支持→放手→结果四段讲 60–90 秒，再准备一条自己做得不好的反馈，以及为何该方法适合对方。
易错点与追问
容易失分的边界
- 只说‘我很乐于助人’，没有对象目标和结果。
- 把替对方完成任务当成带教成功。
- 过度强调自己贡献，否定对方独立努力。
- 没有正式 mentor 头衔就编造经历。
继续深挖
- 对方一直依赖你审所有代码，如何调整？
- 带教影响了自己 deadline 时怎样与经理平衡？
- 如果被带教者不同意你的技术建议，你如何处理？
