👔 我的 Google 面試經歷
前言
距離上次更新博客，大約已經過了一個月。
這段時間，我一直想寫點新的內容，卻遲遲找不到適合的主題。直到最近，我開始頻繁回想起 2024 年 2 月參加 Google 面試的經歷，才決定趁著記憶還算清晰，把整段過程記錄下來，也分享給正在準備軟體工程師面試的人。
當時我一共經歷了五輪面試。這篇文章主要會分享我與 HR 的談話過程，以及第一輪 Coding Interview 的完整經歷。
之所以沒有逐一記錄其他四輪，是因為幾輪程式設計面試的形式大致相同，而且我仍然保留著第一輪面試時寫下的程式碼，比較適合拿來還原整個解題過程。
我如何準備 Google 面試
為了準備 Google 的面試，我前前後後花了將近一年的時間，總共完成大約 350 題 LeetCode。
還記得當時我仍在 ASML 工作，下班後的生活幾乎只剩下兩件事：健身和刷題。甚至有一次放假和朋友去阿里山旅遊，我還特地找了一間咖啡廳，坐在裡面繼續刷 LeetCode。
現在回頭看，多少有點走火入魔，但當時確實非常投入。
為了提升準備效率，我還在網路上找了一位專門教授 LeetCode 的家教。除了協助我整理資料結構與演算法的觀念，也能定期追蹤我的刷題進度，避免自己只挑熟悉或喜歡的題型練習。
Google HR 的來電
經過長時間準備後，我終於在 2024 年 1 月接到 Google HR 的電話。
以下是我依照記憶整理出的對話內容：
HR：「我看過你的履歷，你在 ASML 已經待了快兩年，時間也不算短，怎麼會突然想換工作？」
我：「其實我大學畢業後就一直很想進入軟體產業，我的大學畢業專題也是使用 Python 開發。只是當時沒有找到適合的機會，加上台灣半導體產業正在大舉徵才，所以最後選擇加入 ASML。」
HR：「了解。那你對 Google 的面試流程有多少認識？」
我：「我知道 Google 會有好幾輪面試，主要會考資料結構、演算法和 LeetCode 類型的題目。另外好像也有一輪行為面試，用來評估所謂的 Googleyness？」
HR：「沒錯，你提到的就是 G&L，也就是 Googleyness and Leadership Interview。你目前大約完成多少題 LeetCode？」
我：「大約 350 題。」
HR：「資料結構和演算法的各種題型都有接觸過嗎？我們之前遇過一位面試者刷了 500 題，但他只集中練習單一類型，例如 Linked List。Tree、Dynamic Programming 和 Stack、Queue 等題型都不太熟悉。」
我：「我了解你的意思。我並不是只練特定題型，平常會隨機選題，你剛才提到的資料結構和演算法類型，我都有練習過。」
HR：「好的，那我會協助你安排第一輪面試。先說明一下，第一輪會是 Coding Interview，全程使用英文，而且不能使用 IDE 或查詢資料。
第一輪通過後，我們會再安排後續四輪面試，其中三輪是 Coding Interview，另外一輪則是剛才提到的 G&L Interview。」
我：「第一輪面試大約會安排在什麼時候？」
HR：「大約是兩週後。」
我：「好的，那再麻煩你寄送面試邀請給我，謝謝。」接下來，HR 又向我說明了許多面試時需要注意的事項，以及可以如何準備 G&L Interview。
整段通話中，我可以感覺到 HR 不只是負責安排流程，也真心希望候選人能夠做好準備並順利通過面試。這種感受，多少也緩解了我當時的緊張。
在正式面試前一週，我另外找了幾位朋友，進行了四次 Mock Interview。
非常感謝 Phillip、Ivy、Jade、Alex、Yale、Steve，以及綿羊群的其他夥伴，願意抽出時間陪我進行模擬面試，並提供許多寶貴的建議。
第一輪 Coding Interview
時間來到第一輪面試。
當天的面試官是台灣 Google Pixel Team 的一名工程師。他給我的第一印象非常斯文，表達能力和英文能力也都相當出色。
雙方簡單自我介紹後，他請我分享螢幕畫面，接著給了我以下題目：
Implement a restaurant waitlist data structure. It should support thefollowing features:
1. A party of customers can join the waitlist.2. A party in the waitlist can leave the waitlist at any time.3. The restaurant serves the first party whose size equals the empty table size (the table size is given as an argument).簡單來說，需要設計一個餐廳候位系統，並支援以下功能：
- 一組顧客可以加入候位名單。
- 候位中的顧客可以隨時離開。
- 當餐廳出現空桌時，系統必須找到候位名單中第一組人數符合桌位大小的顧客。
以下是我依照記憶整理出的對話：
面試官：「你可以先花一點時間閱讀題目，接著說明一下需要實作哪些函式。」
我：「首先需要一個 join 函式，輸入是 party_id 和 party_size，也就是這組顧客的編號與人數。
接著需要一個 leave 函式，輸入只需要 party_id。
最後是 serve 函式，輸入是 table_size。因為題目要求餐廳優先服務候位名單中，第一組人數符合桌位大小的顧客。」
面試官：「聽起來沒有問題。那你會使用什麼資料結構來解這道題？」
我：「目前最直觀的做法是使用 Doubly Linked List。每個 ListNode 代表一組顧客，並包含 id 和 size 兩個屬性，分別代表 party_id 和 party_size。」
面試官：「好，那請你分析一下這三個函式的時間複雜度。」
我：「join 會是 O(n)，因為我需要先走訪整個 Linked List，確認相同的 party_id 是否已經存在。如果存在就回傳 False；如果不存在，再把新的 party 加到 Linked List 尾端。」
面試官：「沒錯，那 leave 呢？」
我：「leave 同樣需要走訪 Linked List，找到符合的 party_id 後再將節點移除，所以時間複雜度也是 O(n)。
serve 也是類似的概念，需要從頭開始尋找第一個 party_size 符合桌位大小的節點，因此也是 O(n)。」
面試官：「很好，那就開始寫吧。」接著，我開始撰寫程式碼。
在整個過程中，我一邊輸入程式碼，一邊使用英文向面試官說明自己的思考方式，包括目前正在實作的功能、選擇這個資料結構的原因，以及需要處理的邊界條件。
大約 30 分鐘後，面試官看完我的初版程式碼，接著問道：
面試官：「我覺得你目前寫的程式碼沒有什麼問題。不過現在 join 和 leave 的時間複雜度都是 O(n)，有沒有辦法進一步優化？」
我：「我可以加入一個 Hash Map，也就是 Python 的 Dictionary。
Dictionary 的 key 是 party_id，value 則是該 party_id 對應的 ListNode。這樣就不需要每次走訪整個 Linked List，可以直接透過 map[party_id] 找到對應的節點。
只要在新增或移除 ListNode 時，同步更新 Dictionary，就可以把 join 和 leave 的時間複雜度從 O(n) 降到 O(1)。」
面試官：「非常好。」大約又過了 10 分鐘，我完成了原始程式碼的優化。
面試的最後，我也詢問了面試官一些關於工作內容、團隊合作方式與公司文化的問題，第一輪面試便正式告一段落。
以下是當時面試的完整程式碼：
# Implement a restaurant waitlist data structure.# It should support the following features:# 1. A party of customers can join the waitlist.# 2. A party in the waitlist can leave the waitlist at any time.# 3. The restaurant serves the first party whose size equals the empty table size (the table size is given as an argument).
# join(ID, size) -> Bool# leave(ID) -> Bool# serve(size) -> ID or -1 (if no matching size)
class ListNode: def __init__(self, ID, size, prev=None, next=None): self.ID = ID self.size = size self.prev = prev self.next = next
class WaitList: def __init__(self): self.head, self.tail = ListNode(-1, 0), ListNode(-1, 0) self.head.next = self.tail self.tail.prev = self.head self.map = dict()
def join(self, ID, size): if ID in self.map: return False
prev = self.tail.prev node = ListNode(ID, size)
prev.next = node node.prev = prev node.next = self.tail self.tail.prev = node
self.map[ID] = node return True
def leave(self, ID): if ID not in self.map: return False
node = self.map[ID] prev, next = node.prev, node.next
prev.next = next next.prev = prev
del self.map[ID] return True
def serve(self, size): node = self.head.next
while node.ID != -1: if node.size == size: ID = node.ID prev, next = node.prev, node.next
prev.next = next next.prev = prev
del self.map[ID] return ID
node = node.next
return -1
"""time complexity: join: O(1) leave: O(1) serve: O(n)"""隔天，我接到 HR 的電話。
HR 告訴我，第一輪面試收到的回饋非常正面。除了程式設計能力獲得肯定之外，我在「表達與溝通能力」方面，也被面試官給予了 Outstanding 的高度評價。
得知結果後，我當然非常開心。這也代表過去一年投入的時間和練習，至少在第一輪面試中確實發揮了作用。
隨後，HR 協助我安排剩下的四輪面試。整個流程前後大約持續了三週。
最後，我被告知其中一輪 Coding Interview 的表現沒有達到團隊預期，因此沒有通過這次招募流程。
總結
雖然經歷了 Google 的五輪面試後，我最終沒有獲得錄取，但這段過程對我而言仍然非常珍貴。
Google 一直是我心目中軟體產業的標竿。能夠收到面試邀請，與 Google 的工程師實際討論問題，並完整走過五輪面試，本身就是一次難得的經驗。
更重要的是，這次經歷讓我重新理解了一件事：技術面試考驗的不只是你能不能寫出正確答案，而是你如何面對陌生問題、拆解需求、說明思路，並在接收到提示後調整自己的解法。
以下是我在刷題與面試過程中整理出的幾點心得：
-
遇到沒看過的題目會緊張，是非常正常的。
Google 的面試官本來就不只是想確認你是否背過題目，而是想觀察你遇到陌生問題時，會如何分析與解決。 -
寫程式碼之前，先確認自己對題目的理解。
可以先向面試官整理需求、說明輸入輸出，並提出必要的澄清問題。與其寫到一半才發現理解錯誤，不如一開始就把方向對齊。 -
不要一開始就執著於最佳解。
先提出最直觀、能夠正確運作的解法，即使是時間複雜度較差的Brute-Force Solution也沒關係。先求有，再逐步分析瓶頸並進行優化。 -
解題時不要長時間保持沉默。
在撰寫程式碼的同時，也要適時說明自己正在思考什麼、為什麼選擇這個方法，以及接下來準備做什麼。面試官只有理解你的思路，才能正確評估你的能力，也才能在必要時提供引導。 -
認真理解面試官給出的提示。
多數情況下，提示不是在刁難你，而是在協助你回到正確方向。能否吸收提示並調整解法，本身也是面試評估的一部分。 -
刷題數量不是唯一標準，但累積仍然有意義。
LeetCode 的確需要一定程度的邏輯能力與熟練度，但隨著練習量增加，辨識題型、拆解問題與實作解法的速度，都會逐漸進步。 -
溝通能力和程式設計能力同樣重要。
Coding Interview 並不是一場安靜的個人考試，而是一次模擬共同解決問題的過程。能夠清楚表達、接受回饋並與對方合作，往往和最後的程式碼一樣重要。
求職從來都不是一件容易的事。
有時候，即使準備了很長時間、完成了數百道題目，也可能因為其中一輪表現不如預期而停在最後幾步。但這並不代表之前投入的努力毫無價值。
至少對我來說，這次面試讓我更了解自己的優勢與不足，也證明了我有能力走到這個階段。
希望這篇文章能為正在準備技術面試，或正在經歷求職低潮的你，帶來一些實際的幫助。
參與討論
使用 Twikoo 參與討論
接近此區域時將載入評論。