如何準備工程師的面試
在我的職涯裡有無數次面試官與面試者的經驗。科技業的面試流程，大家都知道存在很多缺陷。這篇整理是希望能提供一些實戰的思考角度，盡可能提高你的勝率。
我以前也寫過各種面試心得，現在由於 AI 的出現已經有不少變化，像是不少公司會在面試時觀察面試者如何透過 AI 解決問題，而我也相信這會逐漸改變科技業面試的方向。
面試表現不等於你的能力
面試最讓人沮喪的一點，在於權力關係往往極度單向。作為應徵者，你很難摸清對方真正的標準，面試結束後也很容易陷入自我懷疑。面試不順利，絕不代表你是個差勁的軟體工程師。我曾經在寫完面試題之後發現一個小地方需要修正，還立刻回信通知 HR 自己的思路哪邊不對，還因為害怕因此錯失面試機會。
我在《雇用與面試》裡提過，面試本質上跟抽籤非常像。
在資源有限的情況下，公司為了避免錄取不適任員工帶來的巨大管理與離職成本，策略往往是提高 Precision、寧可犧牲 Recall。換句話說，公司寧願承受 False Negative（不小心刷掉實力優秀的人），也極力避免 False Positive（招進不合適的人）
在理解遊戲規則之後，你應該能發現面試是一個充滿雜訊的流程，在一個充滿雜訊的流程上定義自己的價值，往往是面試的內耗來源之一。
在《冒牌者症候群》中我也聊過，學會把自我價值和面試結果脫鉤，對心理健康至關重要。如果說面試最重要的事情是什麼，那大概就是心態調適了吧。
科技業的面試
我在《當測量變成目標：從窗戶稅到 Pull Request 數》裡談過 Goodhart’s Law：當一個測量指標變成目標時，它就不再是一個好的測量指標。
現代科技面試正是古德哈特定律最典型的受害者。
三十年前，微軟和 Google 引入演算法與智力題，原本只是希望藉由非制式的問題，當作評估候選人基礎計算思維與即時拆解問題能力的指標。然而，這個代理指標被固定成招聘的標準，整個系統就迅速被玩壞了。
Ruby on Rails 的創作者 DHH 也曾在 2017 年的一則推文中坦言，自己在白板上寫 bubble sort 也會失敗，平常經常上網查程式碼，也不做謎題。連打造出廣泛使用的框架的人，都不見得擅長面試裡的考題。
能不能在白板上即時寫出一個演算法，與能不能做好軟體開發，終究不能直接畫上等號。
當背誦冷門演算法成了通往高薪職位的門票，它不可避免地帶來了三個系統性扭曲：
- 催生了高價的應試產業鏈：候選人花費數千美元與幾百小時，學習一套人為設計的文化儀式與解題套路，這些記憶在通過面試進公司後，幾乎在一週內就會被大腦垃圾回收
- 高隨機性與高雜訊：匿名面試平台 Interviewing.io 的創辦人 Aline Lerner 在分析平台上數千場技術面試的數據後指出，技術面試的結果往往具有高度不確定性，即使平均表現優秀的人，不同場次的表現也可能有很大落差
一個天天查 Google 的工程師可能每週交付穩定可靠的架構；而一個能在白板上倒背紅黑樹的人，進團隊後可能連最基本的 Git conflict 都要解半天。
面試官在看什麼
別把面試當成一場單向的考試，它更像是一場互動式的技術對話。面試官通常帶著幾個核心問題在觀察你，我的話通常會有一些事先寫好的指標，在面試過程中逐漸挖掘，舉例像是：
- 基礎能力：基本功有沒有到位？如果有些細節不熟，能不能靠動手能力與邏輯迅速補足。面對面試者不熟的問題，我甚至會鼓勵面試者直接展示他如何與 AI 對話
- 文化契合度：通常公司會有一些文化標準，闡述他們對工作的期待與標準是什麼。我建議在應徵公司時，如果有這個頁面就先把閱讀一遍
- 協作並主動對齊：團隊通常會期待能夠協作、主動溝通並對齊認知的人才。這與公司當下正在招募的人才有關，但工作中通常免不了協作
- 解決問題的能力：面對一個未知且不確定的問題，是否能夠主動釐清需求，並將問題拆解成可以驗證的範圍
再來就是設計問題了，一個常見的面試問題大概會是：「跟我說說你遇過印象最深刻、最難的專案」，然後再從其中展開：
- 你在專案中扮演的角色是什麼？當時的需求是什麼？遇到了什麼效能瓶頸？為什麼傳統做法行不通？
- 清楚討論取捨：工程世界裡沒有銀彈。選 A 還是選 B？你在效能、可讀性、開發速度之間做了什麼妥協？如果重新回到當時的時空背景，你會做出什麼不同的決定？
這個問題之所以有效，是因為如果你只是掛名的話，你很難回答出所有細節；但如果你是真的有實際解決問題，你應該會對細節瞭若指掌。面試官也可以從對答中掌握你的水平、經驗大概到哪裡，是否有達到公司需要的標準。
如何在面試中證明自己？
在面試中，你應該把你自己想像成營銷的角色，這不是要你誇大自己，在面試中最大的目標就是證明自己有能力勝任此份工作。驗證你是否有能力勝任是公司端的事，你的目標應該是展示你的能力，以及判斷這家公司是否適合你。
當面試官給你提示時，別把它當成指責。絕大多數面試官不是為了把你問倒，他們只是疲憊的上班族，也希望能找到聊得來的同事。這也是一個觀察公司是否適合自己的好方法。
以下是一些可以採取的策略：
獲取資訊
在早期的獵頭或招聘經理訪談中，你也可以直接詢問：「能勝任這個職位的人，通常需要具備哪些特質？」拿到這些線索後，就能在後續的面試中更有針對性地展現優勢。像是公司比較看重 Infra 相關的人才，你就可以在簡歷當中多著墨關於 Infra 改善，甚至是 Hand-on 的經驗。
從專案經驗出發
先用最直觀、最簡單的方法把基本功能跑通，再隨著追問去優化複雜度。
如果是聊專案經驗，先從 High-level 的脈絡與挑戰切入，再深入技術細節：當時的需求是什麼？遇到了什麼效能瓶頸？為什麼傳統做法行不通？
主動對齊認知
很多溝通問題本質上只是資訊與認知落差。
主動向面試官確認細節：「你們希望深入到哪種程度的架構討論？」、「資料量大概是什麼規模？」這能幫你掌握方向，減少無謂的盲猜。
討論取捨
工程世界裡沒有銀彈。選 A 還是選 B？你在效能、可讀性、開發速度之間做了什麼妥協？如果重新回到當時的時空背景，你會做出什麼不同的決定？
誠實面對未知
不懂就老實承認，千萬不要不懂裝懂。資深工程師一眼就能看出破綻。承認不熟悉某個工具，接著說明你會如何查證、如何推導，反而展現了 Humble 與解決問題的底氣。
找機會 Showoff
面試官不一定會剛好問到你最擅長的事情。如果問題與你的經驗有關，可以在回答之後主動補一句：「這跟我之前處理過的一個問題很像，需要我展開說明嗎？」讓對方有機會深入，也確認這是不是他想了解的方向。
或者提到你在過往專案中如何定位效能瓶頸、降低基礎設施成本，或讓原本容易出錯的部署流程變得可靠。不要只列出你用了哪些技術，而是說清楚你發現了什麼、做了什麼，以及怎麼確認問題真的改善了。
有數據就交代改善前後的差異與測量條件；沒有數據，也可以說明具體改變。團隊一起完成的成果，則要讓面試官知道其中哪些判斷與工作是由你負責。
面試是雙向的
在《2017 年前端面試心得》我就體會過，面試從來不是單方面的考驗。面試官的態度、對時間的尊重程度、問題的深度，往往直接反映了團隊內部的日常，你在挑選每天要花八小時相處的夥伴。
我會建議在面試尾聲提問幾個環節，我把他稱作 Smell Test：
- 升遷機制：「團隊最近一次有人獲得升遷，主要是因為完成了什麼樣的事情？」
- 容忍底線：「團隊成員被認為不適任或被請離開，通常是因為遇到了什麼狀況？」
- 決策分歧：「當團隊在重大技術選型或架構上有嚴重分歧時，你們通常如何定案？能否做到 disagree and commit？」
- 日常開發：「目前團隊從寫完程式碼到發布到正式環境，需要經過哪些步驟？有自動化測試與部署嗎？」
- 公司文化：「最近有發生過高層直接干涉產品開發的情形嗎？」
如果對方的回答閃爍其詞、語帶防衛，或者面試官自始至終用高高在上的態度試圖電人，那麼就算拿到 Offer，你也該認真想想這是不是你想待的環境。
日本的面試
從以上的原則出發，我想要聊一下日本面試。在日本講求禮儀、年功序列制的職場環境下，你可能需要透過「表演」來通過面試。
公司的面試流程體現了這家公司的文化，如果一個公司重視的是禮儀、標準的尊敬語與謙讓語、能否長時間加班，代表加入公司後也會遇到類似的職場文化。每個人的選擇不同，但這類型的公司容易導致的問題有：
- 無法清楚說明標準：在工作上主管可能會以「你就應該做到啊！」「とりあえず根性だろう（總之就是靠意志力啊！）」來要求你
- 以保護自己的權力為優先：如果察覺到你的表現可能影響主管、同事的地位、權力，可能會優先選擇抵抗而非配合
- 重視形式上的禮儀：這可能體現在公司的例行朝會、精神喊話，進辦公室時要大喊おはようございます
我在挑選工作時，更希望加入以技術、解決問題為核心的公司，因此我通常會忽略這類型的公司，我也相當推薦面試時先列出一些自己無法妥協的條件與工作環境，幫助自己篩選。
可以看看我在 2019 年撰寫的日本軟體工程師求職心得。
最後，祝大家面試順利！面試確實不輕鬆，但它依然是一件可以透過準備來提高勝率的事情。不需要因為人為設計的儀式來否定你的全部。也歡迎寫信跟我分享你在面試中遇到的困難！