工程師職稱評審：技術與溝通并重

這幾年在組里看過不少同事準備職稱材料,發現一個挺有意思的現象:有個做了七八年的老哥,線上故障排查能力特別強,每次救火都是他頂上去,但到評審的時候,他自己的材料寫得特別干,就幾行字——"負責某某系統優化""解決了若干性能問題",評委看完根本不知道他到底做了什么。反倒是另一個做了五年的同事,技術深度可能還差點意思,但他每次項目結束都會整理一份文檔,把背景、難點、方案都寫清楚,評審時一翻材料就能看出他干了哪些事。結果你猜怎么著,后者先過了。

這事讓我想明白一件事:工程師光把活干漂亮還不夠,你得讓別人看見你干了什么,更重要的是,讓別人理解你做這件事的價值在哪。這不是什么虛的東西,就是實打實的職場生存技能。

先說技術積累這塊。很多人覺得我天天寫代碼、改Bug、上線發版,這些就是積累了。但你仔細想,三五年經驗和七八年經驗的工程師,差別到底在哪?不只是代碼量的區別,更多是你在項目里承擔的角色不一樣了。做了三五年,你可能還在具體模塊里深挖,比如把某個接口的響應時間從兩百毫秒優化到五十毫秒,或者重構了一段屎山代碼讓后續維護變簡單。這些都很扎實,但評審時你要能說清楚:為什么要做這個優化?影響了多少用戶?節省了多少資源?到了五年往上,你應該開始帶一些小模塊,或者在跨團隊的技術方案里有自己的判斷,比如在某次架構討論會上,你提出的方案被采納了,最后幫整個系統規避了一次潛在的容量瓶頸。這種事情不記下來,過半年你自己都忘了。

我的建議很簡單:每次項目結項或者季度復盤的時候,花半小時把自己做的三件最關鍵的事記下來。不用寫得多fancy,就按"什么時間、碰到什么問題、我做了什么、結果怎么樣"這個結構來。比如去年雙十一之前,你發現某個服務在壓測時CPU飆高,你排查出是某個地方有熱點數據沒做緩存,加了緩存之后CPU使用率降了百分之四十,這次大促期間沒出過問題。就這么幾句話,但信息都在了。平時攢著,到評審前一翻,你會發現自己其實做了不少事,只是當時沒意識到要留痕。

再說材料怎么寫。很多工程師寫東西特別惜字如金,或者反過來,寫了一大堆技術細節,但看的人云里霧里。你得記住,評審的人不一定懂你那個領域的所有細節,你要用他們能聽懂的方式講清楚。舉個例子,有人會寫"優化了數據庫查詢",這就太空了。你可以改成"某個報表頁面加載要十幾秒,用戶投訴特別多,我排查發現是查詢時沒走索引,加了索引之后頁面打開時間降到兩秒以內,投訴量下降了百分之八十"。前后對比一下,后者讓人一眼就能看出你解決了一個真實的用戶痛點,而不是為了優化而優化。

還有一點,工程師容易陷入的誤區是覺得"我就是個寫代碼的,不需要搞什么人際關系"。但實際上,評審看的不只是你一個人悶頭干活的能力,還要看你能不能跟別人配合,能不能把你的經驗傳遞出去。這不是讓你去搞辦公室政治,而是說你在日常工作里,是不是愿意幫其他組解決問題,是不是帶過新人,是不是在團隊分享會上講過你踩過的坑。這些事情做多了,到評審的時候,組里的人、合作過的其他團隊,都會記得你。我見過一個做基礎架構的同事,他每次解決完一個棘手問題,都會寫個簡短的復盤文檔發在內部群里,時間長了大家有類似問題都會來找他。后來他申報高級工程師,好幾個組的人都幫他說話,這種影響力是平時一點一點積累出來的。

說到底,技術和溝通從來不是對立的。你把技術做扎實,然后學會用別人聽得懂的方式講出來,讓你的價值被看見,這才是一個完整的職業發展路徑。評審只是一個節點,真正有用的是你在這個過程里養成的習慣:做事留痕、總結復盤、主動分享。這些東西不僅幫你過評審,更會讓你在后面的職業生涯里走得更順。