最近輔助了大量 Uber VO，最大的感受不是題太難，而是 Uber 的面試非常明確地在篩選某一類人。題目本身大多不複雜，但如果你不清楚他們在看什麼，很容易在自我感覺還行的情況下被刷掉。趁記憶還新，把多場 Uber 面經整理成一篇，給準備 Uber 的同學一個更真實的預期。
一、整體風格：不卷演算法，但非常看工程基本功
如果你刷了大量 hard 演算法題來準備 Uber，方向其實有點偏。Uber 的面試更像在問一個問題：你是不是一個能在真實工程裡穩定交付的人？ Coding 輪更多是工程向問題，System Design 很貼近業務，Behavioral 權重明顯高於很多公司。演算法會考，但往往不是靠技巧取勝的題，而是看你寫得是否乾淨、是否考慮邊界、是否能順著需求往下走。
二、Coding：題不難，但「怎麼做」比「做出來」重要
Uber 很愛出 停車場、Meeting Room、Reservation System 這一類題。比如設計一個停車場系統，支持 park、unpark、checkCar，不同類型車位有不同限制；或者設計一個 meeting reservation system，給定開始和結束時間返回 meetingId，沒有空房就拋異常。
import heapq
class ParkingLot:
def __init__(self, capacity_by_type):
# 每種車位類型維護一個可用車位編號的最小堆
self.free = {t: list(range(n)) for t, n in capacity_by_type.items()}
for t in self.free:
heapq.heapify(self.free[t])
self.slot_of = {} # plate -> (type, slot)
def park(self, plate, vtype):
if not self.free.get(vtype):
raise Exception("no spot") # 沒空位按需拋異常
slot = heapq.heappop(self.free[vtype])
self.slot_of[plate] = (vtype, slot)
return slot
def unpark(self, plate):
vtype, slot = self.slot_of.pop(plate)
heapq.heappush(self.free[vtype], slot) # 釋放後歸還編號
def check_car(self, plate):
return self.slot_of.get(plate)
這些題在 LeetCode 上基本是 easy 到 medium，但 Uber 非常在意你 按需求一步步實現。有一輪 onsite 的 coding 很典型：面試官會把後續小問一次性說出來，但 如果你為了方便提前設計一個複雜資料結構，反而會被認為沒有按當前問題作答。他們希望你把每一問當成獨立小需求，在已有實現上往前推進，而不是一開始就為最終版本鋪路。
三、LeetCode 原題不少，但會不斷追問
從多場面經看，LeetCode 原題出現頻率不低，比如 79、57、153、305、362、729。但 Uber 不滿足於你寫出標準解，而是不斷追問：
| 題號 | 題目 | 典型追問 |
|---|---|---|
| 79 | Word Search | 改 Trie / 多詞搜索 |
| 57 | Insert Interval | 基礎上支持刪除（calendar booking） |
| 153 | Find Min in Rotated Sorted Array | 有重複元素怎麼辦 |
| 305 | Number of Islands II | 並查集 + 線上加點 |
| 362 | Design Hit Counter | rate limiter 後擴展到分散式 |
| 729 | My Calendar I | 支持取消 / 多重預訂 |
有的題會要求在已有實現上 繼續擴展功能（calendar booking 加刪除）；有的會在 rate limiter 之後討論 如何擴展到分散式；還有電面重點看你寫的 test case，以及當 test case 改變時程式行為是否合理。在 Uber，寫完程式碼只是開始，解釋和擴展同樣重要。
四、System Design：熱力圖是入門，但遠遠不夠
Uber driver heatmap 確實是高頻題，很多人都會準備，但真實面試裡並不是萬能答案。有的面試官直接考，有的給一個非常接近但不相同的問題，有的乾脆不用。見過的題目還包括：
- Uber Eats 的 search function
- 類似 Robinhood 的 price tracking system
- 甚至 設計 AI chatbot（消息發送、chat history 存儲、inference）
有一輪 system design 體驗很不好：面試官心裡有一個明確解法，架構裡包含大量 proxy 和 services，重點討論 short-term scalability 和 long-term scalability。如果你的設計只是往熟題上套、但抽象層次沒對齊，很容易被持續質疑，很難拿到正向 signal。Uber 的 system design 不是你說得通就行，而是非常看你是否真正理解產品問題。
五、Behavioral：Hiring Manager 的權力比想象中大
從多場面經看，Uber 的 Behavioral 非常重視 ownership、collaboration、衝突處理、失敗經歷，以及你如何面對 blocker。有的 onsite 甚至整整 50 分鐘都在問這些，而且追問得非常細。HM 輪的權重很高，技術過了但 HM 不買賬，結果一樣不樂觀。準備時建議按這幾個維度各備 2 個 STAR 故事，並想清楚「遇到 blocker 時你具體怎麼推進」。
六、總結
Uber 在篩 能在真實工程穩定交付的人：Coding 不卷演算法，但極看「按需逐步實現」的工程紀律；System Design 貼業務，要求真正理解產品而非套模板；Behavioral 權重高，HM 決定性強。方向對了，準備會高效很多。
FAQ
Q1：Uber 後端面試要刷 hard 演算法嗎？
方向有點偏。Uber coding 更偏工程題（停車場 / Meeting Room / Reservation），演算法多是 easy-medium 原題（79/57/153/305/362/729），重點在 clean code、邊界、按需擴展，而不是 hard 技巧。
Q2：為什麼我寫出標準解還是被追問？
Uber 看的是「怎麼做」。寫完只是開始，他們會要求在已有實現上擴展（calendar 加刪除、rate limiter 上分散式），並考你的 test case 設計。別一開始就為最終版本過度設計。
Q3：driver heatmap 準備了就夠了嗎？
不夠。heatmap 是入門，真實面試可能考 Uber Eats search、price tracking、AI chatbot，且會深挖 short-term / long-term scalability。關鍵是真正理解產品問題，而不是往熟題上套。
Q4：怎麼準備 Uber 的 HM 行為面？
HM 權重很高。按 ownership / collaboration / 衝突 / 失敗 / blocker 各備 STAR 故事，重點講「面對 blocker 如何具體推進」。如果想要這幾類工程題的限時陪練、system design 推演，或需要 VO輔助 / VO代面 的即時對接，可以發職位 JD 先做題型預測再排練習計劃。
正在準備 Uber 面試？
Uber 考的是工程紀律 + 產品理解 + HM 溝通。oavoservice 提供 Uber 全流程陪練：停車場 / Meeting Room / Reservation 工程題限時模擬、heatmap / Uber Eats search system design 推演、HM 行為面演練，也支持 VO輔助 / VO代面 的即時對接。教練含前大廠資深工程師，熟悉 Uber「按需逐步實現 + 持續追問」的評分風格。
立即新增微信 Coding0201，獲取 Uber 真題與陪練。
聯絡方式
- 微信：Coding0201
- Email：[email protected]
- Telegram：@OAVOProxy