聊聊工程师的专业职级晋升之道

这是鼎叔的第三篇原创文章。

行业大牛和刚毕业的小白，都可以进来聊聊。

工程师的职业发展一直是众多从业人员深感困惑的话题。各大公司都有完善的职级晋升通道和能力模型要求，高级别晋升还要通过专家面试。晋升的好处非常实际，可以挂钩更大的薪酬空间，有更多的培训资源和更大的职场挑战机会。通过晋升认证的难度也是指数式上升，远没有纸面上那么容易，毕竟高级别的人才梯队呈现金字塔形。

有些测试工程师工作一年很辛苦，加班无数，业务也成功发布了，但在高职级晋升考核时铩羽而归，甚至会产生转岗或离职的想法。因此，如何辅导工程师通过高级别的晋升考核，也是主管非常关注的问题。

鼎叔参与过多个公司的质量技术领域晋升标准制定，也进行过多场辅导晋升的授课，参与过数以百计的测试工程师面评考核。

写下本篇文章，助大家晋升一臂之力，适合各类专业岗位人员参考。

测试工程师的核心能力模型，可以阅读关联文章：聊聊测试工程师的核心能力模型

首先，工程师能力级别可以简单的划分为四个主要级别，可以抽象地定义不同级别的关键词，便于在不同部门，不同细分岗位能在框架层面对齐。

• 初级工程师，关键词“简单任务”：新手，只能完成单一任务，还不能独立承担项目的交付质量职责。

• 工程师，关键词“独立交付”：可以独立完成普通项目的质量交付，熟悉基本的流程，掌握基本的方法技能。

• 高级工程师，关键词“独当一面”：能够独立或者带团队完成复杂项目/平台的质量保障，能够对复杂产品梳理测试体系，运行合适的自动化实践方案，解决各类测试过程中的典型问题。

• 专家工程师/资深架构师，关键词“行业先进”：在特定技术领域能够独当一面，提供具备行业领先性的测试理论和解决方案，重大技术困难挑战的终结者。

随着级别的提升，对于所担任项目的规模、复杂度、困难深度和广度、理论原创性，方案适应性、行业先进性，都有更高的要求。

不论读者作为甄别工程师能力层级的面试官，还是辅导工程师参加专业晋升答辩的“导师”，下面这些指导经验都会带来益处。有效的辅导可以给工程师更大的信心，对专业修炼能建立正确的方向和态度。

一，储备优秀的STAR

STAR是最常用的能力面试方法，意指通过追问得到一个真实完整的能力展示案例。S表示案例发生时的背景/情景，T表示候选人承担的任务，A指候选人具体做了什么动作，R指得到了什么真实的可量化的结果。优秀的STAR一定是真实发生的项目事件，能和个人努力动作相关联的成果，体现出特定的专业素养。

我们在能力面评时经常会觉得可惜，员工明明有很好的技术，但是举的案例缺乏展示能力的代表性，或者解决的方法简单直白，不能展示更高级别的能力。因此在日常项目中要经常储备能体现深度挖掘难题，或系统化解决复杂问题的案例，并在团队中正式分享刚完成的技术案例，接受同事的技术评议，如此这样才能在正式面评中游刃有余。

二，业务成功和自己的关系

商场上的俗语：如果你能证明商业成功与你的关系，那你就是高工资！

我看到不少同学把自己参与的业务上线后的成功数据，用来佐证自己专业成就，这里通常是比较牵强的。一个新产品受用户欢迎，活跃度高，不一定是因为品质保障做得好，也不一定是产品经理设计的好，可能是因为用户习惯已经养成，或者某个热点事件推动了用户的兴致。

我们需要通过洞察分析，找到业务成功的数据，和自己核心工作的关系，这个并不是邀功，而是抓住“做了什么事最有价值”的本质。

比如，有的测试同学做稳定性测试专项，会把测试优化后版本的crash率每日监控曲线，和用户相关投诉数据做对比，证明相关满意度确实有一定的提升。类似逻辑虽然不能严格证明因果关系，但是这种求证态度是被认可的。

三，收益的量化

虽然是技术能力的考察，但是能力如果不能变成真实的收益，那就没有办法贡献价值。我也经常看到工程师分享技术原理眉飞色舞，但是说到给团队落地的效果却顾左右而言他。作为企业认证而言，能够对成果量化并让人信服是很重要的。收益的量化，不但要看效率，还要看满意度；不但要看现在，还要看未来。

例如自动化新测试工具的开发，为什么要进行这个开发（投资），能不能不做？哪种开发方案回报最大，从什么角度分析？目前的收益如何，如何度量收益，用户评价怎样？未来随着产品的变化，这个自动化收益能否持续？

如果不是为了技术练手，忌讳为了在晋升中体现技术能力而花大量精力创新测试工具，其实并不打算长期使用，团队没有采纳的意愿；或者用现有的开源或商业平台工具就可以解决问题。

四，打动面试官的细节

对于工程师的高级别晋升，要从众多候选人中脱颖而出，需要要在同级别的工程师中棋高一着，光依赖常规成果是不够出彩的，如何找到亮点，打动人心的细节，是辅导者可以多关注的。

