資料工程師面試題，依輪次劃分

你可能一直按照軟體工程師面試的方式準備，想知道資料工程師面試有什麼不同。本節整理這些面試反覆出現的輪次，讓你把精力放在真正拉開候選人差距的兩個環節上。技術篩選環節很少是拿不到offer的原因。

• SQL。視窗函式、去重和查詢效能，通常是現場手寫。
• 資料建模。為給定的業務場景設計資料表結構，並為你選擇的粒度辯護。
• 管線與ETL設計。一個聚焦於資料流動的開放式系統設計輪次。
• 分散式處理。某個框架實際上是如何執行你的任務的，以及它為什麼變慢。
• 寫程式。Python或Scala，通常比軟體工程輪次要輕。
• 行為面試。值班事故、壞掉的儀表板，以及昨天就想要結果的相關方。

這些職稱與分析工程和平台類職位高度重疊，因此考察內容會有所不同。相關的分角色題庫請見依角色劃分的面試問題樞紐頁。

SQL

• 為一張表去重，每個鍵只保留最新的一列。
• 寫一個查詢，用30分鐘不活躍間隔計算每個使用者的工作階段數。
• 在一個查詢裡同時計算累計總和與月增減變化。
• 找出昨天快照中存在、但今天快照中缺失的列。
• QUALIFY是做什麼用的？如果不用它，你會怎麼寫？
• 這個查詢掃描了十億列資料，耗時二十分鐘。你會如何診斷？
• 解釋分區（partitioning）和叢集（clustering）的差異，以及各自適用的場景。

資料建模

• 為一個線上交易市集的訂單歷史設計資料表結構。你的事實表粒度是什麼？
• 解釋星型模式，以及你什麼時候會主動進一步反正規化。
• 什麼是緩變維度？你會如何實作二型？
• 某相關方希望歷史報表反映客戶目前所在的地區。這會導致什麼問題？
• 你會如何為一個亂序到達的事件流建模？
• 什麼時候你會選擇寬表而不是正規化模型？

建模輪次獎勵的是敢於確定一種粒度並為之辯護的人。那些描述了三種可能設計卻始終沒有做出選擇的候選人，得分通常低於選定一個合理設計並指出其弱點的候選人。

管線與ETL設計

• 設計一個將每日交易資料載入資料倉儲以供報表使用的管線。
• 上游資料源把昨天的資料又送了一次。你的任務會發生什麼事？
• 你會如何讓一個管線具備冪等性？這對重跑為什麼重要？
• 你會如何在不打斷每日載入的情況下回填兩年的歷史資料？
• 某個分區已經關閉三天後，延遲到達的資料才出現。你會怎麼做？
• 你會如何偵測出一個管線運作成功了，但產出的資料是錯的？
• 你會監控什麼指標？凌晨三點會因為什麼而呼叫你？

分散式處理與串流處理

• 什麼會導致shuffle？為什麼它的代價很高？
• 你的任務執行得很慢，其中一個task耗時遠超其他task。發生了什麼事？
• 解釋資料傾斜（data skew），以及兩種應對方法。
• 什麼時候你會選擇串流處理而不是排程批次任務？
• 「恰好一次」處理到底保證了什麼？在哪些情況下它並不成立？
• 在視窗聚合中，水位線（watermark）是如何處理亂序事件的？

請注意，這些問題裡很少要求你說出一個具體工具的名字。說出工具名只是回答的開始，而不是答案本身。後續追問永遠是為什麼，以及會出什麼問題。

閱讀這些題目清單能建立辨識能力。而設計輪次考察的是另一種能力：在有人不斷用故障情境打斷你的情況下，仍能把整個系統裝在腦子裡。這種能力只能透過大聲說出你的設計來獲得。

• 用十五分鐘畫出並講述一個管線。資料源、落地、轉換、服務，加上每個環節可能如何失敗。
• 攻擊你自己的設計。每次練習結束後，問自己：重跑會怎樣？延遲資料會怎樣？schema變更會怎樣？
• 準備好一個規模數字。每天的列數、資料大小、延遲預算。先說出你假設的規模會加分。
• 手寫SQL。現場輪次常常只給一個沒有自動補全、也不能執行的純文字編輯器。
• 認真演練一個事故故事。出了什麼問題、你是怎麼發現的、你做了什麼改動讓它不再發生。

一位在批次管線上有六年經驗的資料工程師，準備時複習了框架內部原理，卻在「上游資料源重新傳送了昨天的檔案」這個問題上卡住了，因為她過去只是手動處理過，從沒有把它講清楚過。知識是有的，但口頭表達沒有跟上。帶著追問練習設計輪次，正是模擬面試模式存在的意義。