資料工程師面試題目：SQL、管道和高壓下的可靠性

這個職位的面試流程圍繞一個核心關切而建立：你是否能在規模上正確地移動和轉換資料，而無需任何人監督。這體現在四個相互連接的技能領域：SQL 和資料建模、跨 ETL 和 ELT 模式的管道設計、故障下的可靠性，以及與非程式設計人員溝通權衡的判斷力。

大多數面試流程混合了實踐性的 SQL 輪次、聚焦於管道或資料平台的系統設計輪次，以及探查你如何處理破損資料、缺失要求和與資料科學家或分析師分歧的行為輪次。某些公司也會進行帶回家的練習，讓你從原始資料集構建一個小型管道，這測試的是相同的技能，但沒有現場觀眾。

面試官不僅是評估你的查詢是否返回正確的行。他們在聽你如何敘述你的推理：為什麼你選擇窗口函數而不是自連接，為什麼你選擇了增量加載而不是完全重新整理，為什麼你會對行計數漂移發出警報而不只是空值計數。一個能清晰解釋稍微粗糙答案的候選者通常會贏過一個嘟囔著正確答案的人。

在你的面試前，列出你自己工作中的管道、表或事件清單，能夠在兩三句話內描述。你將在整個 SQL、設計和行為輪次中不斷提到它們。

即使在主要運行 Spark 或 dbt 的公司，SQL 仍然是資料工程師面試中最常見的門檻。期望提示如：寫一個查詢返回每個客戶的最近訂單、找到每個帳戶的日期序列中的間隙、計算每日收入的運行七日總計，或去重行而不失去最新版本。

窗口函數不斷出現。ROW_NUMBER() 帶 PARTITION BY 子句是「每個鍵的最新記錄」問題的標準工具；LAG() 和 LEAD() 處理間隙-島和變化檢測問題；SUM() OVER 有序窗口處理運行總計而不需要自連接。面試官也希望你大聲推理查詢計劃：優化器可能選擇的連接順序、索引可能有幫助的地方，以及查詢速度緩慢是因為缺失分區過濾器而不是壞連接的情況。

資料建模題目測試一個不同的技能：在衝突約束下的架構設計。一個常見的提示是為電子商務或訂閱資料集設計星型架構，帶有訂單或事件的事實表以及客戶、產品和時間的維度表。準備好解釋緩慢變化的維度：何時第 1 類更新（覆蓋）就足夠，何時你需要第 2 類（新行、有效日期）來保留「購買時客戶段」等指標的歷史。

你也應該能夠為正規化權衡辯護。OLTP 系統傾向於正規化表來保護寫入一致性；分析倉庫通常有意反正規化，使 BI 工具可以查詢一個寬表而不是五個連接。命名該權衡，而不是將一種風格視為普遍正確，是將強答案與教科書答案分開的原因。

管道設計題目要求你概述原始資料如何成為可信表。一個典型的提示：設計一個管道，攝取點擊流事件並產生一個每日活躍用戶表，產品團隊可以每天早上查詢。一個強答案從來源開始，而不是工具：資料來自哪裡，多久到達一次，可接受的延遲是多少，批次遲到或流掉線時會發生什麼。

期望明確比較 ETL 和 ELT。在 ETL 中，你在將資料加載到倉庫前轉換資料，這適合較小的體積或嚴格的合規需求。在 ELT 中，你首先加載原始資料，然後在倉庫內用 dbt 等工具進行轉換，這現在是更常見的模式，因為倉庫計算便宜且它保留了原始歷史以便重新處理。能夠解釋為什麼你會為給定資料源選擇一個而不是另一個。

協調問題測試你是否考慮故障，而不僅是樂觀路徑。面試官想聽到 Airflow 或 Dagster 等工具中的 DAG、任務級重試、用於在中途更改的架構的回填，以及僅處理新的或更改的行的增量加載，而不是每次運行都重新處理整個表。冪等性是一個最喜歡的後續：如果任務在中途失敗並重新運行，它是否會產生重複行或相同的正確結果？

