刚结束一个 Snap 的 DE 面试流程。发帖是因为现在网上的 DE 面试内容不是太老就是太泛。Snap 的 data infra 确实很有意思，面试也会反映这一点。
背景：我是 senior DE，7 年经验，主要是 Spark + Kafka + dbt 这套。面的是 data platform team 的 senior 级别。
Phone screen（45 分钟）： 技术和 behavioral 混合。先过简历，问我做过的最大 pipeline（我讲了一个每天处理约 2TB/day 的事件处理 pipeline），然后现场做两道 SQL。一题 window function，一题是用递归 CTE 做层级遍历。都不算离谱，但递归那题让我有点措手不及。CTE 要熟。
Onsite（4 轮）： SQL deep dive（60 分钟）。比 screen 更复杂。给了一个很乱的多表 join 场景，还带一个很 tricky 的去重要求。他们会专门问性能，不只看对不对。我讲了 indexing 策略，以及为什么我会避免某些 subquery 写法。 数据建模与架构（60 分钟）。更像偏软一点的系统设计。给的场景是：Snap 新上线一个广告产品，会产生高量 events。设计从 raw ingest 到报表的 data pipeline。我讲了 Kafka ingest、Spark streaming vs batch 的取舍、schema 演进、以及如何为 analytics team 建下游的聚合表。关于 schema-on-read vs schema-on-write 的讨论很多。 Coding（45 分钟）。Python。数据处理题，不是 LC 算法题。更像：给你一个数据集，清洗、聚合、并高效返回结果。比起常见 LC 更接近真实工作。 Behavioral（45 分钟）。跨职能。你怎么跟 data scientists 和分析师合作，他们的质量标准跟你不一样怎么办？怎么处理影响下游 dashboard 的数据事故？挺标准，但值得准备。
他们内部用 Spark，这在第 2 轮里会自然出现。你不需要是 Spark 专家，但基础概念懂会很有帮助。
总体：比我做过的一些 DE 流程更难，也更有意思。SQL 轮是实打实的，不是走过场。
6 条回复
ae_andre (Primly starter)
recursive CTE 在 DE 面试准备清单里真的太被低估了。我看到很多人 window functions 学了好几周，然后一个简单的 hierarchy traversal 反而脑子空白。加到我的 list 里了。
由 AI 翻译，查看原文
analyst_ana (Primly starter)
schema-on-read 和 schema-on-write 的区别就是那种，听起来很简单，但面试官让你在约束条件下为一个选择做论证时就不简单了。你有没有一个常用的默认框架？
由 AI 翻译，查看原文
de_derek (Primly starter)
我的默认：当 schema 稳定、已知且你在意查询性能时用 schema-on-write（报表型数仓、维度表）。当数据源多样或变化很快时用 schema-on-read（data lake ingestion、ML features）。然后再把成本和工具约束叠加进去。他们好像对这个框架挺满意。
由 AI 翻译，查看原文
ml_mike (Primly starter)
好奇 data modeling 那轮更偏 lakehouse 还是传统 DW。snap 以前 hadoop/hive 基建很重，但我觉得应该在变化。
由 AI 翻译，查看原文
de_derek (Primly starter)
更偏 lakehouse。他们提到过一次 iceberg。传统的 star schema 也聊到了，但明显他们在想更现代的存储模式。
由 AI 翻译，查看原文
Primly Team
在这种 DE 面试流程里，有一关经常被低估：SQL 和 pipeline 的“性能推理”层。只写出正确的 query 往往不够。面试官通常想看你怎么决定复杂度该花在哪里：尽早下推过滤条件、在昂贵 join 前先缩小 join 域、把去重写清楚（tie-breaker、确定性排序），以及点出 DISTINCT-after-join 或相关子查询这类模式的代价。
一个更实用的答题结构是：（1）先复述你要达到的数据粒度，（2）用普通英语概述步骤，（3）写出 query，（4）用边界情况做 sanity-check（null、重复、延迟事件），然后（5）给出一个优化方向和你会衡量什么（各阶段 row count、数据倾斜、分区、spill）。
在 senior 的 DE 面试里，你最意外的是哪一块：时间压力下保证正确性、解释 tradeoff，还是尽早发现数据边界情况？
由 AI 翻译，查看原文