技术评委支招:如何提高年底晋升成功率?

骆俊武 2020-12-27 17:58:00
​前阵子,我花了不少时间在组员的晋升辅导上。另外,也担任了 3 天的技术晋升评委。

 

刚好临近年底了,很多公司陆续启动了晋升流程。趁这个时间点,我谈一谈我的个人经验,给大家点启发。

 

先申明一下,本文就不讲那些投机取巧的套路了,只关注:如何在一个公平竞争的环境中,提高晋升的成功率?

 

对于那些日常表现都称不上当前职级要求的同学(比如说绩效很差),晋升基本不太可能,因为评委的职级一般都比你高两个级别,就算你过了部门内的初筛,要水过大部分的评委概率还是很小的。

 

我讲的内容主要针对平时表现正常的人,给你们一个思路去提炼和准备,同时帮助你们踩准评委们的喜好。

 

重要的话说在前面 

 

很多公司的晋升答辩只有 30 分钟,PPT陈述 15 分钟,回答评委问题 15 分钟。因此,如何在这短短的半小时里,用你的表现去说服评委,看起来还是有一定挑战的。

 

但我个人认为,如果你能吃透「晋升的标准」,再有针对性的去准备,其实难度没有想象中的那么大。

 

怎么理解「晋升的标准」呢?其实你只需要证明好这样一件事:通过讲述你做了什么?拿到了什么样的结果?来说明你的能力已经达到下个职级的要求了。具体怎么拆解,后文会详细展开。

 

从这一点来看,晋升其实就是一个命题作文,难度肯定比求职面试小一些,因为晋升 PPT 是你事先准备好的,评委的问题也基本都是围绕你的 PPT 展开,就算超纲也不会很离谱。

 

因此,如果你所有的准备工作都能围绕「晋升的标准」去反复推敲和优化,每一点都尽可能地做到最好,你就能比别人准备得更充分,胜算自然更大。

 

准备晋升材料的正确姿势 

 

先聊一聊如何系统性地准备晋升材料。

 

对于技术同学来说,一般都是选择自己最有说服力的项目作为答辩内容,然后准备一个 PPT 进行现场陈述。

 

这一步,很多同学容易犯方向性的错误。为什么这么说呢?首先,所选的项目没打到点上,那些你以为「很厉害」的项目很有可能并不适合作为答辩的素材(后面会具体举例);其次,写 PPT 很像是在写技术设计文档一样,你呈现的技术点并不是评委们想看到的点。

 

这两个问题只要有一个没处理好,晋升的希望就会变小很多。最有效的破解方法其实并不难,需要你回到评委的评价标准上,先彻底理解「目标职级的要求」,然后再将你做的事情、以及拿到的结果往这个要求上靠。

 

只有按照这个思路走,方向才不会走偏。下面我详细展开说一下。

 

 
1、 如何更通俗地理解职级要求

 

大部分公司都会有明确的职级体系以及衡量标准,通常是按照开发能力、架构能力、业务能力、协作能力等维度进行拆解,会详细地列出每一项能力的行为标准(很细、很晦涩)。

 

这是我前一家公司对于 P6 级别「开发能力」这一项的具体要求:

 

深刻理解服务在实际运行过程中各个环节的相关原理,如硬件(CPU、内存、硬盘等)、内核(进程调度、内存管理等)、应用(设计模式、同步异步设计)、网络(协议栈等),清楚各个部分对实际服务的影响,并在实际系统开发中灵活应用。

 

这还只是其中某一项能力的行为标准,如果真要把每个职级各项能力的要求都熟记于心,估计会把评委们逼疯。

 

因此在真正实践时,评委并不会很死板地使用这个标准,而是抽象出一些「关键词」以及采用「人物对比」的方式去操作,先从自己熟悉的员工中选择几位表现优秀、同时和目标职级相同的人,拿他们与候选人进行横向对比。

 

以开发同学为例,从评委视角通常会这样来把控各个大级别的要求:

 

  • 初级:能在他人的指导下完成工作;具备简单模块的开发能力,代码质量达标。

     

  • 中级:能独立完成日常工作;具备子模块的设计能力,熟练掌握常用的技术栈。

     

  • 高级:能指导他人完成工作;具备跨模块和子系统的设计能力,有一定的技术深度,对高可用、高并发、高扩展等问题有完整的思路。

     

  • 专家:能对业务和技术进行整体规划;具备复杂业务场景的系统设计能力,能体系化的分析和解决问题,视野全面。

 

可以看到:职级越高,负责事情的复杂度越大,对技术能力的要求也越高。这还只是表象的理解,背后更深层次的解读其实是:从点、到线、再到面,系统性的思考力和把控能力,高度也要跟上。

 

这个标准基本适用于我们常见的互联网大厂,只是有些公司会将大级别进一步细分成多个子级别而已。大家务必先吃透这个晋升标准,再考虑下面的事情。

 

 
2、选择项目的正确思路

 

技术同学的晋升一般是以「研发项目」作为载体,项目选择的好与坏能直接决定晋升的结果,因此一定要反复斟酌。

 

