5 年经验面试：当了组长还要不要自己写代码？写多少合适？
面试怎么回答
我认为组长要写代码，但要换一种写法。写太多会让自己成为团队瓶颈和单点，管理和沟通顾不上，组员也得不到有挑战的机会；完全不写又会对系统失去感知，评审方案和估工期不准。比例取决于团队规模：三到五人的小组可能还要写一半左右，六到十人降到两三成，再大基本不写生产代码。写的内容尽量避开关键路径上的紧急任务，选工具、自动化、技术预研、性能优化、打样模板这类即使被打断也不影响进度的工作。同时通过认真做代码 Review 和方案评审、参与重大故障排查、关注核心任务的运行数据来保持技术敏感度。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
刚当上组长的人常常纠结：完全不写代码，担心技术退化、失去对细节的判断；写得太多，又会成为团队的瓶颈，管理的事情顾不上。面试官问这道题，是想看你对组长角色的理解，以及能不能根据团队情况调整自己的投入。
两个极端都有问题
写得太多：
- 自己负责关键模块，一忙起来团队的事就没人管；
- 组员遇到问题找不到你，方案评审、需求沟通被拖延；
- 你成了单点，你请假，你的模块就没人能处理；
- 组员得不到成长机会，最有挑战的活都被你做了。
完全不写：
- 对系统的实际状况失去感知，评审方案时判断不准；
- 估工期脱离实际；
- 在团队里的技术威信逐渐下降。
写多少合适
没有固定比例，取决于团队规模和阶段：
- 3–5 人的小组：组长通常还要承担 40%–60% 的开发工作，但不要负责最紧急、最关键路径上的任务；
- 6–10 人的组：写代码的比例降到 20%–30%，更多时间用于规划、评审、沟通和带人；
- 更大规模：基本不写生产代码，但保持对技术的深入理解。
写什么样的代码
- 不在关键路径上的任务：比如工具、自动化脚本、技术预研、性能优化，即使被打断也不会拖累项目进度；
- 探索性的工作：新技术的 POC、为团队打样的模板代码；
- 帮助理解系统：参与排查疑难故障、做代码 Review。
保持技术敏感的其他方式
- 认真做代码 Review 和方案评审；
- 参与重大故障的排查和复盘；
- 定期看核心任务的运行数据和监控；
- 持续学习，跟踪技术趋势。