流特定問題在具有即時要求的公司中出現得更多。你可能被要求比較基於 Kafka 的流管道與微批量方法，或解釋恰好一次與至少一次交付語義，以及當系統只保證至少一次時，你會在下游使用什麼去重策略。

資料工程師面試題目中的可靠性問題通常以一個情景開始：儀表盤今天早上顯示零收入，請告訴我你如何調試它。一個好答案按順序從管道向後工作，而不是隨機猜測。檢查來源系統是否實際產生了資料、檢查攝取工作的日誌和行計數、檢查轉換層是否有失敗或默默跳過的運行，以及檢查儀表盤本身是否指向一個陳舊表或快取。

資料質量檢查是其自身上的一個頻繁主題。面試官想要細節：必需欄位的空值率檢查、針對歷史基線的行計數異常檢測、當表在其預期窗口內未更新時發出警報的新鮮度檢查，以及在上游架構更改後捕獲孤立外鍵的引用完整性檢查。dbt 測試或 Great Expectations 等工具經常出現，但命名工具不如解釋你實際會檢查什麼以及該檢查如何捕獲你關心的故障模式那麼重要。

你也應該期望關於資料新鮮度的 SLA 和 SLO 的問題，以及你將如何設計警報，使正確的人為真實問題受到頁面，而不會因預期變異的噪音而淹沒團隊。談論你會如何設置閾值、按嚴重性路由警報，以及避免每天觸發的警報被忽略的方式。

一個相關的行為線是事後分析：描述一個壞資料在任何人發現它之前到達報告或模型的事件。面試官在聽所有權和流程更改，而不是指責。一個強答案命名了根本原因、立即修復和你之後添加的具體保護措施，例如新的驗證檢查或如何審查回填的更改。

資料工程師的行為題目較少關注個人英雄主義，更多關於你如何處理來自依賴你的管道的人員的競爭需求。常見提示包括：講述一個時代利益相關者需要資料的速度快於你的管道可以交付的時代；講述你與資料科學家或分析師對架構或指標定義的分歧；講述一個時代你在壞資料已經被用於報告後發現了它。

使用 STAR，但將行為部分保持對資料工作特定。對於「已在壞報告中使用的資料」故事，解釋你如何發現了錯誤、你如何告訴誰以及多快、你如何更正了下游數字，以及你添加了什麼驗證，使相同的錯誤類不能再滑過。面試官想看到你像軟體工程師對待生產中斷一樣對待資料事件，而不是作為一個小不便。

對於架構或指標分歧，表明你可以堅持技術立場，同時仍然達到團隊可以接受的決定。解釋你所維護的權衡，例如查詢性能與儲存成本，或更嚴格的架構與更快的新資料源上線，以及你如何在不簡單地覆蓋另一個人的情況下解決它。

優先順序題目也很常見：你如何在修復一個不可靠的管道、構建一個利益相關者等待的新資料來源和支付舊模型中的技術債務之間做出決定。一個可信的答案權衡商業影響、如果不可靠的管道再次失敗的爆炸半徑，以及團隊在債務開始減緩每個未來變化前能容忍多久。

這些題目在紙上比出聲音容易回答。在清晰的口語句子中解釋窗口函數、管道設計或事件事後分析是一個與寫正確的 SQL 或繪製正確的 DAG 不同的技能，面試官評估解釋和答案一樣多。

在你接觸鍵盤前練習敘述 SQL 解決方案：陳述方法、命名你將使用的窗口函數或連接策略，然後寫查詢。對於管道設計提示，練習通過來源、延遲要求、轉換邏輯和故障處理按該順序進行，使結構在壓力下成為自動的。對於行為故事，排練直到技術細節保持具體而不變成獨白。

記錄你自己回答其中幾個題目並聽回去的填充詞、在到達重點前的漫無邊際的設置或管道演練中跳過的步驟。SayNow AI 可以幫助你出聲練習資料工程師面試題目，提供關於清晰度和步調的反饋，使你的技術推理能夠傳達得如同它在頁面上讀起來一樣自信。