工程師的職涯不是一條直線,而是一棵分支樹。Junior 到 Senior 靠的是技術深度 + 解決問題的能力,Senior 之後分成「技術專家」和「管理」兩條路。每個階段需要的能力不一樣,卡關的原因也不一樣。這篇把 career、project-mgmt、process 三個系列的文章按職涯階段串起來。

你不需要每條路都走——但你需要知道有哪些路可以走。


Level 0:全景圖

flowchart TD
    J[Junior Engineer] --> M[Mid-level Engineer]
    M --> S[Senior Engineer]
    S --> TL{選方向}
    TL -->|管理| LEAD[Tech Lead]
    TL -->|技術| EXPERT[技術專家]
    LEAD --> EM[Engineering Manager ⚠️ 待寫]
    LEAD --> PM_PATH[轉 PM]
    EXPERT --> ARCH[Architect]
    EXPERT --> IC[Staff / Principal]

    style J fill:#e3f2fd,stroke:#1976d2
    style M fill:#e3f2fd,stroke:#1976d2
    style S fill:#e8f5e9,stroke:#388e3c
    style TL fill:#ede7f6,stroke:#5e35b1
    style LEAD fill:#fff3e0,stroke:#f57c00
    style EXPERT fill:#f3e5f5,stroke:#8e24aa
    style EM fill:#fff3e0,stroke:#f57c00
    style ARCH fill:#f3e5f5,stroke:#8e24aa
    style IC fill:#f3e5f5,stroke:#8e24aa
    style PM_PATH fill:#fce4ec,stroke:#c62828

Junior → Mid → Senior 是共同的路,到 Senior 後分成管理(Tech Lead → EM)和技術(Architect / Staff IC)兩條路。這個選擇沒有對錯,只有適不適合你。


Level 1:Junior → Mid-level(0-3 年)

這個階段的核心是「能獨立完成任務」。從需要人帶,到能自己解決問題,到能把問題解決得漂亮。

技術基礎 — 把基本功練好,不是什麼都會,而是「會的東西真的會」。 → 好的前端工程師:前端該精通什麼 → 好的後端工程師:後端該精通什麼 → Junior vs Senior:真正的差距在哪

工作方法 — 不只是寫程式,還有 Git、Code Review、測試。 → Commit Lint:好的 commit message 習慣 → 測試策略:Unit Test、Integration Test、E2E → Code Review:怎麼做有效的 review → Code Review(二):reviewer 和 author 的注意事項

Debug 能力 — Junior 跟 Mid 最大的差距之一。 → Debug 方法論:系統化除錯 → Debug 方法論(二)Debug 方法論(三)Debug 方法論(四)


Level 1:Mid → Senior(3-6 年)

技術不再是瓶頸——瓶頸變成了「影響力」。Senior 不只解決自己的問題,還要能幫團隊解決問題。

系統思維 — 不只看程式碼,要看整個系統。 → 好的 Infra 工程師:基礎設施的全貌 → 好的全端工程師:能連結前後端的思維 → IT 角色演變:軟體業的各種角色和它們的關係

架構能力 — Senior 要能做技術決策,不是只執行別人的決策。 → 系統規劃(一):從需求到架構 → 系統規劃(二)系統規劃(三)取捨框架:怎麼在技術選項間做決定 → 技術債:什麼時候該還、什麼時候可以欠 → 理解新 Codebase:快速上手陌生專案

流程改善 — Senior 要能改善團隊的開發流程。 → 環境規劃:開發 / Staging / Production 的分層 → Release 方法論:怎麼安全地發布 → Feature Lifecycle:一個功能從需求到上線的全流程


Level 1:Senior → Tech Lead

Tech Lead 不是「最強的工程師」,而是「讓團隊發揮最大效能的人」。寫程式的時間會大幅減少,取而代之的是決策、溝通、mentoring。

好的 Tech Lead:角色定位和必備能力

專案管理能力 — Tech Lead 需要的不是「管理」,是「讓事情發生」。 → 需求拆解:Epic → Story → Task → 工時估算:Story Points、歷史速率 → Agile 實務:Scrum 和 Kanban 的實際操作 → Backlog 優先排序:RICE、MoSCoW 框架 → Sprint 規劃:怎麼規劃一個兩週的 Sprint → 進度追蹤:Burndown Chart、風險指標 → Stakeholder 溝通:向上管理、期望管理 → Postmortem & Retro:事後檢討和持續改進

