資料科學家面試準備：2026 年完整指南

2026年資料科學家面試為什麼是這樣的

2026年的資料科學家這個職位與五年前已經不是同一種工作了。兩個結構性的變化從兩個方向壓縮了這個職位的範圍。從建模角度，ML工程師吸收了生產化的工作——任何部署到服務棧的東西現在是MLE的工作，而不是資料科學家的。從分析角度，具有強大dbt和資料倉儲技能的"分析工程師"吸收了儀表板和指標定義的工作。那麼留在中間的——也就是現在大多數"資料科學家"職位所處的位置——就是產品資料科學：掌管實驗、指標設計以及產品決策背後統計學嚴謹性的職位。

這對面試準備很重要，因為面試流程已經追蹤了角色的變化。五年前的資料科學家面試流程是60%的建模和40%的SQL。到了2026年，這個比例已經更接近60%的SQL和實驗設計、25%的產品和指標理解，以及15%的建模——當建模輪次出現時，它越來越多地是一個"案例研究"而不是程式設計問題。如果在準備中權重分配錯誤，你會在Kaggle風格的競賽上投入過多，而實際面試問的卻是如何診斷指標下降。

還有第二條賽道——在仍然區分研究科學家、ML工程師和應用資料科學家的公司中擔任ML應用型資料科學家的職位（Netflix、Stripe、Anthropic、DeepMind在他們以資料科學家職位招募的有限情況下）。這些面試流程將權重倒轉回約50%的建模深度，案例研究輪次需要深入三層——特徵工程、評估方法論、線上評估——而不是淺嘗輒止。如果你的目標是這些職位，就要相應地準備；如果你的目標是Meta或Airbnb，則不需要。

2026年資料科學家面試流程，逐階段分析

一個典型的2026年資料科學家面試流程在三到五週內進行四到六個階段。具體的組成因公司和賽道而異，但總體框架是一致的。

**招募人員篩選（30分鐘）。**主要是後勤和薪資期望，加上一些"自我介紹"的探問。這裡的訊號是你是否能用清楚的英文表述你曾經處理過的問題型別——不要充滿術語，也不要過度謙虛。兩到三個清晰的專案描述，每個都與一個可衡量的業務成果聯絡起來，這樣就能進入下一輪。

**SQL/程式設計篩選（45–60分鐘）。**這是技術篩選。在StrataScratch、DataLemur、Coderpad或HackerRank上進行即時編碼——取決於公司。兩到三個中等難度的SQL問題，偶爾還有一個Python資料操作問題。標準是第一次執行時的正確性、體面的變數命名，以及對面試官沒有問到的邊界情況的解釋。時間壓力是真實的；大多數候選人因為把聯接過度複雜化而失敗。

**現場或虛擬現場（4–5個輪次，通常每輪45分鐘）。**這是面試流程按公司分化的地方：

• Meta進行SQL深度挖掘、產品/指標理解輪次、A/B測試輪次和行為評估輪次（"你最自豪的專案是什麼"）。產品輪次權重最大。
• Google範圍更廣：SQL、統計學、ML案例研究、產品輪次和"Google特質"行為評估。ML案例的存在比Meta更明顯。
• Amazon以領導力原則驅動；預期每一輪都會包含LP（領導力原則）的探問，加上技術內容。SQL很短；統計學很短；特定於資料科學的輪次通常是以領導力原則語言表述的指標設計問題。
• Netflix是戰略思維的異類——輪次較少，每輪預期訊號更強，強調寫作。你可能被要求寫一份一頁的備忘錄來解釋你的分析。
• Airbnb重視主機端指標（"你如何衡量主機流失？"），並進行一個較長的產品輪次。
• ML研究傾向的公司（DeepMind、Anthropic、OpenAI在他們以資料科學家職位招募的有限情況下）除了標準輪次外，還進行論文討論輪次和深度建模輪次。

**招募經理輪次（45分鐘）。**通常安排在最後，有時在技術輪次之間。技術含量較少，更多關於適配度以及你如何規劃前90天。資深候選人應該預期戰略性問題——"這個團隊應該追蹤但目前沒有追蹤的最重要指標是什麼？"

從第一次招募人員電話到收到Offer的總時間投入很少少於三週，通常需要五到六週。根據這個週期來規劃你的準備，而不是圍繞某一場關鍵的面試。

SQL 輪: 2026 年重點考察內容

SQL 篩選是大多數候選人失去 offer 的地方，「我懂 SQL」和「我能通過 60 分鐘 SQL 篩選」之間的實際差距比很多候選人想像的要大。有三類問題是考察重點。

