程式設計師的職涯發展不只是技術能力的提升，更需要全方位的規劃和持續的自我投資。本章探討技術能力評估、職涯規劃、面試技巧等核心主題。

技術能力評估#

編程能力的定義#

編程能力：把「邏輯」翻譯成程式碼的能力。編程能力強，意味著能編寫正確的程式碼、編寫速度快、bug 少、效能好、質量高。

編程能力強的人：

• 熟練使用編程語言和開發類庫
• 思路清晰，面對複雜邏輯能寫出 bug free 的程式碼
• 能合理利用資料結構和演算法編寫高效程式碼
• 能靈活使用設計思想、原則和模式編寫高質量程式碼

編程能力弱的人：

• 邏輯思維能力較差
• 面對複雜邏輯編寫速度慢，容易考慮不周
• 缺乏效能意識，不懂得分析時間、空間複雜度
• 只追求能執行，不考慮可讀性、可擴展性

能力考察的三個維度#

立命之本：技術、業務、能力#

不管哪個行業，混得好的人都要有兩把刷子。對於程式設計師來說，這「兩把刷子」包括技術、業務和能力三個方面。

技術競爭壁壘#

如何形成技術壁壘：

• 從事有技術難度、技術挑戰的崗位
  • 基礎架構、中間件、資料庫等偏底層開發
  • 人工智能演算法等入行門檻較高的細分領域
• 在一個細分技術領域長期、深入積累
• 別人無法在短期內超過你

業務競爭壁壘#

技術驅動的公司其實很少。 即便是 Google，90% 的項目都是業務、產品驅動的。高精尖技術集中在一小撮項目中。

適合積累業務壁壘的領域：

• 金融系統
• 銀行系統
• 財務系統
• 清結算系統
• 物流系統

靠技術只能面到阿里 P7 層級。想面到 P8、P9，靠的不只是技術，還需要對某個業務的深入積累。很多領導之所以能做領導，不是技術牛，而是對業務熟悉。

成事能力壁壘#

對於技術沒太大挑戰、業務也不複雜的項目，可以多積累成事能力、解決問題的能力。

成事能力包括：

• 分析總結能力
• 邏輯思維能力
• 溝通協調能力
• 自我驅動能力

比起固定的技術和業務知識，成事能力對於職場發展更加重要。職位越高，成事能力就越重要，畢竟企業最終看的是結果，而不是技術有多好。

入場門票：學歷、項目、履歷#

現實認知#

招聘市場已從賣家市場變成買家市場。公司不僅加大面試難度，還會在學歷、過往經歷等方面先過濾一批候選人。

一般來說：

• 好學校的學生對計算機基礎知識掌握得更好
• 學習能力、邏輯思維更強
• 成績好的同學往往執行力和交付能力更強

通過學歷過濾候選人是高效的招聘手段。公司不在乎因此漏掉一兩個優秀的候選人，或者錯招一兩個不優秀的候選人。

面向簡歷打工#

如果說技術、業務、能力是立命之本，決定了你能不能在職場比賽中勝出，那麼學歷、項目、履歷就是入場門票，決定了你可以選擇哪個賽道。

建議：

• 學歷太低：考個好點的學歷
• 項目經驗：在公司內部努力選擇有技術含量的項目
• 履歷提升：跳槽去知名的互聯網公司

職場軟技能#

學生思維要不得#

職場不是學校。影響你向上發展的因素很多，肯定不是單靠技術。

學校 vs 職場：

技術好不等於貢獻多#

常見問題：

• 技術好的人愛自嗨，鑽研高精尖技術
• 這些技術從短期或長期看，都沒給團隊、公司帶來收益
• 公司不會為不產生效益的付出買單

正確態度：

• 學會跟公司共同成長
• 你的成長要為公司的成長貢獻力量
• 為公司、為領導解決問題，才有升職加薪的機會

必要的軟技能#

要想職場混得好，以下軟技能不能成為短板：

