結論先講
Junior 和 Senior 的差距不是年資，不是會用幾個框架，不是 GitHub 上有幾顆星。是面對問題時的思考方式和行為模式。
我看過工作一年就展現 Senior 思維的人，也看過工作五年還是 Junior 思維的人。差別在哪？這篇用六個維度來拆解。
每個維度你都可以對照自己目前的狀態，看看哪些地方可以刻意練習。
1. 怎麼面對 Bug：症狀 vs 根因
Junior 的做法
- 看到 bug → 慌
- 改一行跑一次
- 好了！交差
- 三天後同樣的 bug 又出現了，因為你只治了症狀
典型對話：
「我修好了，原本那個值是 null，我加了一個
if (value !== null)就不會報錯了。」「但是為什麼那個值是 null？」
「…我沒有看。」
Senior 的做法
- 看到 bug → 先重現
- 確認影響範圍（只有這裡會壞嗎？）
- 找根因（為什麼這個值是 null？上游是什麼？）
- 修根因
- 加測試確保不會復發
- 檢查有沒有類似的地方可能有同樣問題
| 面向 | Junior | Senior |
|---|---|---|
| 第一反應 | 怎麼讓它不報錯 | 為什麼會報錯 |
| 修復目標 | 這個 bug 消失 | 這類 bug 不再發生 |
| 驗證方式 | 手動跑一次 | 加自動化測試 |
| 影響評估 | 只看出問題的地方 | 檢查類似的 pattern |
| 事後處理 | 修完就忘了 | 記錄下來，分享給團隊 |
真實案例：某 API 偶爾回傳空陣列。Junior 的修法是「如果空陣列就顯示 loading」。Senior 追查發現是 cache TTL 設定不當，在 cache 過期到重新填充的空窗期會回傳空結果。修了 cache 策略後問題根治。
2. 怎麼看需求：字面 vs 質疑
Junior 的做法
PM 說：「幫我加一個按鈕，點了以後把資料匯出成 CSV。」
Junior：「好。」然後開始寫。
Senior 的做法
Senior：「可以多問幾個問題嗎？」
- 匯出的資料量大概多大？（如果幾百萬行，前端產生 CSV 會當掉）
- 誰會用這個功能？（只有管理員？還是所有用戶？權限呢？）
- CSV 的格式有規範嗎？（編碼？分隔符？欄位順序？）
- 多久匯出一次？（如果頻繁，要不要做排程下載？）
- 有沒有期限？（影響要做到多完整）
| 面向 | Junior | Senior |
|---|---|---|
| 接到需求 | 直接做 | 先理解「為什麼」要做 |
| 問問題 | 怕問太多顯得笨 | 知道問對問題比寫 code 重要 |
| 邊界情況 | 做完才想到 | 開始做之前就提出 |
| 需求變更 | 抱怨 PM 一直改 | 理解需求本來就會變，設計時留彈性 |
| 推回不合理的需求 | 不敢 | 用數據和事實說明 trade-off |
Senior 的思維不是「多問問題」這麼簡單。 是能從需求看到背後的業務目標，然後判斷這個需求是不是解決問題的最佳方式。有時候 PM 說要 A，但他真正需要的其實是 B。
3. 怎麼寫 Code：能跑 vs 能維護
Junior 的 code
def process(data):
result = []
for item in data:
if item['type'] == 'A':
if item['status'] == 'active':
if item['amount'] > 100:
result.append({
'name': item['name'],
'total': item['amount'] * 1.1
})
return resultSenior 的 code
TAX_RATE = 0.1
MINIMUM_AMOUNT = 100
def is_eligible_for_processing(item: dict) -> bool:
return (
item['type'] == 'A'
and item['status'] == 'active'
and item['amount'] > MINIMUM_AMOUNT
)
def calculate_total_with_tax(amount: float) -> float:
return amount * (1 + TAX_RATE)
def process_active_items(items: list[dict]) -> list[dict]:
return [
{
'name': item['name'],
'total': calculate_total_with_tax(item['amount'])
}
for item in items
if is_eligible_for_processing(item)
]差別不只是「看起來比較整齊」：
| 面向 | Junior 的 code | Senior 的 code |
|---|---|---|
| 可讀性 | 需要仔細讀才知道在幹嘛 | 函數名就說明了意圖 |
| 可維護性 | 改一個條件要找很久 | 改一個條件改一個地方 |
| 可測試性 | 只能整個測 | 每個函數可以獨立測試 |
| Magic number | 1.1 和 100 是什麼？ | 常數命名，一目瞭然 |
| 型別 | 沒有 | 有 type hint |
但 Senior 也知道什麼時候不需要這樣寫。 如果是一次性的 script，Junior 的寫法可能更適合。Over-engineering 也是一種問題。
4. 怎麼面對未知：慌張 vs 系統化
遇到從來沒碰過的技術或問題時：
Junior 的反應
- 心裡想：「完了，我不會。」
- Google 搜尋，複製第一個 Stack Overflow 的答案
- 跑起來了 → 太好了
- 不跑 → 繼續 Google，換下一個答案試
- 三小時後還是不行 → 去問人，但說不清楚自己試了什麼
Senior 的反應
- 心裡想：「有趣，我不會，但我知道怎麼學。」
- 花 15 分鐘了解概念（官方文件、README）
- 找一個最小的範例跑起來
- 逐步加入自己的需求
- 如果卡住，能清楚描述問題和已經嘗試的方法
- 知道什麼時候該問人（不是三小時後）
| 面向 | Junior | Senior |
|---|---|---|
| 心態 | 怕被發現不會 | 不會是正常的，學就好了 |
| 搜尋 | 找答案 | 找理解 |
| 複製 code | 複製貼上，能跑就好 | 理解每一行在幹嘛再用 |
| 問人 | 太早問（沒自己試）或太晚問（卡太久） | 自己試到一定程度再問，帶著具體問題 |
| 學習方式 | 找教學影片看完 | 看文件 + 動手做 + 看 source code |
| 記錄 | 不記錄 | 寫下來，下次不用重新學 |
Senior 的秘密武器：知道問題的分類。
碰到新問題，Senior 會先想：「這跟我知道的什麼東西類似？」很多看起來新的問題，本質上跟之前解過的問題是同一類。這就是「經驗」的價值——不是記住答案，是建立模式庫。
5. 怎麼溝通：回報 vs 對齊
Junior 的溝通
Daily standup：「昨天做了 A，今天繼續做 B。」
被問進度：「差不多快好了。」（什麼叫差不多？什麼叫快？）
遇到問題：默默卡著，不好意思說。
Senior 的溝通
Daily standup：「A 完成了，PR 在 #123。B 今天會開始，預計兩天。有一個 blocker 是 C 的 API 還沒好，我跟他確認過預計明天完成，不影響我的 deadline。」
被問進度：「完成了 70%，剩下的是 X 和 Y，預計週三完成。如果 Z 的規格有變，可能要加一天。」
遇到問題：「我遇到了 X 問題，試了 A 和 B 都沒解決，我覺得可能是 C 的原因。你有什麼建議嗎？」
| 面向 | Junior | Senior |
|---|---|---|
| 進度報告 | 模糊（「差不多」） | 具體（完成百分比、預計時間、風險） |
| 求助 | 「不會」或「幫我」 | 「我試了 X、Y，我的假設是 Z，需要你的意見」 |
| 風險溝通 | 出事了才說 | 提早預警 |
| 跨團隊溝通 | 等別人來問 | 主動同步和對齊 |
| 會議中 | 沉默或只聽 | 提出觀點、問好問題 |
| 寫文字 | 口語化、沒重點 | 結構化、有 context |
主動對齊（Proactive Alignment）是 Senior 最重要的溝通技能。
不是等到問題發生才溝通，是在問題可能發生之前就先對齊期望。比如：
- 「這個需求我理解是 X，如果我理解錯了請告訴我。」
- 「這個 feature 有兩種做法，我傾向 A，因為…你怎麼看？」
- 「下週五的 deadline 有風險，因為 X。我建議先砍 Y scope。」
6. 怎麼估時間：永遠低估 vs 留 Buffer
Junior 的估時
「這個功能？大概兩天吧。」
結果：
- 第一天：主要功能做完了
- 第二天：發現邊界情況沒處理
- 第三天：QA 回報 bug
- 第四天：修 bug，又發現另一個問題
- 第五天：終於好了（比預估多了 150%）
Senior 的估時
「讓我想一下…」
- 主要功能：1.5 天
- 邊界情況和錯誤處理：0.5 天
- 測試：0.5 天
- Code review 修改：0.5 天
- 「我沒想到的事情」buffer：0.5 天
- 總計：3.5 天
結果通常是 3-4 天完成，偶爾提前。
| 面向 | Junior | Senior |
|---|---|---|
| 估的是什麼 | 「寫 code 要多久」 | 「整個功能從開始到 merge 要多久」 |
| 邊界情況 | 沒想到 | 列出來並估進去 |
| buffer | 不敢加 | 合理的 buffer 是專業表現 |
| 信心 | 「應該可以」 | 「80% 的信心可以在 X 天內完成」 |
| 超時處理 | 默默加班 | 提早通知並調整計畫 |
估時的訣竅：
- 把任務拆小，分別估，再加總
- 乘以 1.5-2 倍（認真的，這不是偷懶）
- 分清楚「開發時間」和「calendar 時間」（你不是每天八小時都在寫 code）
- 不確定的部分先做 spike（花半天研究），再估剩下的
- 記錄自己的估時和實際時間，校準自己的估時準度
一張總表：你在哪個階段？
| 維度 | Junior | Mid-level | Senior |
|---|---|---|---|
| 面對 Bug | 改到不報錯 | 找到根因 | 防止再犯 + 檢查類似問題 |
| 看需求 | 照做 | 會問一些問題 | 質疑假設、提出替代方案 |
| 寫 Code | 能跑 | 可讀 | 可維護、可擴展 |
| 面對未知 | 慌 | 能自己 Google 解決 | 系統化學習、建立模式庫 |
| 溝通 | 被動回報 | 主動更新 | 主動對齊和影響決策 |
| 估時 | 永遠低估 | 有時準確 | 有系統地估，留合理 buffer |
| 影響力 | 自己的 task | 自己負責的功能 | 團隊的技術方向 |
**重要提醒：**這不是「Junior 不好，Senior 才好」。每個人都是從 Junior 開始的。重點是知道方向在哪，然後刻意練習。
而且不是所有面向都要同時到 Senior 水準。你可能在 debugging 已經是 Senior 思維，但在溝通上還是 Junior。這很正常。挑一兩個你最弱的面向，先集中改善。
FAQ
Q1: 工作幾年才算 Senior？
沒有標準答案。有些公司兩年就給 Senior title，有些公司五年才能。重要的不是 title，是你解決問題的方式。如果你工作三年但展現上面 Senior 欄位描述的行為，你就是 Senior 等級。
Q2: 我是 Junior，怎麼加速成長？
三個建議：(1) 找一個你尊敬的 Senior 工程師，觀察他怎麼工作；(2) 每次修 bug 都多追一層「為什麼」；(3) 每次估時結束後回顧實際花了多久，調整自己的估時方式。成長最快的方式是刻意練習，不是純粹累積年資。
Q3: Senior 就不需要再成長了嗎？
當然不是。Senior 之後有 Staff、Principal、Distinguished 等級。成長方向從「個人技術能力」轉向「技術影響力」和「解決更大問題的能力」。而且技術一直在變，不持續學習就會被淘汰。
Q4: 我的主管不是好的 Senior，怎麼辦？
向外學。看 tech blog（Netflix Engineering、Uber Engineering）、聽 podcast、參加社群活動、讀開源專案的 code 和 PR discussion。好的學習對象不一定要在你公司裡。
Q5: 面試時怎麼展現 Senior 的思維？
面試官問技術問題時，不要只回答「怎麼做」。加上「為什麼選這個方案」、「有什麼 trade-off」、「如果規模變大會怎麼調整」。遇到不會的問題，展示你的思考過程比背出答案更重要。
系列導航
- [01] 好的前端工程師需要什麼能力？
- [02] 好的後端工程師需要什麼能力？
- [03] DevOps 工程師需要什麼能力？
- [04] 好的全端工程師：廣度和深度怎麼平衡？
- [05] 好的 Tech Lead 需要什麼？
- [06] Junior 和 Senior 的真正差距 ← 你在這裡