視窗函式 — 幾乎每次都會考。反覆出現的具體函式包括：ROW_NUMBER()、RANK()、DENSE_RANK() 用於按組取前 N 個；LAG() 和 LEAD() 用於期間環比變化；SUM() OVER (PARTITION BY ... ORDER BY ...) 用於累計求和。如果你無法快速寫出按組前 N 個的查詢，就會失敗。常見的誤區是用自連線或相關子查詢，而視窗函式五行就能搞定。

CTEs 和多步驟轉換 — 現代規範做法。超過單個 JOIN 的複雜邏輯都應該寫成 CTE 鏈，名字要清晰，每步只做一件事。面試官既關注 可讀性 也關注正確性；一個 40 行、命名清晰的 CTE 鏈永遠勝過一個 12 行巢狀子查詢。

四個經典模式:

1. 按組前 N 個 （找出各地區消費最高的前 3 個客戶）— 用 RANK() 或 ROW_NUMBER() 的視窗函式，按排名篩選。
2. 留存與佇列分析 （1 月新註冊使用者中有多少在 2 月迴歸）— 按 user_id 自連線配合日期計算，或用視窗函式標記活躍天。
3. 漏斗轉換 （註冊 → 啟用 → 首次購買）— 分階段的 CTE，使用 LEFT JOIN 或 EXISTS 檢驗，計算各階段的轉換率。
4. 會話化 （把事件行按會話分組，連續事件間隔在 30 分鐘內）— 用 LAG() 計算時間間隔，再對「新會話」標誌求累計和。

最常見的錯誤是粒度搞錯。如果輸出應該是每個使用者-天一行，但你不小心寫成了每個事件一行，所有後續的計數都會相差數個數量級。在寫查詢前 要明確說出輸出的粒度，寫完後用簡單的 SELECT COUNT(*) 驗證。

統計與機率輪

統計輪在各公司間差異最大。有些考理論知識（貝葉斯推導、分佈性質）；有些考實際應用（「這個場景你會用什麼檢驗？」）。三個子類覆蓋了大多數常見題型。

貝葉斯/條件機率。 蒙提霍爾問題出奇頻繁，還有它的變體 — 「兩枚硬幣，一枚公正一枚有偏，你丟擲來看到正面，P(有偏) 是多少？」— 幾乎每家公司都問。套路是寫出貝葉斯定理，確認先驗、似然和證據，然後計算。關鍵是在白板上邊講邊做；答案對了是必要條件但不充分。

分佈與何時使用。 正態近似很有用，但很多人過度使用。面試官想聽的是：「我這裡會假設正態分佈，因為樣本量足夠大，CLT 適用，但我會檢查殘差來驗證；如果原始資料有重尾，我會用 t 分佈或非引數方法。」既說出假設，又說出驗證方法，這是高階訊號。

假設檢驗。 標準框架是：確認指標型別（比例、均值、計數、比率），檢查前提條件（獨立性、正態性、樣本量），選擇檢驗方法（比例用 z 檢驗、均值用 t 檢驗、分類資料用卡方檢驗、非正態用曼-惠特尼檢驗），陳述零假設和對立假設，定義顯著性水平，討論多重比較修正（如適用）。對任何一個場景，你應該能在 90 秒內走完這個流程。

置信區間。 陷阱在於解釋。「真實均值有 95% 的機率在這個區間裡」是 錯誤的 — 頻率學派置信區間不對引數做機率陳述。正確說法是：「如果我重複這個實驗很多次，95% 的構造區間會包含真實均值。」說錯了，懂統計的面試官會留下不好的印象。

A/B 測試與實驗：基礎工作

這是在產品資料科學公司（Meta、Airbnb、Uber）中權重最大的面試輪次。最少要覆蓋以下幾點：

1. 假設 — 你認為會發生什麼以及為什麼？要與行為機制相關聯，而不僅僅是「我們認為這會很好」。
2. 指標 — 主要成功指標、次要指標、保護性指標。資深候選人在被問之前總是會主動指定保護性指標。
3. 功效計算 — 要以 80% 的功效和 5% 的顯著性水平檢測 X% 的提升，需要多少樣本？你應該能夠使用經驗法則 n ≈ 16 × σ² / δ² 每組樣本量進行估算，無需計算器。
4. 隨機化單位 — 使用者、會話、裝置？面試官會深入探究；你需要有意識地選擇。
5. 保護性指標和 SRM 檢查 — 樣本比例不匹配（實際分組偏離預期的 50/50）是破損實驗最常見的訊號，資深候選人在報告結果前會檢查這一點。
6. 分析 — 點估計、置信區間、p 值（如需要，進行多重比較校正），以及統計顯著性與實際顯著性的區別。
7. 決策 — 釋出、不釋出或迭代，明確說明權衡。

面試官會深入探究的陷阱：

