工程师职称评审：技术与沟通并重

这几年在组里看过不少同事准备职称材料,发现一个挺有意思的现象:有个做了七八年的老哥,线上故障排查能力特别强,每次救火都是他顶上去,但到评审的时候,他自己的材料写得特别干,就几行字——"负责某某系统优化""解决了若干性能问题",评委看完根本不知道他到底做了什么。反倒是另一个做了五年的同事,技术深度可能还差点意思,但他每次项目结束都会整理一份文档,把背景、难点、方案都写清楚,评审时一翻材料就能看出他干了哪些事。结果你猜怎么着,后者先过了。

这事让我想明白一件事:工程师光把活干漂亮还不够,你得让别人看见你干了什么,更重要的是,让别人理解你做这件事的价值在哪。这不是什么虚的东西,就是实打实的职场生存技能。

先说技术积累这块。很多人觉得我天天写代码、改Bug、上线发版,这些就是积累了。但你仔细想,三五年经验和七八年经验的工程师,差别到底在哪?不只是代码量的区别,更多是你在项目里承担的角色不一样了。做了三五年,你可能还在具体模块里深挖,比如把某个接口的响应时间从两百毫秒优化到五十毫秒,或者重构了一段屎山代码让后续维护变简单。这些都很扎实,但评审时你要能说清楚:为什么要做这个优化?影响了多少用户?节省了多少资源?到了五年往上,你应该开始带一些小模块,或者在跨团队的技术方案里有自己的判断,比如在某次架构讨论会上,你提出的方案被采纳了,最后帮整个系统规避了一次潜在的容量瓶颈。这种事情不记下来,过半年你自己都忘了。

我的建议很简单:每次项目结项或者季度复盘的时候,花半小时把自己做的三件最关键的事记下来。不用写得多fancy,就按"什么时间、碰到什么问题、我做了什么、结果怎么样"这个结构来。比如去年双十一之前,你发现某个服务在压测时CPU飙高,你排查出是某个地方有热点数据没做缓存,加了缓存之后CPU使用率降了百分之四十,这次大促期间没出过问题。就这么几句话,但信息都在了。平时攒着,到评审前一翻,你会发现自己其实做了不少事,只是当时没意识到要留痕。

再说材料怎么写。很多工程师写东西特别惜字如金,或者反过来,写了一大堆技术细节,但看的人云里雾里。你得记住,评审的人不一定懂你那个领域的所有细节,你要用他们能听懂的方式讲清楚。举个例子,有人会写"优化了数据库查询",这就太空了。你可以改成"某个报表页面加载要十几秒,用户投诉特别多,我排查发现是查询时没走索引,加了索引之后页面打开时间降到两秒以内,投诉量下降了百分之八十"。前后对比一下,后者让人一眼就能看出你解决了一个真实的用户痛点,而不是为了优化而优化。

还有一点,工程师容易陷入的误区是觉得"我就是个写代码的,不需要搞什么人际关系"。但实际上,评审看的不只是你一个人闷头干活的能力,还要看你能不能跟别人配合,能不能把你的经验传递出去。这不是让你去搞办公室政治,而是说你在日常工作里,是不是愿意帮其他组解决问题,是不是带过新人,是不是在团队分享会上讲过你踩过的坑。这些事情做多了,到评审的时候,组里的人、合作过的其他团队,都会记得你。我见过一个做基础架构的同事,他每次解决完一个棘手问题,都会写个简短的复盘文档发在内部群里,时间长了大家有类似问题都会来找他。后来他申报高级工程师,好几个组的人都帮他说话,这种影响力是平时一点一点积累出来的。

说到底,技术和沟通从来不是对立的。你把技术做扎实,然后学会用别人听得懂的方式讲出来,让你的价值被看见,这才是一个完整的职业发展路径。评审只是一个节点,真正有用的是你在这个过程里养成的习惯:做事留痕、总结复盘、主动分享。这些东西不仅帮你过评审,更会让你在后面的职业生涯里走得更顺。