技術面試準備 2026｜工程師白板、系統設計、live coding
我們檢視 2024 台灣科技公司（TSMC、聯發科、Google Taiwan、Microsoft、AWS、Trend Micro）+ 海外 FAANG 對工程師的面試流程，加上 LeetCode 通過率與 offer 率的對比。「FAANG-tier 面試的 LeetCode 部分需要練 200-400 題、系統設計需要 4-8 週準備——這個時間投入大多數工程師低估」是面試學的核心發現。
工程師面試跟其他職位差很大。除了行為面試 + 經歷詢問，多了「技術評估」這個獨立關卡：白板演算法、live coding、系統設計、技術深度問答。對台灣 FAANG-tier 工程師面試，技術部分是 60-70% 的評分，準備量是其他職位的 3-5 倍。這篇用 2026 的實際面試流程，拆解技術面試的具體準備方法。
技術面試的類型
不同公司、不同職位的技術面試組成不同。
| 類型 |
內容 |
適用 |
| 線上 OA（Online Assessment） |
1-3 小時做題（LeetCode-style） |
大公司初步篩選 |
| 電話面試 + live coding |
45-60 分鐘解 1-2 題 |
跨國公司中段 |
| 白板演算法 |
紙筆 / 線上白板解題 |
FAANG 經典 |
| 系統設計 |
設計一個系統的高層架構 |
mid-senior 以上必考 |
| 程式碼審查 |
審查一段已寫好的程式碼 |
部分公司 |
| Take-home project |
給 1-7 天做完整專案 |
部分公司 |
| 工作 deep dive |
深入問你做過的專案 |
senior+ |
| 行為面試 |
跨職位的標準 |
所有技術職位 |
各公司類型的面試流程
| 公司類型 |
典型流程 |
| FAANG（在台分公司） |
OA → 1 場電話 → 4-6 場 onsite |
| 大型科技（TSMC、聯發科） |
履歷篩 → 主管面 → 技術面（2-3 場） |
| 新創獨角獸 |
履歷 → CEO/CTO + 技術面 + 文化面 |
| 中型 SaaS |
履歷 → 線上電面 → onsite 2-3 場 |
| 本土軟體公司 |
履歷 → HR + 主管 + 技術 |
| 顧問業 |
履歷 → case + behavioral |
FAANG-tier 流程 4-8 週，本土 1-3 週。準備時間應該對應流程長度。
LeetCode 準備
LeetCode 是技術面試的「考古題」資料庫。
題目分類
| 類型 |
題數比例（FAANG） |
| 陣列 / 字串 |
20-25% |
| 動態規劃 |
15-20% |
| 樹 / 圖 |
15-20% |
| 雜湊表 / 字典 |
10-15% |
| 排序 / 搜尋 |
10-15% |
| 設計題 |
5-10% |
| 數學 / 邏輯 |
5-10% |
| Bit manipulation |
5% |
| 其他 |
餘 |
題數目標
| 目標公司 |
LeetCode 題數 |
| FAANG |
200-400 |
| 跨國公司 Taiwan |
100-200 |
| 大型本土科技 |
80-150 |
| 中小型科技 |
50-100 |
| 新創 |
30-80 |
練習策略
| 階段 |
行動 |
| 第 1-2 週 |
Easy 題 50 題，掌握基本資料結構 |
| 第 3-4 週 |
Medium 題 50 題 |
| 第 5-6 週 |
Medium 題 80-100 題 |
| 第 7-8 週 |
Hard 題 + 弱項補強 |
| 面試前 1 週 |
重做難題 + mock interview |
練習方法
| 方法 |
細節 |
| 設 25-45 分鐘時限 |
模擬面試節奏 |
| 寫紙筆 / 白板 |
模擬白板面試 |
| 大聲說出思路 |
模擬講解 |
| 看不出 → hint → 自己嘗試 → 看解答 → 重做 |
標準流程 |
| 重做 1-3 次 |
直到流暢 |
| 標籤分類 |
找弱項 |
| Mock interview（Pramp、Interviewing.io） |
真實演練 |
系統設計
Senior+ 工程師必考。設計一個大型系統的高層架構。
常見系統設計題目
| 題目 |
重點 |
| 設計 URL shortener（bit.ly） |
雜湊、分散式、快取 |
| 設計 Twitter / Instagram |
News feed、Push vs Pull |
| 設計 Uber / Lyft |
地理位置、即時 |
| 設計 Whatsapp / 聊天系統 |
即時通訊、訊息儲存 |
| 設計 YouTube / Netflix |
影片串流、CDN |
| 設計 Search engine |
索引、爬蟲、ranking |
| 設計 Recommendation system |
機器學習、個人化 |
| 設計 Distributed cache |
Redis-style |
| 設計 Rate limiter |
速率限制 |
| 設計 Notification system |
推送、批次 |
系統設計面試結構
| 階段 |
時間 |
| 1. 釐清需求 |
5-10 分鐘 |
| 2. High-level design |
10-15 分鐘 |
| 3. Deep dive 1-2 components |
15-20 分鐘 |
| 4. 規模 / scaling |
5-10 分鐘 |
| 5. 邊角情況 + 改進 |
5-10 分鐘 |
系統設計面試 45-60 分鐘，重點是「思考過程」而非「最終答案」。
準備資源
| 資源 |
用途 |
| 《Designing Data-Intensive Applications》 |
基礎 |
| System Design Primer (GitHub) |
免費，全面 |
| Grokking the System Design Interview |
付費，題目集 |
| ByteByteGo |
付費，視覺化好 |
| YouTube：Hussein Nasser、Tech Dummies |
免費影片 |
系統設計的常見錯誤
| 錯誤 |
為什麼錯 |
| 直接畫圖不釐清需求 |
設計可能完全偏離 |
| 沒考慮規模（DAU、QPS） |
不專業 |
| 全用最新技術（炫技） |
不必要 |
| 忽略 trade-off |
工程沒這麼絕對 |
| 不討論瓶頸 / failure mode |
沒系統思維 |
Live Coding
即時解題 + 寫程式 + 解釋。
Live coding 的評分維度
| 維度 |
細節 |
| 釐清題目 |
確認需求 / 邊角 |
| 思路 |
跟面試官溝通 |
| 程式碼正確性 |
寫得對 |
| 程式碼品質 |
命名 / 結構 / 可讀 |
| 時間 / 空間複雜度 |
分析正確 |
| 處理邊角 |
edge cases |
| 測試 |
用例驗證 |
| 反應 |
提示後能改進 |
Live coding 的應對
| 步驟 |
細節 |
| 1. 重述題目 |
確認理解 |
| 2. 問釐清問題 |
「輸入範圍是？」「edge case 怎麼處理？」 |
| 3. 講思路（brute force → optimal） |
不要直接 jump 到最佳解 |
| 4. 寫程式（邊寫邊講） |
不要悶頭寫 |
| 5. 跑用例（含 edge） |
自己 trace |
| 6. 分析複雜度 |
Big-O |
| 7. 討論優化 |
如有時間 |
行為 + 技術混合：Project Deep Dive
Senior+ 面試常見：「介紹你做過最具挑戰的專案。」
Deep Dive 的結構
| 段 |
內容 |
時間 |
| 背景 |
公司、產品、為什麼需要 |
30 秒 |
| 你的角色 |
在團隊中的位置、責任 |
30 秒 |
| 技術挑戰 |
為什麼難 |
60 秒 |
| 你的決策 |
為什麼選 X 不選 Y（trade-off） |
90 秒 |
| 執行細節 |
寫了什麼 / 設計了什麼 |
60 秒 |
| 結果 + 學習 |
量化 + 反思 |
60 秒 |
Project Deep Dive 的常見追問
| 追問 |
回答方向 |
| 「為什麼用 X 而非 Y？」 |
Trade-off 思考 |
| 「如果再來一次怎麼做？」 |
反思 |
| 「規模再大 10 倍會遇到什麼？」 |
可擴展性 |
| 「failure mode？」 |
韌性思考 |
| 「你的個人貢獻？」 |
區分團隊 vs 你 |
處理「不會」
技術面試最大的陷阱：遇到不會的題目。
好的應對
| 反應 |
細節 |
| 「我先想 brute force」 |
不要急著找最佳 |
| 「能否提示 X 方向？」 |
主動求 hint |
| 「我會這樣分解問題...」 |
顯示思考流程 |
| 「這跟我做過的 X 類似，但有 Y 不同」 |
連結既有知識 |
| 「我先寫 brute force，再優化」 |
步驟化 |
| 誠實：「這個我不熟，能否解釋一下？」 |
在 senior 面試中是 OK 的 |
不好的應對
| 反應 |
為什麼錯 |
| 完全沉默 |
顯示卡住 |
| 「我不會」+ 放棄 |
不嘗試 |
| 隨便寫 |
沒思考 |
| 抱怨題目難 |
不專業 |
| 假裝會（亂寫一通） |
被看穿 |
不同職位的技術面試重點
| 職位 |
重點 |
| 前端工程師 |
JS / TS、React、瀏覽器知識、CSS、performance |
| 後端工程師 |
演算法、系統設計、資料庫、API design |
| 全端工程師 |
兩者基本，廣度 > 深度 |
| 資料工程師 |
SQL、ETL、分散式 |
| 機器學習工程師 |
ML 基礎 + 系統設計（ML systems） |
| DevOps / SRE |
系統 + 網路 + 自動化 |
| 行動端工程師 |
iOS / Android 平台知識 + 演算法 |
| 嵌入式 |
C / C++、低階知識、硬體 |
| 安全工程師 |
漏洞知識 + 系統思維 |
不適用此架構的情境
- 應屆 / 初階工程師：簡化的演算法 + 基本問答
- 純研發 / 學術職位：論文 + 研究方法
- 顧問 / SA（Solution Architect）：客戶 + 設計能力
- IT 維運 / 系統管理員：故障排除實作
- 銷售工程師：技術知識 + 業務能力
常見問題
LeetCode 200 題真的夠嗎？
看公司。FAANG 來說，200 題是「最低」，理想 300-500 題。本土科技公司 100-200 題夠。重點不是題數而是「熟練度」——一題重做 3 次比新做 3 題有用。
系統設計面試我沒做過大系統怎麼辦？
這是常見困境。應對：(1) 讀經典書（DDIA）累積 framework、(2) 看 YouTube 案例分析、(3) 用「假設我來設計」的口吻，講出思考過程而非「我做過」。HR 知道 mid-level 工程師多半沒實際做過大型系統。
面試官說「亂寫沒關係」是真的嗎？
不是。是說「不要因為怕錯而不寫」。實際評分時，程式碼品質、邊角處理、思考結構都會評。
Take-home project 該花多少時間？
題目通常說 X 小時，但實際完成需要 1.5-3X 時間。建議：先按 X 小時做（評估自己），再思考是否多投入時間做更完整。過度投入（10 小時做 3 小時題目）顯得「太閒」。
下一步行動
- 確認目標公司面試流程（OA / live coding / 系統設計 / take home）。
- 用本文「題數目標」表估算 LeetCode 需準備量。
- 列出 4-8 週的準備計畫。
- Mock interview 至少 3-5 次（Pramp、朋友、付費服務）。
- 面試前 1 週重點「弱項補強」+ 重溫故事庫。
延伸閱讀