• 新奇效應。 處理組在第一週表現很好，到第三週有所回落，因為使用者只是在探索新功能。
• 網路效應。 Facebook News Feed 的經典陷阱 — 如果處理改變了誰看到什麼，你無法按使用者隨機化，因為對照組被處理組使用者的行為所汙染。面試官有時會問「如果我們在測試市場排名變化呢？」他們想聽到網路干擾的框架。
• 稀釋。 如果只有 10% 的使用者看到該功能，全體人口的提升是那 10% 的提升乘以 10%。忘記這一點會將「5% 的提升」變成經不起推敲的營銷宣告。
• 主要指標 vs 保護性指標的權衡。 「如果收入增加但 DAU 下降怎麼辦？」資深答案涉及保護性指標的彈性和時間範圍問題 — 短期收入提升而犧牲長期參與度很少值得。

一個詳細的示例講解 — 為新主頁資訊流設計實驗 — 應該花費約 8-10 分鐘。練習到自動化程度。

ML 案例研究（產品資料科學視角）

當 ML 出現在產品資料科學面試中時，它以案例研究的形式出現，而不是編碼輪次。框架總是某種「為 X 設計排序器」的變體 — 資訊流排序、搜尋結果、推薦、廣告選擇。預期的結構：

1. 業務目標 — 我們實際上在最佳化什麼？參與度、收入、長期留存？資深訊號是即使代理指標是短期的，也要說出長期目標。
2. 標籤 — 正類和負類是什麼？標籤如何生成，這會引入什麼偏差？（位置偏差、選擇偏差、冷啟動問題。）
3. 特徵 — 三到五個類別：使用者特徵、物品特徵、上下文特徵、互動特徵，以及（對於序列感知模型）最近歷史特徵。
4. 模型類別 — Gradient-boosted Trees 作為主力預設選擇，在資料和訊號合理的地方使用深度學習。資深候選人會說出權衡 — 可解釋性、訓練成本、線上推理延遲 — 而不是盲目跟風。
5. 離線評估 — 分類用 AUC-ROC，排序用 NDCG，迴歸用 RMSE。陷阱是停在這裡；離線指標與線上業務指標的相關性較弱，資深候選人會指出這一點。
6. 線上評估 — A/B 測試設計、主要指標和保護性指標、迴圈回到實驗輪次。

按級別預期的誠實深度：L4（初級）你可以描述每個步驟。L5（中級）你可以在每個步驟上論證權衡。L6（資深）你可以識別這個案例研究不尋常的兩三個步驟 — 什麼讓它比教科書框架更具挑戰性 — 以及你如何處理它們。

產品/指標輪次：DAU 下降

幾乎每個進行產品資料科學面試的公司都會問標誌性的產品輪次題，通常是這樣的變體：「DAU 環比下降了 5%。你會怎樣診斷？」

預期框架，即時執行：

1. 首先驗證資料。 指標是否真的下降，或這只是資料記錄問題？檢查日誌管道、檢查上游變化、查詢當日部分資料。
2. 分段。 按地理位置、平台、作業系統、國家、使用者佇列、獲取渠道。下降很少是均勻的；找到分段可以定位原因。
3. 按行為分解。 DAU = 新使用者 + 回訪使用者。新使用者註冊下降了？回訪使用者留存下降了？這些有完全不同的原因。
4. 按漏斗分解。 在每個行為組內：應用開啟下降了？開啟到參與的轉化率下降了？每個步驟有不同的上游原因。
5. 與外部事件交叉參考。 產品釋出（你的和競爭對手的）、新聞週期、假日、付費營銷變化、基礎設施事件。
6. 形成假設，設計驗證。 一旦你有了候選解釋，什麼資料會駁斥它？

在 Meta 和 Google，預期的輸出是「指標樹」— 顯示每個輸入及其變化相對幅度的指標的視覺化分解。資深候選人在談話前畫出樹；初級候選人先談話，永遠到不了樹。

即時 AI 助手在資料科學面試中的幫助範圍 — 以及不適用的情況

要誠實對待這一點。在資料科學面試過程中，有些環節 AI 能幫你走大部分距離，但有些環節會讓你顯得很不專業。下面的表格是我們對自己使用者的建議。

Feature	SQL	統計	A/B 測試	機器學習案例	產品/指標	行為
AI 助手質量	優秀	良好	強大	強大	中等	強大
延遲要求	低於 200 毫秒（現場編碼）	對話式	對話式	對話式	對話式	對話式
隱蔽要求	高（螢幕共用）	中等	中等	中等	中等	中等
倫理接受度	有爭議	舒適	舒適	舒適	舒適	個人判斷
推薦使用方式	接近逐字指令碼	思維輔助	框架提示	大綱 + 自己補充	頭腦風暴；為自己辯護	僅大綱 — 用你自己的聲音說出來

