题目重点：个人编码应补关键缺口，避免替代团队成长和日常管理。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 答案来自本人管理经验，团队规模、周期和人员结果必须真实；没有正式管理经历应区分tech lead/mentor与绩效管理权限。
- 内部级别、绩效流程和人员政策随组织不同，不将某公司的做法泛化为统一标准。
解题路线
- 给本人典型周期的真实分配范围，并说明项目阶段/事故如何改变，不能给一个适用于所有团队的比例。
- 列必须完成的管理输出：方向/优先级、反馈、招聘、跨团队依赖。编码安排不能长期挤掉这些基础责任。
- 选择适合manager亲自写的任务，如原型验证、低依赖修复或明确无人可做的紧急工作；关键长期owner应让团队有稳定责任，不把自己设成全系统唯一专家。
- 日程保护反馈与深度工作时间，保留升级路径。编码忙时怎样delegate、谁承接人员问题要说清，而非“我下班后再补”。
- 定期看manager介入是否造成review等待、成员无决策机会或只等你debug。若是，转知识传递与授权，减少长期救火。
手动走一遍
关键事故临时深度参与可合理，结束后应补文档/训练和owner，使同类事故不再都依赖你。技术原型完成后交清接口与取舍，不在所有后续PR里替团队决定细节。
规模与取舍
主答约2分钟，准备一项可展开5分钟的真实案例；用团队规模、阶段、职责和可支持的结果说明scope，不编造业务或人事数字。
易错点与追问
容易失分的边界
- 用写很多代码证明经理价值，却漏人员反馈。
- 承诺固定一半时间写代码，不核对团队需要。
继续深挖
- 当人员问题与上线deadline冲突，你怎样安排？
- 如何保持技术判断力而不亲自实现每个项目？
