I. The Interview Process • 破解程式面試

概述#

在大多數頂尖科技公司（以及許多其他公司），演算法與程式碼題目是面試的最大組成部分。這類問題本質上是解題問題，考官評估的是你解決從未見過的演算法問題的能力。

一場面試通常只有 45 分鐘，往往只能處理一道題目。你應該全程大聲思考，說明你的解題過程。面試官可能會跳進來給予提示，這是正常的，不代表你表現不佳。

面試結束後，面試官不會依照量化評分表打分，而是根據整體印象做出評估，通常涵蓋以下幾個面向：

Analytical skills（分析能力）：解題需要多少協助？解法是否夠優化？是否能良好地架構問題並思考不同決策的取捨？
Coding skills（程式能力）：能否將演算法正確轉化為程式碼？程式碼是否整潔、有條理？有沒有考慮到潛在錯誤？是否有良好的程式風格？
Technical knowledge / Computer Science fundamentals（技術知識與 CS 基礎）：是否具備扎實的電腦科學基礎與相關技術知識？
Experience（經驗）：過去是否做過良好的技術決策？是否建構過有趣、有挑戰性的專案？是否展現主動性與驅動力？
Culture fit / Communication skills（文化契合度與溝通能力）：個性與價值觀是否適合公司與團隊？與面試官的溝通是否良好？

各項目的比重會因題目類型、面試官、職位、團隊與公司而有所不同。在標準演算法題中，前三項的比重通常最高。

這是許多候選人最常提出的問題：「為什麼要用這種方式面試？」

常見的批評包括：

作者坦承這些批評並非全無道理，但也說明了為何這種方式仍存在一定合理性：

從公司角度來看，False positive（誤招不好的人）比 false negative（漏掉好人）更令人擔憂。公司的目標是招募一批優秀員工，即使漏掉部分好人才，仍是可接受的取捨——只要能確保招進來的人是真的好。

能夠獨立突破數道困難題目，代表你很可能是個善於推導最佳演算法的聰明人。聰明人通常能在公司發揮很大的價值。

樹、圖、串列、排序等知識在工作中確實會定期出現。此外，熟悉這些知識也是**「曾認真學習電腦科學」的一個代理指標（proxy）**，顯示候選人具備一定廣度的技術素養。

還有另一個原因：要出一道不涉及這些基礎的解題題目其實很困難。大部分的問題多少都會用到這些基礎，久而久之就形成了固定的出題模式。

白板上你不需要寫出完整的 class 定義與 boilerplate 程式碼，你可以直接聚焦在題目核心的邏輯。面試官也不預期你的程式碼零錯誤——幾乎所有人都會有些小 bug 或語法錯誤。

此外，白板鼓勵候選人開口說話、解釋思路；而有電腦時，溝通往往大幅減少。

這種面試方式並不適用於所有公司或所有職位。它無法衡量工作態度或專注力，也對於倚重特定技術或先前經驗的職位不夠公平。這不是完美的流程，但所有面試流程都有各自的缺點。

「某公司最近在問什麼題目？」這個問題本身就反映了對面試題目來源的誤解。

在絕大多數公司，沒有一份統一的「指定題目清單」。每位面試官自行選擇自己想問的題目。

因此，所謂的「最近 Google 面試題」，不過是「某位恰好在 Google 工作的面試官最近問了這道題」。Google 今年問的題目與三年前差異不大，和 Amazon、Facebook 等類似公司也差別不大。

各公司之間確實存在一些宏觀差異：

但在同一類型的問題中，題目幾乎沒有「歸屬」於某家特定公司的特徵。一道 Google 的演算法題，本質上和一道 Facebook 的演算法題是一樣的。

如果沒有固定的評分標準，面試官如何評估你的表現？

答案是：相對比較（relative comparison）。

面試官評估你時，是拿你與其他曾被同一位面試官問過同一道題的候選人做比較。這是一種相對性的判斷，而非絕對標準。

如果你拿到了一道很難的題目，不要慌。因為對你難，對其他人也一樣難。題目的難易度本身不影響你的相對表現。

不一定。公司回覆延遲有很多原因，最常見的是某位面試官還沒提交意見。絕大多數公司不會對拒絕的人不回覆作為政策。

幾乎都可以，但通常需要等一段時間（6 個月到 1 年）。第一次面試失敗通常不會對之後的申請造成太大影響。許多人曾被 Google 或 Microsoft 拒絕，後來仍成功獲得 offer。