去年北美數(shù)據(jù)工程師崗位平均收到247份簡歷，技術(shù)篩選環(huán)節(jié)吃掉HR團隊60%工時。Apache Spark（阿帕奇Spark，分布式計算引擎）作為數(shù)據(jù)管道核心框架，面試題庫質(zhì)量直接決定招聘效率——但市面上90%的題庫要么太淺、要么答案過時。

這份覆蓋初級到架構(gòu)師層級的100題清單，正在硅谷招聘圈悄悄流傳。它的特殊之處在于：每道題都配了「糟糕答案」和「標(biāo)準(zhǔn)答案」的對比，像X光片一樣照出候選人的真實水位。

為什么面試官需要結(jié)構(gòu)化題庫

技術(shù)招聘有個經(jīng)典困境：HR不懂Spark的shuffle機制，工程師沒時間篩簡歷。結(jié)構(gòu)化題庫把技術(shù)深度拆解成可對比的答題維度，讓非技術(shù)招聘官也能識別「看起來會，實際不會」的簡歷包裝。

題庫設(shè)計遵循兩條鐵律。第一，按難度分層——基礎(chǔ)概念、生產(chǎn)調(diào)優(yōu)、架構(gòu)設(shè)計各占三分之一。第二，答案必須可驗證，比如「DataFrame和Dataset區(qū)別」這道題，糟糕答案說「Dataset是DataFrame別名」，標(biāo)準(zhǔn)答案要答出編譯期類型安全和語言綁定差異。

這種設(shè)計讓簡歷篩選從「關(guān)鍵詞匹配」變成「能力對標(biāo)」。

對候選人而言，題庫的價值在暴露盲區(qū)。很多人以為自己懂Spark，直到被問到「RDD何時還會用到」才意識到——DataFrame API覆蓋95%場景，但遺留代碼和自定義分區(qū)器（partitioner）仍需要RDD操作。這種細(xì)節(jié)不會出現(xiàn)在官方文檔的顯眼位置。

100題的骨架：從API到生產(chǎn)現(xiàn)場

題庫前20題錨定基礎(chǔ)概念。SparkSession（Spark會話，2.0版本后的統(tǒng)一入口）取代了三Context分裂的歷史包袱；惰性求值（lazy evaluation）機制解釋了為什么代碼寫了半天沒報錯也沒結(jié)果——直到遇到count或write這類動作（action）才觸發(fā)實際計算。

中間50題進入生產(chǎn)深水區(qū)。分區(qū)（partition）數(shù)量如何決定并行度？Parquet和ORC格式為什么能下推謂詞（predicate pushdown）？這些問題區(qū)分「寫過Spark代碼」和「調(diào)過Spark集群」兩種經(jīng)驗層級。

最后30題面向架構(gòu)師候選人。驅(qū)動程序（driver program）如何將代碼轉(zhuǎn)成DAG（有向無環(huán)圖）并調(diào)度執(zhí)行？故障恢復(fù)時，引擎為什么靠血緣（lineage）重算而非數(shù)據(jù)副本？這些設(shè)計哲學(xué)層面的追問，篩掉的是只會調(diào)API的「框架操作員」。

每道題的糟糕答案都經(jīng)過精心設(shè)計——它們不是胡編，而是真實面試中高頻出現(xiàn)的誤解。

比如「Spark容錯機制」這道題，「把數(shù)據(jù)復(fù)制到所有節(jié)點」聽起來合理，實際卻完全違背分布式系統(tǒng)的設(shè)計常識。正確機制是血緣重算：每個DataFrame記錄自己的變換歷史，分區(qū)丟失時從上游節(jié)點重新計算，而非依賴冗余存儲。

題庫背后的招聘邏輯變遷

五年前Spark面試還在問「RDD vs DataFrame」，現(xiàn)在同一道題的合格線已經(jīng)變成「Dataset的類型安全在Scala和Java中如何實現(xiàn)，Python為什么做不到」。技術(shù)棧迭代倒逼面試標(biāo)準(zhǔn)升級，但多數(shù)公司的題庫更新周期長達(dá)18個月。

這份100題清單的另一個隱性價值：統(tǒng)一面試官的評分尺度。同一場面試，不同工程師的提問隨機性很大——有人深挖SQL優(yōu)化，有人追問流處理語義。結(jié)構(gòu)化題庫讓「通過」和「不通過」有明確的分界線，減少招聘決策的主觀噪音。

對數(shù)據(jù)工程師求職者，題庫的使用方式也在進化。早期做法是背答案，現(xiàn)在更流行的策略是「反向工程」——從標(biāo)準(zhǔn)答案倒推知識圖譜，比如看到「shuffle內(nèi)部機制」就意識到需要補磁盤I/O和內(nèi)存管理的交叉知識。

題庫作者建議搭配Spark開發(fā)者面試題一起使用，如果工作涉及應(yīng)用層代碼的話。

這種分層設(shè)計反映了一個行業(yè)現(xiàn)實：數(shù)據(jù)工程師的角色正在分裂。一部分人向下沉，專注集群調(diào)優(yōu)和資源治理；另一部分人向上走，用Spark作為執(zhí)行引擎構(gòu)建數(shù)據(jù)產(chǎn)品。同一套面試框架已經(jīng)裝不下這兩種職業(yè)路徑。

這份題庫在GitHub技術(shù)招聘板塊被fork了3400次，但討論區(qū)最熱的帖子卻是抱怨：「第47題的答案在Spark 3.4之后已經(jīng)過時」。技術(shù)文檔的半衰期正在縮短，靜態(tài)題庫的維護成本可能比想象中更高——當(dāng)社區(qū)還在爭論某道題的現(xiàn)行最佳實踐時，下一個LTS版本可能已經(jīng)改寫了底層實現(xiàn)。

如果你的團隊正在用Spark構(gòu)建實時特征平臺，你會把「精確一次語義（exactly-once semantics）」的考察權(quán)重調(diào)到多高？