• 溝通能力
• 協作能力
• 總結彙報能力
• 向上管理能力

不是推崇純靠「耍手段」上位，而是這些軟技能起碼不能成為短板，不要讓非技術、非能力的因素，阻礙了職場發展。

面試技巧#

面試官的視角#

設計模式面試#

面試官常見題型：

1. 手寫設計模式：讓候選人手寫單例、工廠等

   • 這種偏記憶的題目沒有區分度
   • 候選人容易突擊準備

2. 給需求寫程式碼：給一個功能需求，讓候選人設計和實現

   • 討論程式碼的可讀性、擴展性等質量問題
   • 讓候選人繼續最佳化

3. Code Review：給一段有問題的程式碼，讓候選人找問題並重構

不管是資深工程師、架構師，還是技術 Leader，只要應聘一線技術研發崗，都應該能現場寫一段程式碼。這是最直接、最有效檢驗基本技術素養的途徑。

候選人的回答策略#

面對需求類題目：

1. 首先明確需求

   • 大部分功能需求都是籠統、模糊的
   • 通過挖掘、假設、取捨，搞清楚具體需求
   • 這本身就是在考察溝通能力、分析能力

2. 從最簡單的方案做起

   • 不要一上來就搞太複雜
   • 不要為了設計而設計

3. 再講如何最佳化

   • 基於某某設計模式，進一步對程式碼解耦
   • 提高程式碼擴展性
   • 體現程式碼演進思維

重要提醒：

• 多問多溝通，不要覺得問多了會被認為理解能力不夠
• 面試官不會反感，反而覺得你思路開闊、有想法
• 只是悶頭寫程式碼，可能會被認為不善溝通

如何處理爛業務程式碼#

接手爛程式碼的方法#

要想接手一個業務系統，前提是要讀懂程式碼，而讀懂程式碼的關鍵是要熟悉業務。

爛程式碼的共性特點：

• 維護了兩三年甚至五六年
• 程式碼量大（十幾萬行以上）
• 沒有注釋、沒有文檔
• 充斥臨時解決方案（Workaround）、硬編碼（Hard Code）、遺留程式碼
• 有些「反人類」設計或「故意挖坑」

接手策略：

1. 只要業務搞清楚，程式碼只不過是對業務的翻譯
2. 對於零文檔的項目，通過閱讀程式碼反推業務功能
3. 對於各種坑，必要時詢問前輩
4. 重要：把讀懂的每個業務都寫到文檔中

在讀程式碼的過程中重視知識的文檔化。這是對公司和團隊來說最有價值的部分，之後新同事看了你的文檔，就能很快上手。

在爛程式碼中成長#

正確心態：

• 接手爛程式碼，雖然過程痛苦，但會有更多施展才華的空間、鍛鍊技術的機會
• 業務開發的難度不亞於底層開發
• 做好業務開發同樣可以積累技術、鍛鍊能力

業務系統的開發難度來自兩方面：

如果你的項目：

• 效能要求高、業務也複雜 → 恭喜你，好好幹
• 只兼具其中一點 → 也不錯，值得一做
• 既沒效能壓力、業務也不複雜 → 走著瞧，實在不行再跳槽

Google 的人才培養#

職涯規劃建議#

短期目標（1-3 年）#

• 打好技術基礎
• 積累項目經驗
• 建立個人品牌（技術博客、開源貢獻）

中期目標（3-5 年）#

• 在某個技術領域建立專長
• 或在某個業務領域深耕
• 提升軟技能
• 考慮職業方向（技術專家 vs 管理路線）

長期目標（5 年以上）#

• 形成不可替代的競爭壁壘
• 技術影響力或業務影響力
• 平衡技術深度與廣度
• 持續學習，與時俱進

25~35 歲是每個人最寶貴的時光，應該用在刀刃上。 把時間投資在主流、高級、有挑戰性的技術上，保持技術和技能的領先，保持對技術本質和趨勢的敏感度。