数据工程师面试问题：SQL、管道和压力下的可靠性

这个职位的面试流程围绕一个核心关注点构建：你能否在规模上正确地移动和转换数据，而不需要任何人看管它。这表现为四个相关的技能领域：SQL和数据建模、ETL和ELT模式的管道设计、故障下的可靠性，以及向不编写代码的人传达权衡的判断力。

大多数流程混合了一个实践SQL轮次、一个专注于管道或数据平台的系统设计轮次，以及一个行为轮次，探测你如何处理损坏的数据、缺失的需求和与数据科学家或分析师的分歧。一些公司还进行一个带回家的练习，你从原始数据集构建一个小管道，这在没有现场观众的情况下测试相同的技能。

面试官不仅在评估你的查询是否返回正确的行。他们在听你如何叙述你的推理：为什么你选择窗口函数而不是自连接，为什么你选择增量加载而不是完全刷新，为什么你会对行数漂移而不仅仅是空值计数发出警报。一个含糊其辞地给出正确答案的候选人通常会输给清楚地解释略微不完美答案的人。

在面试前，从你自己的工作中列出一份短清单，列出你能在两三句话中描述的管道、表或事故。你将在SQL、设计和行为轮次中不断参考它们。

SQL仍然是数据工程面试中最常见的门槛，即使在主要运行Spark或dbt的公司也是如此。期望这样的提示：写一个查询返回每个客户最近的订单、在每个账户的日期序列中找到间隙、计算日收入的七日滚动总计或去重行而不丢失最新版本。

窗口函数不断出现。具有PARTITION BY子句的ROW_NUMBER()是"每个键的最新记录"问题的标准工具；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可以帮助你大声练习数据工程师面试问题，提供关于清晰度和节奏的反馈，以便你的技术推理能以在页面上阅读一样的信心传达出来。