程序员的成长阶梯和级别定义

初级

初入职场的新人，一般叫助理工程师或者初级工程师。主要工作是：学习并熟悉公司常用的开发技术、涉及的工具和框架，熟悉公司的开发流程规范等等。

初级工程师在导师的帮助下，经过一段时间（1、2年）后，应该对公司的各种开发流程规范已经相当熟悉，熟悉其参与项目中的部分业务、产品和代码，能够按要求完成业务功能开发。

中级

中级与初级最本质的区分在于独立性。中级工程师应当能够独立承担开发工作，甚至有些还可以指导新人，成长为公司「动作执行」层面的中坚力量。

这个层面的基本要求就是：完成动作、达成品质、优化效率。多数的工程师都满足这个要求，品质可能有瑕疵，效率可能有缺陷。效率和品质总是在不断地迭代和改进中去不断完善，自身也在这个过程中不断成长。不少人卡在这个阶段，就是因为虽然不断地在完成工作，但却没有去反思、沉淀、迭代并改进。

 高级

这个级别基本属于能独立负责某个小项目或大项目中的子系统或模块，是项目的骨干成员，属于团队或项目中最大的个人贡献者。

相比于中级，高级工程师在「动作执行」层面属于攻坚力量，不仅能独立完成高级难度的开发任务，而且在用户体验（品质提升）和性能优化（优化效率）都能作更全面的考量。不仅对开发任务完成的又快又好而且还能清晰的定义出多快多好。比如，一个服务的响应时间 99.9% 的响应是 20 毫秒内，内存消耗估计不超过 1G，并发吞吐每秒 10000，类似能用清晰的数据来定义服务品质和效率。

 资深

进入这个级别说明在特定领域都已经具备了相当的积累，在项目和团队中担任技术骨干。除了自身专业知识、技能和实践经验的积累，还能够从中总结沉淀出有效的方法论，引导和组织团队成员一起进行推广应用。积极主动的输出自身经验，为跨团队项目提供技术支持。

这个级别有些叫「资深工程师」，有些叫「架构师」，而不同的叫法代表了两种不同的发展方向。在基础研发、算法或特定技术复杂领域会向「资深工程师」方向发展，属于深度优先；而在面向业务开发的领域，业务复杂度高于技术复杂度的场景，则会向「架构师」方向发展，属于广度优先。

很多有一定年头的高级工程师卡在这个级别的门槛边，往往有两个原因。一是自身虽然各种实战经验丰富，却没有系统的去梳理自己多年的积累，未能很好的形成体系（AKA方法论，有效的方法论的最大作用是帮助快速决策，而且决策的正确概率也会比较高）。或者是其虽胸有块垒、腹藏千言，却倒不出来，出现明显的瓶颈效应，外界也很难对其「资深」的程度作出有效评定。

 专家

技术专家一般在公司领衔重大技术项目，而且在其细分的技术领域，于业界也有公认的影响力。

以Java举例，在学习 Java 的过程中总有那么几个人，你不仅要去读他们的书还要去看并且使用他们写的代码，在 Java 这个领域你总是绕不过去。那么这就是他们在这个领域的影响力，自然也是这个领域的专家。所以，专家总和影响力挂钩，就是某个领域内你绕不过去的人。

 评定

不同级别的评价标准都应该定义覆盖多个维度的评价标准，并给出详尽的说明。低级别的评定中标准会相对宽松，高阶的晋升会有公司评审小组来组织晋升述职答辩，通过多维度的标准来做出一个做出一个综合的评价。

在一场半小时的述职中评定一个程序员的级别难度很大，准确性也不可能很高。正如前文所说很多「高级」的工程师虽然已经在特定领域进行了多年的沉淀积累，但这也只是第一层次：深度理解并掌握了某领域的知识和技能。下一层次则是能很好的表达和展示该领域的知识和技能，能让人容易听懂。如果做到这层的话，基本就大幅降低对你进行评定的门槛和难度。

 

 

 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　原文链接：程序员的成长阶梯和级别定义