对于晋升答辩来说,一个「好」项目一定要具备这两个因素:

 

  • 项目贡献:代表你做出的成绩,可以是业务价值,也可以是技术价值(比如研发效率的提升、研发成本的降低等等);

  • 专业能力:代表你做事过程中体现出来的实力。可以是技术能力、业务能力或者协调能力等等。

 

上个章节提到了:有些你以为「很厉害」的项目其实并不适合作为答辩的素材,一定是没法同时满足上面那两点要求。比如说有不错的技术亮点,但是没产生实际价值(或者项目的负面评价很多),在评委看来:要么是没想清楚为什么做?要么是没想清楚该怎么做?

 

上面说的两个因素,项目贡献往往比专业能力更重要一些,一定要有很具体的东西让评委们看到。如果只是能力够了,贡献还不够,这种情况要通过晋升也是很难的。

 

此外,不论是项目贡献还是专业能力,一定要和目标职级的要求相匹配。假如你的目标职级是技术专家(P7及以上),那所选的项目最好能对业务起到一定的助力作用、或者能横向复制影响到其他业务,技术上则建议从全链路、整体架构这个视角去梳理。

 

说这么多了,那到底该如何挖掘最合适的项目呢?建议按照下面的步骤去操作:

 

  • 详细梳理回顾晋升周期中你参与过的所有项目,将每个项目的技术亮点和成果整理一遍。有些项目可能闪光点不多,这种都不要放过,后续可以通过合并多个项目的方式串联进去。

 

  • 初步筛选:根据第一遍的梳理结果,拉上你的直属 leader 以及团队中的高 P 做一次深入讨论,参考目标职级的要求做一次初筛,留下 4 个左右价值最高的项目(注意:有些亮点不多的小项目可以合并成一个大项目,只要你能找到一条主线将它们串联起来即可)。

 

  • 深度挖掘:针对第 2 步筛选出来的项目,做更深入的亮点和成果挖掘,这个时候可以将业务视角带入进去,结合你对业务的理解对技术点做下升华。价值的体现最好落实到具体数据上(可以是业务指标、也可以是研发维度的 Bug 数量、研发工期等)。这一遍需要你将项目想呈现的亮点全部整理出来。

 

  • 精细筛选:再对第三步的结果做一次精筛,考虑答辩时间只有 15 分钟,一般选出 2 个即可。标准是:成果要明显,技术亮点的密度合适(每个项目至少要有 2 个亮点)。

 

整体来看,项目选择是很核心的一环,项目没选好,后面做得再好可能都于事无补,因此一定要高度重视。

 

 
3、 一份优质的 PPT 该如何写?

 

项目以及各个项目的亮点确定下来后,下一步就是准备答辩 PPT 了。我先说下「项目部分」该以什么样的思路去准备内容。

 

我观察到的是:很多人习惯性按照写技术文档的方式去写答辩 PPT,先是项目背景,然后是技术方案,最后是技术细节。

 

其实这个思路是不对的,因为晋升答辩不是技术评审,你不需要将所有细节都体现出来,不然会导致信息量过大,从而很难将你的项目亮点凸显出来。

 

我建议换成这个思路:围绕项目亮点去组织你的 PPT,因为这才是评委关注的东西。从亮点出发,你再想你需要交代哪些东西能让评委听懂并认可。按照这个思路走,你就能省略很多不必要的背景交代以及技术细节呈现,将足够多的篇幅留给真正想要展现的亮点上。

 

何谓亮点?无非就是上面提到的两个核心因素:项目贡献和专业能力。围绕亮点,内容组织的顺序建议是这样:业务背景交代 -> 问题描述 -> 技术方案 -> 项目成果。

 

PPT 中除了项目以外,当然还有其他锦上添花的东西。一个完整的答辩 PPT,我建议包括以下 5 个部分:

 

  • 个人简介:重点说明你在当前公司的经历,比如什么时候加入的?在什么时间点参与了哪些业务?如果有比较出彩的学历或者工作背景也可以提一下,加深评委对你的印象。

 

  • 工作回顾:将晋升周期中你参与过的项目做下罗列,重点突出有影响力的项目。

 

  • 核心项目:这是 PPT 最重要的部分,需要展开陈述,会占到 80% 左右的篇幅,按照前面说的思路组织即可。

 

  • 其他贡献:能进一步证明你价值的其他信息,比如公共组件的开发、性能优化、项目管理、或者团队管理工作等等,简单罗列出工作内容和成果即可,无需展开。

 

  • 未来规划:可以是支撑业务长期发展的技术规划,可以是解决技术痛点的方案改进,确保有远见、有高度、可落地、不务虚。

 