越高级别的晋升，打动人的细节要越硬核。

这种细节可以是想法设法降低大家习以为常的昂贵设备成本，也可以是出乎意料的微创新解决了困扰已久的难题，还可以是持续挖掘软件缺陷后的根本原因，更可以是主动承担边界难题，或推动其他角色执行了老大难“承诺”。

五，抬头看方向

越是高级技术级别的工程师，越应该具备前瞻的行业技术视野，思考适合本业务或者本团队的前进方向。在面评时最好能主动论证自己成果的含金量，反客为主，而不是等着被质疑。

例如，我主导的效能提升方案，在行业内是什么水平（有数据对比更佳），为什么我没有借鉴XX公司的做法，我的信心是来自于什么理论和什么项目经验，等等。

看方向这个习惯肯定要在早期实行，包括同行优秀团队交流，行业大会的定向参与，相关论文的学习，高校老师的拜访，研读本领域的行业咨询报告等等。

六，聚焦一个案例

通常面评的时间非常有限，要在很短的时间要评委认可自己的岗位能力，最好的策略是主打一个核心案例。尤其对于高级别的工程师，一堆不出彩的案例，不如一个聚焦攻关并产生可观价值的案例。好的案例可以充分体现被面试者契而不舍的专业精神和严密的系统逻辑，充分地把这个案例的背景、价值、上线数据、个人主导内容说清楚。

针对其他可能引发面试官兴趣的个人能力，可以准备次要案例简单介绍，如果被追问再详细展开。正如个人的简历，所有写上去的内容都应该是有过实践甚至是深入思考的，不然的话建议不要写，否则被追问起来可能会留下负面的印象。

七，一线管理者

有些一线管理者参加专业晋升面评，有时会遇到尴尬的情况，技术工作都有参与，但是都没有深入了解，因此拿管理上的工作产出说事，这反而会体现专业上的心虚。有经验的评委会把“我们”做了啥和“我”做了啥区分清楚，管的井井有条不代表技术过硬。

对于一线管理者，我认为还是要实打实的承担具体技术项目的责任，有意识的提升特定的专项技术能力，注入自己的深度分析，并保障足够的投入。技术实力不足的债（技术债）在未来的职业生涯中还是要连本带利偿还的（鼎叔自己就遇到过这种惨痛教训）。

各大公司提拔一线技术经理都会把较高的专业职级作为硬门槛，深以为然。不鼓励为了管理者能顺利任命而在专业职级上放水。但是管理者举证技术能力的视角可以高一些，比如放在技术模型，工具选型，架构合理性分析等方面。

类似的，承担项目经理工作的人参加工程师晋升面评，也会遇到同样的尴尬，这种情况下要思考：我到底适合走项目管理通道（和人打交道，擅长推动目标达成），还是走技术通道（喜欢钻研技术，搞定技术问题）。

八，曾经“失败”

打“引号”的意思是，参与晋升考核这件事没有真正的“失败”，这个机制是让每个专业岗位的员工都能够对专业积累做提前的规划，做精心的价值总结，甚至有机会和公司专家做直接的技术沟通，得到职业发展的中肯建议。

如果晋升评定没有通过，首先也不要陷入自我怀疑，本身高级别的专业职称竞争就激烈，有限的时间个人发挥也会有影响，专家自身也不会那么精准客观，当然评审组织者通常会尽量减少非专业水平因素的干扰。

但是，确实有必要做一些个人发展的反思，下一次再接再厉。特别要对比上一次的“失败”，我又获得了什么可视化的新成果。

鼎叔多次面评过两次甚至三次参加同一等级的高级工程师，大多数都最终通过了，而且体现的进步令人刮目相看。如果因为这个工程师绩效高、主管评价高，就放水让他通过职级认定，反而不是好事。

九，其他

其他需要列举，但是通常在专业面评时一笔带过的信息有：辅导人员情况，主导流程规范，项目管理和人才管理的心得，分享课程，认证/专利和奖励信息等。属于可以加印象分，但如果完全没有，可能会在某个能力项上失分。

特别强调的是类似分享课程的举证，可能在某些岗位的高晋升级别上是必选项，可能会一票否决。即使是技术优秀的个人贡献者，如果不能通过系统梳理，讲出来给大家听，影响足够的人，对组织而言也是颇有缺憾的。

还有部分通道会要求，高职级人员的举证门槛是培养过一个成功晋升的徒弟，这块也需要尽早和领导沟通安排，做一个靠谱的导师。

最后就是PPT表现形式，鼎叔的建议是不要受限于模版，尽可能展示真实界面，尽可能用图表可视化，标注准确的关键数据。对着清晰的架构图或逻辑图来讲解技术思路，而不是靠语言干讲。

重要面评之前，可以邀请自己的主管或者专家，做一个模拟演练，很容易发现整个过程中的疏忽。熟悉你的主管和专家，对你的亮点看法，可能和你自己以为的不一样，这是一个很好的对齐机会。

最后，总而言之，功夫还是放在平时，日常多表达自己的思路，勇于拿出深思熟虑的方案，个人影响力建立起来是最关键的，没有临时抱佛脚的秘籍。