技術能力只是入場門票。真正決定職場高度的，是技術、業務、能力三方面的複合競爭力，以及把這些優勢有效呈現出來的能力。
編程能力本身的內涵與練習方法，請見 技術成長。本章聚焦在「如何把能力轉化為職場競爭力」。
立命之本：技術、業務、能力#
不管哪個行業，混得好的人都要有兩把刷子。對於程式設計師來說，這「兩把刷子」包括技術、業務和能力三個方面。
技術競爭壁壘#
如何形成技術壁壘：
- 從事有技術難度、技術挑戰的職位
- 基礎架構、中介軟體、資料庫等偏底層開發
- 人工智慧演算法等入行門檻較高的細分領域
- 在一個細分技術領域長期、深入積累
- 別人無法在短期內超過你
業務競爭壁壘#
技術驅動的公司其實很少。 即便是 Google，90% 的專案都是業務、產品驅動的。高階技術只集中在少數專案中。
適合積累業務壁壘的領域：
- 金融系統
- 銀行系統
- 財務系統
- 清結算系統
- 物流系統
純靠技術通常只能晉升到資深工程師層級。要再往上（如技術主管、首席架構師），靠的不只是技術，還需要對某個業務的深入積累。很多主管之所以能帶團隊，不是技術強，而是對業務熟悉。
成事能力壁壘#
對於技術沒太大挑戰、業務也不複雜的專案，可以多積累成事能力、解決問題的能力。
成事能力包括：
- 分析總結能力
- 邏輯思維能力
- 溝通協調能力
- 自我驅動能力
比起固定的技術和業務知識，成事能力對於職場發展更加重要。職位越高，成事能力就越重要，畢竟企業最終看的是結果，而不是技術有多好。
入場門票：學歷、專案、履歷#
現實認知#
招募市場已從賣家市場變成買家市場。公司不僅加大面試難度，還會在學歷、過往經歷等方面先過濾一批候選人。
一般來說：
- 好學校的學生對計算機基礎知識掌握得更好
- 學習能力、邏輯思維更強
- 成績好的同學往往執行力和交付能力更強
透過學歷過濾候選人是高效的招募手段。公司不在乎因此漏掉一兩個優秀候選人，或誤招一兩個不優秀的人。
為履歷而工作#
如果說技術、業務、能力是立命之本，決定了你能不能在職場比賽中勝出，那麼學歷、專案、履歷就是入場門票，決定了你可以選擇哪個賽道。
建議：
- 學歷太低：考個好點的學歷
- 專案經驗：在公司內部努力選擇有技術含量的專案
- 履歷提升：跳槽去知名的網際網路公司
職場軟技能#
別把學生思維帶進職場#
職場不是學校。影響你向上發展的因素很多，不會只靠技術。
學校 vs 職場：
| 學校 | 職場 |
|---|---|
| 一份試卷見分曉 | 好壞難以客觀、量化評價 |
| 悶頭學就行 | 需要團隊合作 |
| 不需要向上管理 | 需要讓領導看到你的價值 |
技術好不等於貢獻多#
常見問題：
- 技術好的人容易自我陶醉，鑽研冷門艱深的技術
- 這些技術從短期或長期看，都沒給團隊、公司帶來收益
- 公司不會為沒有產生效益的付出買單
正確態度：
- 學會跟公司共同成長
- 你的成長要為公司的成長貢獻力量
- 為公司、為主管解決問題，才有升職加薪的機會
必要的軟技能#
想在職場走得遠，以下軟技能不能成為短板：
- 溝通能力
- 協作能力
- 總結彙報能力
- 向上管理能力
不是要你「耍手段」上位，而是別讓這些軟技能成為短板。不要讓非技術、非能力的因素，阻礙了職場發展。
面試技巧#
面試官的視角#
面試官如何評估候選人
經驗分享：
- 透過學歷、專案、履歷判斷候選人，比短短 1 小時的面試更可靠
- 特別是高階職位，好的學歷、專案、履歷有壓倒性優勢
- 基本上看完履歷，對是否符合招募要求心裡就有八九不離十的判斷
- 面試開始的前 10 分鐘，基本已經決定要不要錄用
- 後面的面試只是為了進一步證實剛剛的決定
設計模式面試#
面試官常見題型：
手寫設計模式：讓候選人手寫單例、工廠等
- 這種偏記憶的題目沒有區分度
- 候選人容易突擊準備
給需求寫程式碼：給一個功能需求，讓候選人設計和實現
- 討論程式碼的可讀性、擴展性等品質問題
- 讓候選人繼續最佳化
Code Review：給一段有問題的程式碼，讓候選人找問題並重構
不管是資深工程師、架構師，還是技術 Leader，只要應聘一線技術研發崗，都應該能現場寫一段程式碼。這是最直接、最有效檢驗基本技術素養的途徑。
候選人的回答策略#
面對需求類題目：
首先明確需求
- 大部分功能需求都是籠統、模糊的
- 透過挖掘、假設、取捨，釐清具體需求
- 這本身就是在考察溝通能力、分析能力
從最簡單的方案做起
- 不要一開始就把方案做得太複雜
- 不要為了設計而設計
再講如何最佳化
- 套用合適的設計模式，進一步對程式碼解耦
- 提高程式碼擴展性
- 體現程式碼演進思維
重要提醒：
- 多問多溝通，不要擔心問太多會讓面試官覺得你理解能力不夠
- 面試官不會反感，反而覺得你思路開闊、有想法
- 只是悶頭寫程式碼，反而可能被認為不善溝通
如何處理爛業務程式碼#
接手爛程式碼的方法#
要想接手一個業務系統，前提是要讀懂程式碼，而讀懂程式碼的關鍵是要熟悉業務。
爛程式碼的共通特徵：
- 維護了兩三年甚至五六年
- 程式碼量大（十幾萬行以上）
- 沒有註解、沒有文件
- 充斥臨時解決方案（Workaround）、寫死的常數（Hard Code）、遺留程式碼
- 有些反人類設計或故意留下的坑
接手策略：
- 只要釐清業務，程式碼只不過是業務邏輯的翻譯
- 對於沒有文件的專案，透過閱讀程式碼反推業務功能
- 遇到各種坑，必要時詢問前輩
- 重要：把讀懂的每個業務邏輯都寫到文件中
在讀程式碼的過程中重視知識的文件化。這對公司和團隊最有價值——之後新同事看了你的文件，就能很快上手。
在爛程式碼中成長#
正確心態：
- 接手爛程式碼，雖然過程痛苦，但會有更多施展才華的空間、鍛鍊技術的機會
- 業務開發的難度不亞於底層開發
- 做好業務開發同樣可以積累技術、鍛鍊能力
業務系統的開發難度來自兩方面：
| 挑戰 | 要求 |
|---|---|
| 高效能要求 | 架構能力、技術廣度、技術深度、使用經驗 |
| 業務複雜 | 業務建模能力、複雜邏輯抽象能力、程式碼翻譯能力 |
如果你的專案：
- 效能要求高、業務也複雜 → 恭喜你，好好做
- 只兼具其中一點 → 也不錯，值得一做
- 既沒效能壓力、業務也不複雜 → 觀察一陣子，真的沒成長空間就換工作
Google 的人才培養#
Google 讓人快速成長的機制
完整的培訓課程#
- 實體分享與線上錄播課程
- 新技術 DogFood、入門 101 教程、深度系列教程
- G2G（Googler to Googler）學習計畫
- 鼓勵員工自我學習，不反對占用上班時間進修
公開的文件和程式碼#
- 幾乎所有文件和程式碼都是公開的
- 可以隨意查看任何專案的設計文件和程式碼
- 帶著問題去學習：想實現某個功能時，搜索程式碼倉庫找參考
- 從高手程式碼中學習設計思路和實現技巧
清晰的成長路徑#
- 新人學習計畫：編碼規範、單元測試、Code Review、開發工具、行為準則
- 分配 Mentor（導師）
- 每半年制定 OKR，包含個人成長部分
- 主管協助制定升職計畫
- 鼓勵內部轉調，跳出舒適圈
頻繁的一對一溝通#
- 與 Leader 或 Manager 通常每一至兩週一次
- 聊工作、想法、困惑
- 即時反饋、即時指導
- 避免悶頭做事、累積不滿就突然離職的情況