当然,一个优质的答辩 PPT,还有非常多的细节需要打磨,下面几点建议是根据我当晋升评委时看到的一些 case 总结的:

 

  • 材料的层次关系、论证结论的因果关系,一定要有非常清晰的顺序,不能逻辑混乱。

 

  • 清楚每一页 PPT 你最想传递给评委的亮点是哪一个?充分利用标题、文字加粗等形式突出这个亮点,去掉不必要的废话。

 

  • 非常不建议粘贴大段代码,这不是代码审查会,你可以用流程图、类图等方式呈现你的思路。

 

  • PPT 不需要很绚丽,但是标题、图片、文字等样式要做到统一,不要有错别字或者图片看不清楚的情况,技术同学该有的严谨性要体现出来。

 

 现场述职的关键点 

 

再说下非常关键的现场述职环节,你有 15 分钟的时间演示 PPT,还有 15 分钟用来回答评委的提问,这个环节非常考验你的临场发挥能力。

 

 
1、如何才能做好 PPT 演示?

 

因为答辩的时间很紧凑,因此一定要排练。如果条件允许的话,建议按照正式流程在团队内做两遍预演。一方面是帮助你找到合适的节奏,确保能在 15 分钟左右将 PPT 演示完;其次,也是为了发现内容以及表达上不完善的地方进行改进优化。

 

第二点,要和评委有眼神上的交流,建议用光标或者激光笔引导评委跟着你的节奏走。同时,注意观察现场气氛和评委们的状态,如果评委出现心不在焉、犯困等现象,一定要及时调整你的节奏,将评委的注意力拉回来。

 

第三点,适当的背景交代必不可少。评委不是你团队的同事,他们极有可能不了解你的业务、不清楚你的设计背景、不了解系统的历史包袱,这些交代不清楚,他们很难理解你的方案,但是也切忌讲得过于细节。

 

第四点,清楚什么内容最容易打动评委。在逻辑顺畅的前提下,评委最想听的内容是你的思考过程,为什么这么设计?你又是如何判断和权衡的?

 

 
2、问答环节该如何应对?

 

问答环节应该是晋升流程中最难、最关键的一环。一个问题没答好,可能就全盘皆输了。

 

首先,你肯定要提前准备评委可能会问到的问题。基本分成这两类:

 

  • PPT 范畴内的问题:和 PPT 强相关,可能是评委没理解你的讲解逻辑提出来的;也有可能是评委想将问题进一步复杂化,考察你的应对能力;

  • PPT 范畴外的问题:针对你所用的技术或者所做的业务延展出的问题。评委想考察你的全局视角,目标职级越高,这类问题越重要。

 

下面我举一些具体的例子,以便大家有更好的思路去搜集问题:

 

  • 你为什么用方案 A,而不是方案 B?你为什么要自研,而不是用开源方案或者中台的能力?(评委想判断你在做一件事情之前,是否做过深层次的调研)

 

  • 如果业务再扩张几倍、或者并发再增大几倍,系统会遇到哪些技术挑战?你又会如何优化技术方案?(评委想将现实问题难度加大,来判断你的技术水平)

 

  • 业务目前存在的问题有哪些?重心是什么?各种核心业务指标分别是多少?从技术维度你能做哪些事情更好地助力业务?(评委想考察你对业务的敏感度,以及从更高级别的视角来审视你的思考高度是否足够了)

 

  • 过去一段时间你的成长是什么?有哪些需要突破的瓶颈?团队以及你个人接下来的规划是什么?(评委想考察你是不是一个善于复盘总结,同时抬头看路的人)

 

除此之外,两点最实用的建议:

 

  • PPT 中每一个信息点,都不要有技术盲区或者业务盲区,同时确保你的技术方案和业务数据是合理,同时经得起推敲的。

 

  • 面对质疑性的问题时,不要有防卫心态,不要尝试将项目中考虑不足或者逻辑不严谨的地方合理化,而是虚心接受评委的意见就行。

 

写在最后 

 

本文从评委视角,非常详细地解读了技术晋升各个环节的思路和要点。虽然说功夫在平时,但是临阵磨枪也很重要,它能让你准备得更充分、同时更有针对性。

 

当你把自己能控制的东西做到极致时,其他的就交给天意吧,毕竟还有很多不可控的因素会决定最终的晋升结果。评审通过与否未必能完全地体现出你的能力。

 

另外,从整个职场发展来看,一次晋升失败可能并不会对你的整个生涯造成实质性的影响。反而,以下两点是我认为决定职场发展高度最核心的因素:

 

  • 练本事:要清楚技术上的精进非一天练成,当你努力把平时做的事情做到极致,别人只做到 80 分,但你做到 90 分甚至 100 分,当遇到一个典型问题时,别人是解决了就结束了,你是刨根问底彻底弄清楚,这就是差距。

 

  • 攒口碑:做一个靠谱的同事,不去计较是不是比别人多做了,承诺的事情不讲困难、不找借口,而是尽自己最大的努力去完成并且做好,你可能又超过 80% 的人了。 

 

当能力和口碑都具备了,是你的早晚是你的。

 

当然,还是要预祝大家晋升顺利!关于晋升,如果你有任何疑问,欢迎评论区留言交流!

 

作者丨骆俊武
来源丨公众号:IT人的职场进阶(ID:BestITer)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告