技術決策 — 不只是「我們用什麼框架」,是「為什麼用這個、不用那個」。 → API 設計:團隊層級的 API 規範 → CD Pipeline好的監控系統好的 DX(開發者體驗)Monorepo vs Multi-repo:專案結構的取捨 → 事故管理:出事了怎麼辦 → SDD:測試驅動的開發策略


Level 1:其他路徑

不是只有 Tech Lead 一條路。

技術專家 / Staff Engineer — 繼續深耕技術,影響力來自技術深度和跨團隊的架構設計。 → 系統分析與設計UML:用圖說話 → ⚠️ 待寫:Staff Engineer 角色定位(跟 Senior 和 Architect 的差異)

轉 PM — 從技術到產品。 → 產品定義:從使用者需求到 PRD → 專案管理職涯指南 → ⚠️ 待寫:工程師轉 PM 的實戰經驗


每個階段的關鍵能力

階段技術能力軟實力常見瓶頸
Junior能寫能跑的程式碼Google 和問問題不敢問問題、不會 debug
Mid好維護的程式碼Code Review、文件只在舒適圈、不碰新東西
Senior系統設計、技術決策跨團隊溝通、mentor只深不廣、不懂業務
Tech Lead架構把關、技術方向團隊管理、向上管理放不下程式碼、不會委派

閱讀路徑

Junior(剛入行)

Junior vs Senior 看差距在哪,然後專注在 Debug 方法論Commit Lint。技術面先選前端或後端深入。

Mid-level(想升 Senior)

取捨框架 學做技術決策,看 Code Review 提升影響力。開始關注系統設計:系統規劃

Senior(考慮要不要當 Tech Lead)

先看 好的 Tech Lead 確認這是你要的。然後看 Stakeholder 溝通需求拆解——這兩個是 Tech Lead 日常最花時間的事。


知識缺口

缺口為什麼重要建議放在哪
⚠️ Staff Engineer 角色Senior 之後的技術路線缺少具體描述career/
⚠️ 薪資談判每次換工作都需要,但很少人教career/
⚠️ 面試準備(系統設計)Senior 面試必考,目前只有零散的系統設計文章career/ 或 system-design/
⚠️ 管理者的技術退化當 Lead 後技術跟不上的焦慮怎麼處理career/
⚠️ 遠端工作海外遠端的工作模式和挑戰career/
⚠️ 工程師的倦怠Burnout 的預防和恢復career/

FAQ

Q: 寫程式可以寫到幾歲? A: 沒有年齡限制。矽谷有大量 50+ 歲的 Staff Engineer 和 Principal Engineer。台灣的問題不是年齡,是市場對資深工程師的需求結構——管理職缺多、純技術高階職缺少。關鍵是你能提供的價值,不是你的年紀。

Q: PM 跟工程師哪個好? A: 看你享受什麼。喜歡解決技術問題、看到程式跑起來的成就感 → 工程師。喜歡理解使用者需求、協調不同部門、看到產品被使用 → PM。薪資在同級別差異不大。詳見 PM 職涯指南

Q: 怎麼談薪水? A: 三個原則:(1)先調查市場行情(levels.fyi、薪資比較網站);(2)用你的成果說話,不是用年資;(3)談的是整包(base + bonus + RSU + 福利),不是只看月薪。⚠️ 薪資談判的深入文章待寫。

Q: 全端工程師值得當嗎? A: 在小團隊(< 10 人)或新創,全端非常有價值。在大公司,通常會偏向前端或後端的某一邊。全端的風險是「什麼都會一點,什麼都不精」。建議先精一個方向,再往另一邊擴展。詳見 好的全端工程師

Q: Tech Lead 一天在做什麼? A: 大約 30% code review + 技術決策、30% 開會(需求討論、Sprint planning、1-on-1)、20% 寫文件和做架構設計、20% 自己寫程式碼。寫程式的比例會隨團隊大小而變——團隊越大,自己寫得越少。詳見 好的 Tech Lead

Q: 要不要讀資工碩士? A: 如果你想進大公司(FAANG、台灣的科技業大廠),碩士有幫助。如果你想進新創或中小企業,作品集和實際經驗更重要。碩士最大的價值不是學歷本身,而是你在研究所培養的「研究問題的能力」。