概述#

通往這本書的路有很多條：有人是經驗豐富的工程師、有人是 tester 或 PM、有人正在準備 acquisition 面試。本章針對這些「特殊情況」提供對應的建議。

Experienced Candidates（有工作經驗的候選人）#

有些人以為演算法題只針對應屆畢業生，這並不完全正確。

有工作經驗的工程師面試時，演算法題的比重只會略微減少。若一家公司對應屆生問演算法題，他們通常也會對有經驗的候選人問，因為他們認為這類題目所展現的能力對所有工程師都重要。

在評分標準上：

• 部分面試官對有經驗的候選人要求較寬鬆，因為距離上演算法課已久
• 部分面試官則要求更高，認為更多年的經驗代表接觸過更多類型的問題

兩種傾向平均下來，結果大致相同。

例外情況#

系統設計與架構問題，以及履歷相關問題，是有工作經驗候選人會被特別重視的領域：

• 學生通常不深入研究系統架構，這方面的能力主要來自職場經驗，因此評估時會考量你的資歷
• 即使是學生和應屆畢業生也會被問到系統設計題，應盡力作答
• 有工作經驗的候選人，對於「你遇過最難的 bug 是什麼？」這類行為問題，預期能提供更深入、更令人印象深刻的回答

Testers and SDETs（測試工程師）#

SDET（Software Design Engineer in Test） 與一般開發工程師一樣需要寫程式，差別在於他們測試功能而非建構功能。因此，SDET 必須是優秀的程式設計師，同時也是優秀的測試者。準備量要加倍。

準備方向#

• 準備核心測試問題（Testing problems）：例如「你會如何測試一個燈泡？一枝筆？一台收銀機？Microsoft Word？」本書的 Testing 章節有更多背景知識
• 準備程式碼題（Coding questions）：SDET 被拒絕的首要原因是程式能力不足。雖然 SDET 的程式標準通常比一般開發工程師低，但仍期望在程式碼與演算法上有很強的表現。練習與一般開發工程師相同的程式題
• 準備測試程式碼的題目（Testing the coding questions）：SDET 面試中很流行「請寫出 X 的程式碼，然後測試它」這類格式。即使題目沒有明確要求，也應主動問自己：「我要如何測試這段程式碼？」任何問題都可以是 SDET 問題

此外，溝通能力對 SDET 非常重要，因為這個職位需要與許多不同的人合作。不要忽略行為問題的準備。

職涯建議#

若你打算以 SDET 作為進入公司的「捷徑」，要注意：從 SDET 轉換到開發職位的難度相當高。許多人發現這條路比預期困難得多。若你希望轉換，務必保持程式碼與演算法能力的高水準，並盡量在 1–2 年內完成轉換，否則之後在開發職位的面試中可能很難被認真對待。

切勿讓你的程式能力退步。

Product (and Program) Management（產品與專案管理）#

PM 職位在不同公司甚至同一家公司內差異極大——有些 PM 幾乎是客戶傳道士，有些則花大量時間寫程式。後者類型的 PM 面試可能涵蓋程式碼題。

PM 面試考察的核心領域#

• Handling Ambiguity（處理模糊情境）：面試官希望看到你面對不確定的情況時，能主動收集資訊、找出最重要的問題，並以結構化方式解決問題，而非陷入停頓。通常不會直接測試，但在解題過程中會觀察到

• Customer Focus - Attitude（以客戶為中心的態度）：你是否站在使用者的角度思考？是否能理解不同使用者如何使用你的產品？設計題（例如「為盲人設計一個鬧鐘」）是考察這一點的好機會，要多問問題以釐清使用者是誰、如何使用產品

• Customer Focus - Technical Skills（技術能力的客戶導向）：部分有複雜產品的團隊，要求 PM 對產品有深入技術理解。例如 Windows Security 團隊的 PM 可能需要具備資安背景知識

