Uber 的 Data Scientist 面試有一個非常鮮明的特徵：business impact driven。它不是那種「寫一段 SQL、跑一個 A/B test」就能交差的職缺，而是要求候選人在每一道 case 裡同時展現 資料建模能力 + 跨部門溝通能力 + Marketplace 雙邊市場直覺。這篇文章把一次完整的 Uber DS 面經依「VO 三輪 + Onsite 五輪」拆解到題面、踩坑點、應對框架，方便正在準備的朋友對照練習。
流程概覽：VO 三輪 → Onsite 五輪
W0 Recruiter 電話 / Career Site 投遞
W1 VO Round 1 — Hiring Manager（45 min）
W2 VO Round 2 — Stakeholder Management（45 min）
W3 VO Round 3 — Analytics & Experimentation（60 min）
W4 Onsite 五輪（一整天，每輪 45-60 min）
Coding (Python/SQL) → Bar Raiser → Marketplace Experimentation
→ XFN with PM → Hiring Manager
W5 Team Match → Offer 決議
VO 三輪基本上是一個「篩選漏斗」：HM 看大方向 fit，Stakeholder 看跨部門溝通，Analytics 看實驗設計基本功。Onsite 才是真正的深度考核，這裡也是 candidates 最容易翻車的地方。
VO 階段三輪拆解
Round 1 — Hiring Manager：專案 Impact 必須是數字
HM 這一輪看似最簡單（resume + 專案），但陷阱就在 follow-up：
"How much real business impact did your model end up delivering?"
如果你的履歷上只寫「improved accuracy by 4%」，HM 會立刻追問到具體的 GMV / retention / cost saving 數字。我建議事先準備一個「impact paragraph」模板：
Project: <one-liner>
Stakeholder: <which team / who consumed the output>
Metric: <baseline → after, absolute Δ>
Business value: <$ saved / GMV lifted / hours reclaimed>
My role: <I owned X, partnered with Y on Z>
HM 還會丟一道 product case 暖手，強度不大但要求框架感。Uber 習慣聽到的結構是 Hypothesis → Metric → Experiment，把這三段放在第一句話裡拋出來，interviewer 會立刻給綠燈。
Round 2 — Stakeholder Management：Uber Eats 優惠券對比
這一輪的 BQ 幾乎都是同一類：
"What would you do if a cross-functional partner disagreed with your analytic recommendation?"
不要一上來就講「我會用資料說服他」。Uber 想聽到的是：
- 理解對方動機（PM 關心 launch 時間 / Ops 關心成本）
- 共建一個評估框架（先約定 metric，再討論具體數字）
- 資料收口（用最小可比較的實驗切片回答爭議）
緊接著會進入 product case，典型題：
"How do you compare and prioritize the effectiveness of Uber Eats promotions?"
很多候選人會陷進「先看轉換率還是 GMV」的細節裡。正確做法是先拋一個二維框架：
| 維度 | User Growth | Profitability |
|---|---|---|
| Conversion rate | ✅ | — |
| GMV per session | — | ✅ |
| Retention W4 | ✅ | — |
| Margin per order | — | ✅ |
| Spillover to Rides | ✅ | ✅ |
把矩陣擺出來，再討論 prioritization：early-stage promo 看 user growth，mature promo 看 profitability。Interviewer 關心的是優先級判斷，不是哪個具體數字。
Round 3 — Analytics & Experimentation：Leave-at-Door
Uber Eats 真實業務背景：
"Leave at door 被 60% 使用者使用，但訂單遺失率比 hand-it-to-me 高 5 倍，refund 成本急遽上升。請分析原因並設計實驗。"
很多候選人會本能地說「跑一個 regression model」，但 Uber 想聽的不是技術，而是使用者旅程拆解：
遺失原因可能來自：
┌─ 使用者側：地址描述模糊 / 公寓樓層無標示 / 時間窗錯位
├─ 司機側：未拍照確認 / 放在錯誤樓層 / 時間緊趕下一單
└─ 系統側：定位精度差 / 通知未觸達 / refund 流程過寬鬆
實驗設計也不是單純 A/B：Uber 期待地理聚類實驗（cluster randomization），因為同一棟公寓的使用者互相干擾、單純按 user 切流會有 SUTVA violation。建議給出雙層實驗：
Layer 1: 地理聚類（high-risk zip 5-digit vs low-risk）
Layer 2: 內層 A/B（強制拍照 vs 預設流程）
Power analysis: 每 zip 至少 200 單，運行 14 天
這套框架拋出來基本就鎖分了。
Onsite 五輪拆解
1️⃣ Coding（Python/SQL）— 不讓用 Pandas
Uber DS 的 Coding 經常會突然限制函式庫：
"Don't use Pandas. Merge two dataframes by hand."
這不是真要你寫 C 風格的程式碼，而是驗證你能否在沒有 black-box 工具時把資料流講清楚。骨架：
def manual_merge(left: list[dict], right: list[dict],
on: str, how: str = "inner") -> list[dict]:
"""
手寫兩個 dataframes 的 merge：用 dict 做 hash join。
支援 inner / left。
"""
index = {}
for row in right:
key = row[on]
index.setdefault(key, []).append(row)
out = []
for row in left:
matches = index.get(row[on], [])
if matches:
for m in matches:
merged = {**row, **{k: v for k, v in m.items() if k != on}}
out.append(merged)
elif how == "left":
out.append({**row})
return out
寫完之後必加：複雜度 O(n + m)、tie-break 規則、null on-column 怎麼處理。Interviewer 會按這三點逐項打分。
緊接著會有一道 SQL，節奏建議是 先寫最樸素的 join，再疊加 aggregation，不要一上來就堆 window function。
2️⃣ Bar Raiser — Uber One 戰略級 Case
Director 會丟一個非常寬的題：
"How would you launch Uber One and analyze its success?"
最容易翻車的是直接埋頭算 GMV / retention，被認為「沒有 executive presence」。正確打開方式是分三層：
| 層 | 看什麼 | 關鍵 metric |
|---|---|---|
| User | 是否解決了 cross-product 切換摩擦 | Rides + Eats 雙產品月活、ARPU lift |
| Merchant | 是否帶來更高品質訂單 | Member order GMV、basket size、cancellation rate |
| Platform | 是否提升 Marketplace 健康度 | Member LTV、subscription churn、incremental contribution |
每一層先講戰略意圖，再下鑽 metric。三層講完，自然顯得「站得高」，Bar Raiser 會買單。
3️⃣ Marketplace Experimentation — Merchant Onboarding
題面：
"Uber Marketplace 要決定 onboard 哪些商家，怎麼建模？"
坑：很多人套電商「補貼拉新」邏輯。Uber 是雙邊市場，必須從供需兩側講：
- 供給側：商家品類覆蓋、cuisine diversity、配送半徑
- 需求側：周邊訂單密度、未滿足偏好、價格敏感度
- 撮合效率：撮合時長、空駛率、merchant utilization
模型層面，可以給出一個 expected incremental GMV 的迴歸框架：
E[ΔGMV | onboard m]
= α · demand_density(m)
+ β · supply_gap(m)
+ γ · matching_efficiency(m)
- δ · cannibalization(m)
最後強調：onboard 決策不能只看絕對 GMV，要看 incremental 的部分（扣掉對現有商家的蠶食）。
4️⃣ XFN with PM — 切到 Layman 語言
這一輪氣氛最輕鬆，但有一個小 trick：別再用 DS 行話。PM 想聽的是 storytelling：
"Onboarding 一個新商家就像在街角開一家新餐廳—— 你得先估周邊客流、口味偏好、其他餐廳的密度， 再決定開張時間和菜單。"
把 marketplace 模型翻譯成餐廳比喻，PM 立刻能跟上節奏，反過來拋出更細的產品問題，會話就順了。
5️⃣ Hiring Manager 收尾 — Impact 優先
最後一輪 HM 會問 career motivation 和 most impactful project。別講學術成就，把 impact 翻譯成業務語言：
❌ "I improved AUC from 0.81 to 0.85." ✅ "My fraud model saved the company $2.3M in chargebacks the first quarter after launch."
VO 輔助與 VO 代面：Uber DS 怎麼對接
Uber DS 的 case study 節奏快、跨度大，自己單練很容易陷在某一類題裡。我們的 VO 輔助 會按下列節奏排：
- 職缺線判定：先確認是 Marketplace DS / Product DS / Experimentation Platform，三條線題型不同
- 題型預測：覆蓋 Eats promotion / Rides surge / driver retention / leave-at-door 等歷史高頻
- 限時 mock：依 45-min × 3 / 60-min × 5 節奏跑全套
- 現場 cue：onsite 當天即時拉框架（Hypothesis → Metric → Experiment / 雙邊 marketplace 三層 / impact paragraph）
- 覆盤：每輪結束 30 min 內回放，找回答裡 metric 不閉環的地方
如果你的行程已經被推到 onsite 週內，我們也支援 VO 代面 的對接路徑：先做職缺線 + 邀請郵件資訊核對，再決定上 VO 輔助 還是 VO 代面。
FAQ
Q1: Uber DS 的 VO 三輪和 Onsite 五輪總週期多長？ A: 一般 4-5 週。VO 三輪通常在 2-3 週內完成（每週 1-2 輪），Onsite 排期會在 VO 全過之後 1-2 週內一整天打包完成。
Q2: Coding 這一輪真的不能用 Pandas 嗎？ A: 不是絕對禁止，是 interviewer 想看你能否在不依賴函式庫的情況下講清楚資料流。建議先問一句「Can I use Pandas as a follow-up after a manual implementation?」，得到允許再用。
Q3: Marketplace case 和電商 case 最大的區別是什麼？ A: 電商通常是單邊——你只關心買家。Uber 是雙邊——司機/商家供給和乘客/食客需求要同時建模，單看一側的指標會被 interviewer 直接挑戰。
Q4: Bar Raiser 這一輪如何避免被認為「不夠 senior」？ A: 別一上來就下鑽 metric，先用 user / merchant / platform 三層結構鋪戰略，再選其中一層下鑽到 metric。這是最穩的「executive presence」表達方式。
Q5: 找 VO 輔助介入最晚到什麼階段還來得及？ A: VO Round 1 之前是最理想的，可以從職缺線判定開始。如果已經到了 onsite 前一週，我們仍然可以做「五輪快速 mock + 現場 cue」組合包，重點在 Marketplace + Bar Raiser 兩輪。
寫在最後
Uber DS 不是一個能「刷題刷出來」的職缺。它考的是業務直覺 + 溝通框架 + 雙邊市場理解這種偏經驗型能力，單刷 LeetCode SQL 50 是遠遠不夠的。如果你正在準備 Uber 的 VO 或 Onsite，可以微信 Coding0201 聯繫，傳職缺 JD + 目前流程節點截圖，先做職缺線判定，再排 VO 輔助 / VO 代面 節奏。
需要面試真題？ 立刻聯繫微信 Coding0201，取得真題。
聯絡方式
- 微信：Coding0201
- Email: [email protected]
- Telegram: @OAVOProxy