两个月前面了 Spotify 的 DE 流程，对应一个 senior data engineer 角色。写这个是因为 DE 的经验在网上几乎看不到，相比之下 SWE 和 DS 的流程信息太多了。
整体结构： OA（take-home coding，2 题，2 小时） technical phone screen（60 分钟） final round：2 天内 4 轮面试（virtual）
OA 第一题是 SQL，中等复杂度，属于那种按多个维度聚合 event 数据的题。第二题是 Python，处理一条 records 流并做一些转换逻辑。两题都更像在考「能不能写干净、接近生产的代码」，不是算法谜题。没有那种刁钻 DP 或 graph。
technical phone screen 一个面试官，60 分钟，混合了： 一道 coding 题（难度和 OA 类似） pipeline 设计问题：「你会怎么设计一个能规模化处理 late-arriving events 的 pipeline」 还提到了 Kafka。我说我用过，他们就往深了问。如果你用过 Kafka，把 consumer group 语义和 offset 管理复习透。如果没用过，至少把概念搞清楚。
final round
pipeline design 轮： 题目大概是：你需要从多个来源 ingest 原始 streaming event 数据，做 normalize，并让它能支持实时 dashboard 和批处理 ML training jobs。经典 lambda vs kappa 讨论，而且他们明确要求我说出 tradeoffs。
SQL 轮： 比 OA 难，更接近另一个帖子里 ds_dmitri 描述的 DS SQL 轮。window functions、time-series 聚合，还有一道关于 streaming events 在 at-least-once 投递下的 deduplication 策略。
behavioral： 标准 values 问题。有一个很具体：「讲讲一次你负责的 pipeline 导致下游数据质量出问题。发生了什么，之后你们改了什么。」
容易踩坑的点 late-arriving events。大家都会设计 happy-path pipeline。Spotify 的 DE 面试会专门追问：如果一个 event 晚到了 6 小时，而你的下游表已经算完了，你怎么办。要知道你的选项（reprocessing、flagging、watermarking），而且要有观点。