• Multi-Level Communication（多層次溝通）：PM 需要與公司各層級、各技術深度的人溝通。面試官可能透過「向你的祖母解釋 TCP/IP」這類問題來評估你的溝通靈活性，也會從你描述過往專案的方式中觀察

• Passion for Technology（對技術的熱情）：面試官想確保你對這份工作感到興奮。無論是直接被問「你為何對 X 感興趣？」，還是從你討論過往經驗的方式中，都會觀察到這一點

• Teamwork / Leadership（團隊合作與領導力）：這可能是 PM 面試中最重要的一環，也是工作本身最核心的能力。面試官會問你如何處理衝突、如何激勵成員、如何在不同意時仍能合作前進

這些領域的比重，大致對應到它們在實際 PM 工作中的重要性。準備行為問題對 PM 面試尤為關鍵。

Dev Lead and Managers（開發主管與管理職）#

開發主管職位幾乎都需要強勁的程式能力，管理職位通常也是如此。若這份工作需要你親自寫程式，就要像一般開發工程師一樣準備程式碼與演算法題。Google 尤其對管理職候選人維持高標準的程式能力要求。

額外考察領域#

• Teamwork / Leadership（團隊合作與領導力）：無論是明確的問題（「你曾何時與主管意見不合？」）還是隱性觀察（面試官看你如何與他們互動），這都會被評估。過於強勢或過於被動，都可能讓面試官懷疑你的領導能力

• Prioritization（優先排序）：管理者常面對「如何讓團隊如期完成任務」的難題。面試官想看到你能適當取捨，懂得分辨什麼是真正關鍵的，什麼可以放棄或延後

• Communication（溝通能力）：管理者需要與上下級以及技術能力不同的人溝通。面試官評估你能否在各層次清楚、友善地傳遞訊息——這在某種程度上也是人格特質的評估

• “Getting Things Done”（執行力）：最重要的管理能力，可能是「讓事情發生」。你需要了解如何架構一個專案，並懂得激勵人心，使團隊目標得以實現

大多數考察領域最終都回歸到你的過往經驗與個人特質。務必使用本書的 interview preparation grid 徹底準備。

Startups（新創公司）#

新創公司的申請與面試流程差異極大，以下提供一些通用方向，但具體的新創可能有所不同。

申請流程#

• 許多新創會貼職缺，但對熱門新創來說，最有效的方式往往是個人推薦（personal referral）
• 不一定要是親近的朋友或同事——主動表達興趣，往往就能讓對方幫你遞履歷

工作簽證#

美國許多小型新創無法協助辦理工作簽證。若你需要簽證，建議聯繫熟悉多家新創的獵人頭顧問，或將目標鎖定在規模較大的新創。

履歷篩選#

新創希望招募的不只是聰明會寫程式的工程師，更要能在創業環境中發揮的人。你的履歷應展現主動性（initiative）——你啟動過哪些自己的專案？

此外，「開箱即戰力（hit the ground running）」非常重要；他們希望你已熟悉公司使用的技術棧。

面試流程#

相較於大公司主要評估一般軟體開發能力，新創往往更關注個人特質、技術能力與過往經驗三個維度：

• Personality Fit（個性契合度）：通常由你與面試官互動的方式來評估。建立友好、有活力的對話是進入許多新創的關鍵
• Skill Set（技術能力）：新創需要能立即上手的人，可能會考察特定程式語言。若你知道對方使用什麼技術，務必熟悉細節
• Experience（經驗）：新創很可能大量詢問你的過往經驗，行為問題的準備非常重要

標準的程式碼與演算法題在新創中同樣很常見。

Acquisitions and Acquihires（收購與人才收購）#

在許多收購案的技術盡職調查過程中，收購方往往會面試被收購新創的部分或全部員工。Google、Yahoo、Facebook 等公司都將此列為收購流程的標準環節。

哪些新創需要面試？為什麼？#

主要原因是：被收購公司的員工並未像一般求職者那樣經過面試就進入公司。收購方不希望把收購當作進公司的「捷徑」，且由於「人才」往往是這次收購的核心動機，評估團隊能力是理所當然的。

