Java 程序员的级别定义

初级

刚入职场的新人一般都在这个级别了。这一点倒是不区分本科还是硕士,比如我第一家公司硕士毕业进去算初级工程师,本科是助理工程师。而公司对于刚毕业的同学的级别定义也是类似,本科 T1-1,硕士 T1-2。大级别都是 T1,小级别上的细分区分可能也就是在薪酬起点上略有不同(别问我差多少,我也不知道,但估计差距不大)。

中级

要说中级和初级最本质的区分是什么,我觉得体现在独立性方面。初级的同学刚进公司,一般还会给安排一对一的导师帮助其快速上手,所以很多初级的同学在工作上就对导师存在依赖性。而工作一段时间(1、2 年吧)后,他们对公司的各种开发流程规范已经相当熟悉,熟悉其参与项目中的部分业务、产品和代码,能够按要求完成业务功能开发。

所以中级的工程师基本能够独立承担开发工作,甚至有些还能指导新人了,成长为公司「动作执行」层面的中坚力量。这个层面的基本要求就是:完成动作、达成品质、优化效率。但观察下来这个级别的工程师多数都能做到完成,但品质可能有瑕疵,效率上甚至可能有缺陷。而关于效率和品质总是在不断的迭代和改进中去不断完善的,自身也在这个过程不断成长向着下一个阶梯迈进。

而不少人卡在这一阶段,就是因为虽然不断的在完成工作,但却没有去反思,沉淀,迭代并改进,导致一直停留在了不断的重复中。

高级

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

相比于中级,高级工程师在「动作执行」层面属于攻坚力量,不仅能独立完成高级难度的开发任务,而且在用户体验(品质提升)和性能优化(优化效率)都能作更全面的考量。不仅对开发任务完成的又快又好而且还能能清晰的定义出多快多好。

资深

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

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

很多工作有一定年头的高级工程师卡在迈入这个级别的门槛边,我觉得有两个原因,一方面是自身虽然各种实战经验丰富,但却没有系统的去梳理自己多年的积累,未能很好的形成体系。所谓体系也这就是上面所说的沉淀出有效的方法论,有效方法论的最大作用是帮助快速决策,而且决策的正确概率还会比较高。另一方面,就是其虽胸有块垒,腹藏千言却倒不出来,出现明显的瓶颈效应,造成的负面作用就是很难对其「资深」的程度作出有效评定。

专家

技术专家一般在公司领衔重大技术项目,而且在其细分的技术领域,于业界也有公认的影响力。以「家」冠名会让人感觉遥不可及,高不可攀。实际「家」也分大小,一般的「大家」实际都是稀世珍宝,举国稀有的,确实是遥不可及,但也有「小家」相对来说就没那么遥远。

而专家总和影响力挂钩,影响力听起来很虚,那换个相对实的角度说说影响力。作为一个 Java 程序员,在学习使用 Java 的过程中总有那么几个人,你不仅要去读他们的书还要去看并且使用他们写的代码,在 Java 这个领域你总是绕不过去。那么这就是他们在这个领域实实在在的影响力,自然也是这个领域的专家。所以,专家可能就是这个领域内你绕不过去的人吧。

评定

有了级别的定义,那么如何来评定一个人到底属于怎样的级别呢?这点在低级别的评定中标准会相对宽松,而越往高级别走越难评定。对于不同级别的评定标准一些大公司都定义了覆盖多个维度的评判标准,并给出了详尽的说明。对于高阶的晋升会由公司专家评审小组来组织晋升述职答辩,评审小组的评委就是根据这些多维度的标准来做出一个综合的评判。

技术不成体系,成为架构师需要掌握的技术体系:

以上就是架构师需要掌握的知识技术体系,看看你离架构师的路还有多远。

1、具有 1-5 工作经验的,面对目前流行的技术不知从何下手,需要突破技术瓶颈的。

2、在公司待久了,过得很安逸,但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的。

3、如果没有工作经验,但基础非常扎实,对 java 工作机制,用设计思想,常用 java 开发框架掌握熟练的。

4、觉得自己很牛 B,一般需求都能搞定。但是所学的知识点没有系统化,很难在技术领域继续突破的。

查看原文