頂尖科技公司的面試核心是演算法解題題：評估你解決從未見過的問題的能力。一場 45 分鐘往往只解一道題，全程要大聲思考。面試官跳進來給提示是正常的，不代表你表現差。
評估的五個面向#
面試官不照量化評分表，而是綜合整體印象：
- 分析能力 — 需要多少協助？解法夠不夠優化？能否權衡不同決策？
- 程式能力 — 能否正確轉成程式碼？是否整潔、考慮錯誤？
- CS 基礎 — 是否具備扎實的資料結構與演算法知識？
- 經驗 — 是否做過好的技術決策、有挑戰性的專案？
- 溝通與文化契合 — 表達是否清楚？個性是否合適？
評分是相對的：面試官拿你和被問過同一題的其他人比較。拿到難題不要慌——對你難，對別人也一樣難。難易度本身不影響你的相對表現。
七步解題流程#
flowchart LR
L[聆聽] --> E[畫例子] --> B[暴力解]
B --> O[最佳化] --> W[走一遍] --> I[實作] --> T[測試]
style B fill:#fff3e0,stroke:#ef6c00
style O fill:#e3f2fd,stroke:#1565c0
style T fill:#e8f5e9,stroke:#2e7d32- 仔細聆聽 — 記住題目所有獨特資訊。「兩個已排序陣列」「在伺服器上重複執行」這些線索往往是最優解的關鍵。
- 畫一個好例子 — 具體（用真實數字）、夠大（比直覺多 50%）、不是特殊情況。
- 說出暴力解 — 別跳過，即使很明顯。說明其時間／空間複雜度，再談改進。
- 最佳化 — 見下方技巧。
- 走一遍 — 確定最優解後先別寫程式碼，完整走過演算法，確認每個細節。
- 實作 — 從白板左上角開始，寫出正確、高效、簡單、易讀、可維護的程式碼。
- 測試 — 概念測試 → 注意可疑行（如
length - 2）→ 熱點（遞迴 base case、整數除法、null 節點）→ 小測試案例 → 特殊情況。
好工程師不假設輸入合法。若錯誤檢查很繁瑣，可以說「我會在這裡寫這些檢查」並留空間，先完成主要邏輯。
最佳化技巧#
Look for BUD#
最有用的最佳化框架，找三種浪費：
- Bottlenecks（瓶頸）：拖慢整體的部分。例如「搜尋」是瓶頸 → 用 hash table 把 O(N) 搜尋變 O(1)。
- Unnecessary Work（不必要的工作）：可省略的計算，例如把最內層迴圈用公式直接算出。
- Duplicated Work（重複的工作）：反覆計算相同東西 → 預先算好放進 hash map 查表。
其他技巧#
| 技巧 | 做法 |
|---|---|
| DIY | 把問題想成真實例子，直覺手動解，再逆向工程成演算法 |
| Simplify & Generalize | 先簡化限制（string→character）解出，再推廣回去 |
| Base Case and Build | 解 n=1，從 n-1 推 n，常自然導向遞迴 |
| 資料結構腦力激盪 | 逐一套用各種資料結構，看哪種最合適 |
「追蹤隨機數的中位數」用兩個 heap（一個 max-heap 管小半、一個 min-heap 管大半）最棒。做的題越多，選對資料結構的直覺越準。
最佳可想像執行時間（BCR）#
BCR 是你能合理想像的最快解法，描述任何演算法都無法突破的理論下界（找兩個陣列共同元素的 BCR 是 O(A+B)，因為至少要看過每個元素一次）。
BCR 與 Best Case Runtime 完全不同。BCR 針對「問題」，Best Case 針對「特定演算法」且幾乎沒用。
用途：告訴你還有多少優化空間（已達 BCR 就轉攻空間複雜度）；提示要消除什麼因子（BCR 是 O(N) 但你是 O(N log N) → 要幹掉那個 log N）；BCR 以內的工作都是「免費的」。
面對錯誤與卡關#
面試最危險的謠言是「每題都要全對」。其實評估是綜合的：解法多優、花多久、需多少提示、程式碼多乾淨——而且是相對比較。拿到 offer 的人也幾乎都犯過錯。
- 聽過這題 → 誠實告訴面試官。否則剝奪了他評估你的機會，被發現還扣誠信分；承認反而加分。
- 語言選擇 → 選你最熟悉的。熟悉度比語言特性重要；若可選，普及、易讀的語言（Java／Python／C++）讓面試官好懂。
- 卡住 → 對解難題表現出興奮感會加分。面試在測：面對困難你是迎難而上還是退縮？
從公司角度，false positive（誤招）比 false negative（漏掉好人）更可怕，所以面試刻意設計得寧可漏掉好人。被拒不代表你不是好工程師——很多優秀工程師只是不擅長這種測驗。多數公司樂於重新面試被拒者（通常等 6 個月到 1 年）。