值得注意的是，數十億美元的知名收購案通常不需要這個流程——那類收購更看重用戶基礎與社群，而非個別工程師的能力。

人才收購（acquihire，純粹為了人才的收購）與產品收購之間其實存在很大的灰色地帶。許多新創被收購，原因是看上了團隊與技術背後的想法，收購方可能停止原本的產品，但讓團隊繼續做類似的事情。

這些面試有多重要？#

這些面試具有極重要的意義，有三個不同的作用：

• 它們可能決定收購是否成功——有時是公司不被收購的原因
• 它們決定哪些員工能獲得加入收購方的 offer
• 它們會影響收購價格（部分取決於最終加入的員工人數）

這遠不只是一個普通的「篩選」環節。

哪些員工需要面試？#

• 對科技新創來說，幾乎所有工程師都需要面試
• 業務、客服、PM 等角色也可能需要
• CEO 通常被安排在 PM 或開發主管的面試中，但也有 CEO 選擇放棄面試、在收購後離開公司

面試表現不好的員工會怎樣？#

表現不佳的員工通常不會獲得 offer。如果太多員工表現不好，整個收購可能無法成交。

部分表現不佳的員工可能獲得「知識轉移」的短期合約（通常六個月），結束後離開，但有時最終也會被留用。

部分情況是員工被「錯位」了：

• 新創將非傳統軟體工程師（如資料科學家、資料庫工程師）標記為軟體工程師，導致他們在軟體工程師面試中表現不佳
• CEO 誇大了某位初級工程師的資歷，導致他以更高的標準被評估

你的「最強」和「最弱」員工可能出乎你意料。

頂尖科技公司的面試評估的是特定能力，可能與主管對員工的日常評估不完全一致。資歷尚淺但擅長解題的工程師，可能在面試中表現優異。在看到評估結果之前，不要預設誰會表現好或差。

員工的標準與一般候選人一樣嗎？#

基本上是的，但稍微寬鬆一些。大公司傾向保守，若候選人的評估處於邊緣，往往傾向不錄取（no-hire）。但在收購情境下，邊緣員工可能因為整個團隊的強勢表現而被帶過關。

員工如何看待收購面試這件事？#

這是許多新創創辦人和 CEO 擔心的問題。實際上：

• 部分員工會不開心，可能不喜歡加入大公司
• 但大多數員工是謹慎樂觀的——他們希望收購成功，但也知道面試不過關就可能泡湯

收購後團隊怎麼辦？#

每種情況都不同。根據作者的客戶經驗，大多數團隊會被整體保留，或整合進現有的某個團隊中。

如何準備 acquisition 面試？#

準備方式與一般面試非常類似，差別在於這是作為團隊整體應對，而非個人被選中面試。

建議：

• 個人學習、兩三人小組練習、以及互相進行 mock interview，三種方式並用
• 給那些準備不足的人足夠的時間：許多新創工程師對 Big O、binary search tree、BFS 等概念可能只有模糊印象，他們需要更多時間
• 不要等到最後一刻：收購面試往往說來就來，一旦有了面試日期，可能只剩幾天時間準備——那根本不夠學習核心 CS 概念

For Interviewers（給面試官的建議）#

本書最初是寫給候選人的，但許多面試官也在用它學習如何進行面試。以下是一些重要的面試官指引。

不要直接使用書中的題目#

書中的題目是為了面試準備而設計的，而不是用來直接搬上面試的。原因有二：

1. 部分適合練習的題目（如腦筋急轉彎）未必適合實際面試
2. 你的候選人也在讀這本書——你不想考他們的記憶力，而是解題能力

可以問類似風格的題目，但不要照搬。

問中難或困難的題目#

面試的目的是評估解題能力。太簡單的題目讓表現趨於集中，細微的差別會對分數產生不成比例的影響，不可靠。

尋找有多個考察點的題目#