誠實的總結：SQL 面試是 AI 助手最接近替你完成工作的地方 — 語法很嚴格，從提示詞到可用查詢的編輯距離很小，而且像 Acedly 這樣的優秀助手可以直接讀取編輯器。在統計學和 A/B 測試面試中，AI 在找到正確的框架和正確的測試方面極其有用，但當面試官深入追問時，你仍然需要為自己的答案辯護。在產品/指標面試中，AI 是你的頭腦風暴夥伴，但無法替你辯護答案 — 面試官會問「為什麼是這個細分，而不是那個？」，你需要有自己的觀點。在行為面試中，AI 可以產生一個結構（情境-任務-行動-結果），但內容必須是你的，用你自己的聲音說出來，否則會聽起來很生硬。

Acedly 在現場資料科學面試中的表現

Acedly 是為現場人類面試而構建的，你可以控制資訊披露。具體來說，對於資料科學家面試，三件事很重要：

延遲。 端到端中位延遲約為 98 毫秒 — 從話語結束到第一個渲染詞元的時間。這個預算在 SQL 編碼螢幕中最為重要，因為「AI 能幫助」和「AI 太慢而無法幫助」之間的差異就是自己寫答案和複製答案的區別。

編碼平台編輯器讀取。 大多數資料科學 SQL 面試在 Coderpad 或 HackerRank 上執行 — 這兩個已驗證的平台都允許 Acedly 讀取問題陳述、模式和候選人已寫的部分查詢，並使用這三個作為基礎上下文。只聽語音的 copilot 會忽視模式資訊，這意味著 SQL 建議會更糟。

多模型路由。 SQL 問題路由到 DeepSeek 進行程式碼生成；統計和機率問題路由到 Claude 以獲得推理質量；產品/指標問題路由到 GPT 以獲得更廣泛的業務背景。路由器按問題選擇，而不是按會話選擇。

八個已驗證的平台。 Zoom、Microsoft Teams、Google Meet、Webex、Lark/Feishu、Amazon Chime、Coderpad、HackerRank。這些平台共同覆蓋了 2026 年大約 95% 的專業資料科學面試平台。

12+ 種程式語言，包括 SQL。 Python、R、SQL（PostgreSQL、MySQL、BigQuery、Snowflake 方言）、Scala、Java、JavaScript/TypeScript、Go、Rust、C++、Julia、MATLAB、Bash。SQL 方言檢測很重要，因為視窗函式語法在 Postgres 和 MySQL 之間略有不同。

四周的DS面試準備計劃

如果你有四周的時間，下面的日程表是一個可行的分配方案。如果你的目標是非標準職缺，請調整權重。

第一週 — SQL鑽練。 每天兩小時。在StrataScratch或DataLemur上完成50道題，重點放在視窗函式、留存率/佇列模式和漏斗查詢上。每道題都要寫一句總結：用了哪個模式、用了哪個視窗函式、資料粒度是什麼。到週末，你應該能從第一句話就識別出top-N-per-group。

第二週 — 統計、機率和A/B測試。 一小時理論（複習分佈、假設檢驗、貝葉斯），一小時應用 — 做十道經典A/B測試題（樣本量、新穎性效應、網路效應、稀釋效應）。反覆練習七步法則直到自動化。閱讀：Kohavi、Tang、Xu的Trustworthy Online Controlled Experiments涵蓋了幾乎所有會被問到的內容。

第三週 — 產品和指標模擬案例。 每天做三個模擬案例，每個30分鐘，涵蓋各種指標：DAU下降、使用者參與度下降、轉化率下降、流失率上升。每次都用指標樹框架。錄下自己講話；回放；前三次很糟糕，第十次就自動化了。

第四周 — 公司特定。 如果你的目標是Meta，從Decode and Conquer軌道鑽練產品案例。如果你的目標是Google，擴充套件到SQL、統計和ML案例。如果你的目標是Amazon，準備一個與LP相對映的投資組合，每個原則兩個故事。最後48小時：休息。做簡單的題，充分睡眠，通過認識到自己已經完成了工作來實現精神上的恢復。

跨越每一週的單一最強槓桿習慣是：為你解決的每個問題寫一句總結。50道題後，你就會有自己的模式識別參考表不斷積累。100道題後，你會在夢中診斷DAU下降。

常見問題

DS面試準備要花多長時間？

2026年獲得DS offer需要知道深度學習嗎？

SQL與Python：DS面試中哪個測試更多？

產品DS和ML應用DS面試有什麼區別？

我可以在現場SQL篩選中使用AI助手嗎？

2026年哪些公司仍在招募DS？