数据工程师面试准备清单模板：SQL到Spark全覆盖
一句话总结
数据工程师面试不是考你会不会写SQL，而是考你在数据腐烂、模型崩溃、上下游扯皮的混乱现场里，能不能用工程思维兜底。真正的分水岭不在Spark调优有多深，而在你能否把"数据管道出错了"这句 shall 翻译成业务损失、修复路径和长期预防机制。
面试官想听的从来不是"我做过实时数仓"，而是"那套Flink作业凌晨三点挂了，我是怎么在三十分钟内让CFO的晨会报表不裸奔的"。准备这场面试的核心判断是：把自己从"写脚本的人"重新定位为"数据系统的可靠工程师"，否则你准备了再多LeetCode SQL，也会被系统设计的第三轮按在地上。
适合谁看
这篇文章写给三类人。第一类是正在从数据分析师转型数据工程师的候选人，你的SQL很强，但听到"数据建模"和"分布式事务"会本能往后缩，你需要知道面试官会在哪里识破你的虚张声势。
第二类是海外归国的资深数据开发，熟悉阿里云全家桶但对硅谷的面试文化水土不服——你不知道为什么自己讲了二十分钟Flink exactly-once，面试官却追问"如果Kafka consumer group rebalance了怎么办"。第三类是校招或一两年经验的候选人，手里拿着"数据工程师面试准备清单模板：SQL到Spark全覆盖"这样的关键词搜到这篇文章，以为能拿到一份可以勾选的to-do list，但你会在这里得到更残酷的东西：一份基于真实debrief会议的裁决书，告诉你哪些准备动作是表演，哪些才是真正的入场券。
不适合的人是纯数据科学家和纯平台SRE。如果你的目标是做模型而不是管道，或者你的日常是调Kubernetes而不是调join策略，这篇文章的切口会偏。数据工程师的模糊边界正在吞噬很多title，但面试房间的考察点不会跟着膨胀。
面试官在系统设计上到底想听到什么
系统设计的十五分钟里，候选人最常犯的错是把数据管道画成一张完美的架构图。不是画架构图不对，而是面试官在等你主动撕开两个口子：数据质量治理的故障域，以及成本与一致性的 trade-off 选择。
真实的场景是这样的。某次debrief会议上，一个候选人在白板画了Lambda架构，batch layer和speed layer分得很干净，实时流用Spark Streaming，离线用Spark SQL。我们问：如果speed layer产出了一条speed layer自己无法回溯的错误数据，batch layer的修正如何在业务可接受时延内覆盖它？
候选人开始讲merge逻辑，但从未主动定义"业务可接受时延"是多少分钟、由谁拍板、超标后的降级预案是什么。另一个候选人在同等复杂度的题目下，先问的是"这条管道服务的是不是财务对账场景"——得到确认后，他直接说"那batch layer的延迟容忍是一整天，但speed layer的错误必须在两小时窗口内人工拦截，否则会影响关账"。这是同一段技术，不同的工程判断力。
不是要你设计一个无懈可击的系统，而是要你暴露一个工程师在真实约束下的决策痕迹。另一个常考场景是数据倾斜。候选人背出"加盐"和"两阶段聚合"的不在少数，但面试官想听的不是方案名称，而是你在什么量级下发现倾斜、用什么指标监控、多少次试错后放弃自动优化改为人工分桶。
曾有一个内部晋升的候选人描述他处理过的skew：某张表按日期分区但热点用户集中在最新分区，导致单个executor内存溢出。他没有讲任何spark.sql.adaptive.enabled，而是说"我们当时算了笔账，手动把那个用户ID前缀拆成十六个桶，开发成本两小时，如果等A/B test验证自动优化要两周，业务等不起"。这种判断才是系统设计的得分点。
分布式系统的考察往往伪装成具体工具问题。问Kafka，不是问topic怎么建，是问"consumer lag告警了，但Grafana显示CPU正常，你的排查路径是什么"。正确答案是先区分lag是突增还是匀速累积，突增看broker端log segment是否触发compact导致fetch延迟，匀速累积看consumer是否poison pill进入死循环。
不是背出这些名词，而是展示你如何在无头公案中建立假设树。另一个候选人答成了"加consumer实例"，这是典型的把症状当病因。
> 📖 延伸阅读：转行PM薪资谈判指南2024：Amazon offer谈判技巧
SQL考察的不是语法，是数据直觉
LeetCode Hard SQL在数据工程师面试中的权重被严重高估了。不是完全不重要，而是它的功能更像守门而非选拔。真正拉开差距的是"业务SQL"——给你一张脏表、模糊需求、隐含假设，看你怎么在对话中逼出澄清问题。
某次面试中，题目是"计算过去三十天每个用户的活跃天数"。候选人A三十秒开始写COUNT(DISTINCT date)，被追问"活跃的定义是什么"时愣住。候选人B先问：用户跨时区怎么办，日期用UTC还是本地时间；如果用户在凌晨活跃，按哪个日期归属；
去重粒度是device还是user_id；三十天是滑动窗口还是自然月。这四个问题问完，面试官已经知道这个人做过真实业务，后面的代码写没写出来反而次要。
窗口函数是必考点，但不是考你会不会ROW_NUMBER()。曾有一个场景：求每个用户首次购买后的三十天内复购次数。陷阱在于"首次购买"可能触发全表扫描，如果数据量级是十亿级。
好的候选人会主动说"这里我假设用户维度有索引，如果没有，我会先物化一个首次购买时间的子表"。另一个层次是处理边界条件：如果用户在首次购买后第三十一天凌晨下单，按UTC算落不进窗口，按业务时区可能落进，你会怎么和PM沟通这个差异。不是每个面试官都会追问到这么细，但主动提这一嘴的人，debrief时的评语会是"有产品意识"。
JOIN的考察常常埋雷。不是考LEFT JOIN还是INNER JOIN，而是考你在什么场景下会主动选择丢失数据。一个经典陷阱：两张表JOIN，主表有十万用户，行为表有八万用户，要求"所有用户的最新行为"。
候选人写LEFT JOIN加ROW_NUMBER()，但面试官想问的是：如果那两万缺失用户是业务上必须追踪的流失信号，你的管道如何产出这份缺失报告，而不是让NULL默默流向下游。正确的工程思维是"JOIN的同时产出anti-join结果，作为数据质量监控的一部分"。
Spark与大数据生态：不是调参，是调试哲学
Spark的面试准备清单模板在网上泛滥，但真正能区分候选人的不是谁背的参数多。两个真实场景可以说明问题。
场景一：Spark作业在cluster模式下频繁失败，日志显示ExecutorLost。候选人开始调spark.executor.memory和spark.memory.fraction，这是标准错误。正确的第一反应是区分是OOM导致的killed by Y..."还是网络分区导致的连接断连。
前者看storage/execution memory配比，后者看YARN或K8s的node health。更进一步，好的候选人会追问：这个作业的历史成功运行时间分布是什么，失败是否集中在特定时段（比如其他部门大批量提交时抢资源），这决定了是参数问题还是调度策略问题。
场景二：面试官问Spark的shuffle优化。候选人背出"减少shuffle就是优化"——这是错的。不是减少shuffle，而是让shuffle发生在正确的位置、以正确的代价。
某次真实项目中，团队花了两周把四个reduce by key合并成一个，结果单个task数据量暴涨导致spill到磁盘，整体耗时反而增加。正确的判断是：shuffle的代价是网络+磁盘IO，不shuffle的代价是单个节点的内存+CPU，选择取决于集群的瓶颈资源是什么。面试官想听的永远是"取决于"，而不是"永远要"。
实时计算是整个面试中最容易露馅的领域。不是做过Flink或Spark Streaming就安全了。曾有一个候选人在简历上写"构建实时用户画像"，面试官问：从Kafka到HBase的latency要求是多少，达不到时如何降级，画像更新延迟一分钟对推荐系统的影响是？
候选人答不上来，因为"之前是算法团队提需求，我们只管接"。这种分工在真实公司存在，但面试房间里会被标记为"对业务上下文缺乏ownership"。
exactly-once semantics是另一个深坑。不是背出Flink的checkpoint机制就算过关，而是要解释在端到端场景下，exactly-once的边界在哪里。
比如Kafka到Flink是exactly-once，Flink到JDBC sink如果不是幂等写入，整体就退化为at-least-once。更好的候选人会主动讨论"我们业务上是否接受at-least-once加下游去重"，这涉及成本、复杂度和正确性的三角权衡。
> 📖 延伸阅读：Plaid PMculture指南2026
数据建模与仓库设计：隐形的分水岭
数据建模是面试中最被低估的环节，因为它不 flashy，但资深面试官会在这里投否决票。不是考星型模型和雪花模型的区别，而是考你在 schema 演进、缓慢变化维、退化维度这些真实泥潭里的选择。
一个具体的debrief案例。候选人在设计用户行为数仓时，把用户属性全量冗余到事实表。面试官问为什么，答"查询方便"。追问：如果用户等级每月更新，历史行为如何关联当时的等级？
候选人沉默。另一个候选人的设计是把user_dim做成SCD Type 2，有效时间戳区间管理，事实表只存代理键。这不是更复杂，是更正确——而且更贵，更慢。面试官想听的是你对这种 trade-off 的主动陈述："我选Type 2是因为财务审计要求历史可追溯，如果业务只关心最新状态，我会用Type 1加每日快照表"。
维度设计的另一个陷阱是"日期维度要不要自己做"。不是简单的要或不要，而是你的BI工具是什么，业务分析师的SQL水平如何，以及你是否要支持财年与日历年的双轨并行。曾有一个候选人说"我们用Trino，所有日期函数原生支持，不需要日期维度表"，这暴露了他没有处理过跨国业务——日本财年从四月开始，你的Trino函数能自动处理吗？
数据治理的考察往往在不经意处。面试官可能问：你的ETL失败了，下游有三张报表，两张给运营看，一张给高管看，恢复顺序是什么。标准答案不是"按重要性"，而是"按数据依赖的拓扑序，除非高管那张是监管报送有 deadline"。
但更好的答案是先问：失败的是哪一层，原始数据是否可重跑，重跑的 SLA 是多少，以及三张报表的容忍延迟分别是多少。这种追问本身就是 senior 的标志。
行为面试与跨部门冲突：你以为不考技术，其实考的是工程可信度
行为面试在数据工程师的考察中权重逐年上升，不是因为HR要凑时间，而是因为数据管道的可靠性最终是人的可靠性。一个管不住自己承诺的工程师，写的cron job 也守不住时。
最常见的错误是讲"我加班解决了问题"的故事。不是这个故事不好，是你的叙事角度暴露了你把自己当救火队员还是防火工程师。对比两个版本：
BAD版本："有一次数据管道凌晨挂了，我收到告警起来修复，三点恢复到六点，保证了第二天业务正常。"
GOOD版本："那次故障后我拉了一个复盘，发现根因是上游schema变更没有通知机制。我推动的是：第一，在数据血缘工具里加schema变更自动订阅；第二，把那个作业的失败重试从三次改成一次，避免错误数据放大；第三，把我和上游负责人的SLA写进团队wiki，不再是口头约定。"
不是解决了问题，而是问题不再以同样方式发生。这种叙事差异在debrief时会被标记为"有系统性思维"或"停留在执行层"。
跨部门冲突是必考题，因为数据工程师处于业务、算法、平台三方的张力中心。一个真实的hiring committee讨论案例：候选人说服算法团队接受更粗的聚合粒度以减少计算成本。BAD版本是"我算了一笔账，说服了他们"。
GOOD版本是"我先和算法确认了什么精度下模型AUC不会掉，然后和平台确认了这个资源可以挪给哪个高优先级任务，最后带着两个团队的共识去找老板拍板"。不是你会谈判，而是你知道工程决策在组织中的流动路径。
另一个高频场景是技术债与业务需求的平衡。面试官会问：你有一个月时间，十个需求，技术债压力也很大，怎么排期。陷阱答案是"按优先级排序"，因为真实世界没有干净的priority list。
正确的判断框架是：区分可逆决策和不可逆决策，不可逆的（如核心模型schema变更）必须留足验证时间；区分可自动化的和必须人工介入的，把自动化投入放在重复性最高的地方；以及，最不重要但最常被忽略的——明确告诉业务方哪些需求是"可以做但建议不做"，而不是默默接受然后延期。
准备清单
- 系统性拆解面试结构，用至少三个真实公司的JD反向推导考察重点。PM面试手册里有完整的硅谷数据岗面试实战复盘可以参考，尤其是系统设计轮次的评分逻辑。
- SQL准备聚焦业务场景题而非纯算法题，给自己设定"每个查询必须问出三个澄清问题"的强制训练，直到形成肌肉记忆。
- Spark调试准备两个真实故障案例，分别对应内存问题和调度问题，要能画出完整的排查决策树，不是背诵参数。
- 数据建模准备一套可复用的设计评审模板，包含SCD类型选择、退化维度处理、缓慢变化维的取舍依据，能对应到具体业务场景。
- 系统设计至少演练三个完整的数据管道设计，分别覆盖离线批处理、近实时流处理、和混合架构，每个设计必须包含故障域分析和降级策略。
- 行为面试准备五个故事，按STAR格式写但刻意练习在三十秒内切换到"系统性反思"模式，即事件-我的选择-长期机制-如果重来会怎么调整。
- 薪资谈判前摸清目标公司的薪酬结构：硅谷数据工程师Base $120K-$200K，RSU每年$30K-$200K（四年等额授予），Bonus目标值10%-20% of base。总包区间$160K-$500K，senior staff级别可突破。不是每个公司都接受"我还有其他offer"的谈判策略，有些需要具体竞品名称，有些反而反感。
常见错误
错误一：把"熟悉Spark"等同于"能讲清楚shuffle机制"。
BAD表现：面试官问Spark优化，候选人回答"减少shuffle，用broadcast join，调大executor内存"。
GOOD表现：候选人先说"我先确认一下，这个作业的问题是latency还是throughput，因为优化方向完全不同。如果是latency，我会先看stage的timeline找bottleneck；
如果是throughput，我可能要理解数据分布特征再决定"。然后展开一个具体案例：某次作业因为数据倾斜导致单个task运行两小时，最终通过salting把key打散，但代价是下游需要额外做一次merge，这个trade-off是和业务方确认过可接受的。
错误二：在系统设计题中回避数据质量话题。
BAD表现：画完架构图后，面试官问"如何保证数据质量"，候选人回答"加一些校验"。
GOOD表现：主动在架构图中标出三个质量检查点：接入时的schema validation（拦截格式错误）、转换时的业务规则校验（拦截逻辑错误）、产出后的同比环比监控（拦截漂移错误）。并且说明：每个检查点的告警阈值是和业务方共同制定的，不是技术团队自己拍脑袋。
举一个真实例子：某次校验规则太严导致合法数据被拦截，业务方投诉后，我们引入了采样白名单机制，而不是一刀切放松规则。
错误三：行为面试中过度强调个人英雄主义。
BAD表现："那个项目很难，但我加班加点做出来了，得到了老板认可。"
GOOD表现："那个项目初期我一个人扛了三个模块，但第二周我就发现这样下去会block全组进度。我发起的调整是：把其中一个模块拆给新来的同事，我花四小时写文档和pair coding，虽然短期我的时间更紧，但两周后我可以专注在关键路径上。这个决策的代价是初期我的加班时间增加了，但项目最终提前两天交付。"不是完成了任务，而是如何在约束下重新组织人和事。
FAQ
Q: 我没有大数据经验，只有传统关系型数据库背景，转数据工程师是不是没戏？
不是没戏，但你的准备策略必须调整。很多候选人犯的错误是硬补Spark和Hadoop，结果面试时一追问就露馅。正确的判断是：把你的关系型数据库经验转化为可迁移的工程直觉。比如，你在MySQL里做过分库分表，这和Kafka的partition设计有共通的分片思想；
你优化过慢查询，这和Spark的stage优化有相似的执行计划分析逻辑。面试时主动说"我没有分布式系统的生产经验，但我理解分片的核心挑战是数据局部性与查询灵活性的 trade-off，我在MySQL分表里遇到过类似问题"——这种主动建立连接的方式，比硬背概念让人信服得多。当然，你 still 需要至少一个分布式系统的个人项目或课程作业，否则简历关难过。一个可行的路径是：用Docker本地搭一套Spark+Kafka+MinIO的环境，把以前的一个ETL任务迁移过去，过程中你会遇到真实的配置问题、版本兼容问题、数据一致性问题，这些才是面试时可以讲的故事。
Q: 面试官问我期望薪资，应该说多少？
这个问题本身就在考察你的市场判断力和谈判成熟度。不是越高越好，也不是越谦虚越好。硅谷数据工程师的薪酬结构通常是Base $120K-$200K，RSU $30K-$200K/年，Bonus 10%-20%。不同公司的权重不同：Netflix风格是高Base低RSU，Google是平衡型，pre-IPO公司是低Base高期权。回答之前，你应该已经通过Levels.fyi、Blind、和内部朋友摸清了目标公司的band。
一个稳妥的回答框架是："基于我对这个岗位的了解和当前市场情况，我的期望总包在X到Y之间。我更看重的是整体package的竞争力，包括Base、股权和成长空间的综合。如果公司有具体的薪酬结构偏好，我可以灵活调整各个部分的权重。"不是回避问题，而是展示你理解游戏规则。一个真实的反面案例：某候选人在第一轮phone screen就被问期望，他报了一个数字，后来才发现那个数字是staff级别的下限、senior级别的上限，导致后续所有包裹都按senior upper bound给，他失去了谈判空间。
Q: 系统设计题完全没有思路怎么办？
首先承认：完全没思路的情况极少发生，因为系统设计题的素材都来源于日常工作的放大。如果你确实卡住，不是知识储备问题，是结构化思维没有形成。一个即时的救命框架是：先定义SLI（Service Level Indicator），再推导SLO，最后才设计架构。比如，面试官说"设计一个推荐系统的数据管道"，你的第一反应不是画组件，而是问"这个推荐的延迟要求是多少，是用户打开App就要有，还是可以容忍几秒预热"。这既是给自己争取思考时间，也是向面试官展示你理解"设计是为约束而生"。
另一个真实的hiring manager分享：他最喜欢的候选人在卡壳时说"这个问题我有点超出经验范围了，但我可以尝试从数据流的角度拆解一下"，然后画了数据产生、传输、存储、消费四个框，逐个确认理解是否正确。不是答对问题，而是展示你在不确定性中的工作方式。最后，如果你确实在某个技术点上完全空白，诚实说"这个我没有实际操作过"比胡扯安全得多，但关键是后面要补一句"如果让我现在学习，我会先去看官方文档的architecture部分，然后找两个开源实现对比"——展示你的学习路径比假装知道更有价值。面试结束后，如果你真的去做了这个功课，可以在thank you email里简要提一句，这种follow-through在有些公司是加分项。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。