依賴單一「Aha！」頓悟的題目是弱問題——候選人要麼靈光一閃，要麼完全不知道。理想的題目有一連串的困難點、洞見、或優化機會，多個數據點勝過單一數據點。

一個簡單的測試：如果給一個提示就能大幅改變候選人的表現，這道題可能不是好面試題。

用難題，而非用冷僻知識#

有些面試官想讓題目「難」，結果不小心讓知識變難，而非解題變難。候選人應有的知識範圍是相當直接的資料結構與演算法知識——Dijkstra 演算法或 AVL 樹的細節，對大多數電腦科學畢業生來說都記不清了。

若你的題目需要冷僻知識，問問自己：這真的是重要能力嗎？還是你只是在無意間縮小了錄取候選人的範圍？

避免「嚇人」的題目#

部分題目看起來像是需要專業知識（數學、機率、系統設計、低層次的記憶體知識），其實並不需要。面試本身已經夠緊張了，一道看起來很嚇人的題目可能讓候選人慌亂，導致表現不反映真實能力。

若要問看似嚇人的題目，務必先明確告訴候選人：這不需要你想的那種專業知識。

給予正向回饋#

面試官有時太專注於「問好題目」，而忘了自己的行為舉止同樣重要。

許多候選人非常緊張，會解讀面試官的每一句話——就連「加油」這種客套話也會讓他們過度思考。你希望候選人有好的面試體驗、對你和公司留下好印象，也希望有能力的人不要因為緊張而表現失常。

在面試中適時給予正向回饋：

• “Right, exactly.”
• “Great point.”
• “Good work.”
• “Okay, that’s a really interesting approach.”
• “Perfect.”

無論候選人表現如何，總有些地方是對的。找到那些地方，注入正面氛圍。

在行為問題上深挖#

許多候選人不擅長清楚表達自己的貢獻。他們可能講的是團隊的成就，而非個人的角色。

• 不要因為聽不出候選人做了什麼，就假設他沒做什麼
• 主動詢問：「你個人在這件事上的角色是什麼？」
• 若感覺不深刻，繼續追問：「你是怎麼思考這個問題的？你為什麼採取那些行動？」

記住：能清楚描述自己貢獻是「當好候選人」的技能，而不一定是「當好員工」的技能。

適時引導候選人#

閱讀本書關於「如何解題」的章節，許多技巧你也可以在候選人卡關時提供：

• 若候選人沒有用例子，引導他們建立一個好例子
• 若他們在測試時用了過大的例子，引導他們縮小範圍
• 若他們在找到最優解前就急著寫程式，拉回來讓他們先優化演算法
• 若他們緊張卡住不知從何開始，建議先嘗試暴力解

即使你引導了候選人，你仍可以在評分中記錄他們「沒有通過」這個環節，並在評分時相應考量。引導候選人是把面試技巧（interview skill）與工程能力（job skill）分開來評估。

若候選人需要安靜思考，給他們安靜#

候選人有時需要一點時間安靜思考，而不是被要求一直說話。學會區分「我卡住了，完全不知道怎麼辦」和「我正在安靜思考」這兩種情況，給予適當的空間。

了解你的面試模式#

從整體來看，有四種問題模式：

• Sanity Check（基本確認）：容易的問題，篩掉明顯不適合的人，無法區分「好」與「很好」。適合用在篩選早期或僅需基本能力的場合
• Quality Check（品質確認）：真正有挑戰性的題目，能讓候選人真正思考。在演算法解題能力最重要時使用
• Specialist Questions（專業知識題）：考察特定主題，例如 Java 或機器學習。應只在職位真正需要難以在職中快速習得的專業知識時使用
• Proxy Knowledge（代理知識）：候選人在這個層級理應掌握的知識，例如長期使用 CSS 的工程師應能解釋表格的優缺點

常見的混淆錯誤：

• 對非專家問專業知識題
• 招募不需要專家的職位，卻用專業知識題篩選
• 以為自己在問 Quality Check，其實問的是 Sanity Check——導致「好」與「很好」的候選人被錯誤地歸為同一類