我在 2025 年末面了 Brex 的 data engineer，现在终于来发帖。loop 一共四轮，侧重点大概是：50% 技术实现，30% 数据建模/架构，20% behavioral。
SQL 轮： 两道题。一道是 transactions schema 上比较直接的 aggregation + filtering。第二道更有意思：给了我一张反范式的表，让我写一条 query，在某些数据质量假设不成立时会直接跑崩，然后问我怎么把它写得更「防御性」。这就是很真实的数据工程问题，不是偏 LeetCode 的那种。我挺喜欢。
Pipeline 设计： 不走传统白板。他们描述了一个场景：你从 Kafka topic 接收原始刷卡交易事件，需要落到数据仓库，下游分析团队既要实时 dashboard，也要每天批处理的聚合。让你讲设计。我提了实时链路用 Flink，批处理变换用 dbt，schema evolution 用 Avro，监控用 ingestion 层的数据质量检查。他们会追问两条链路之间的取舍（延迟 vs 成本 vs 复杂度）。
数据建模： 给我看了他们 spend 数据的一个简化版本，让我给它做维度模型设计。基本的 star schema 之外，还问了 slowly changing dimensions，很多候选人在这块会开始含糊。
他们似乎在意的工具栈： Airflow 或类似的编排器，dbt，有一定 streaming 背景（至少 Kafka），以及熟悉云数仓（Snowflake/BigQuery/Redshift）。pipeline 逻辑用 Python。
Brex 的 DE 角色更偏 senior，所以门槛感觉合理地高。不是过不了，但你得真的做过并运营过 pipelines，而不只是理论描述。
Comp：我没有当前数字能分享，不过 Levels.fyi 上有一些 Brex 的 DE 数据值得看看。
5 条回复
infra_ines (Primly starter)
「把这个 query 写得更 defensive」这个 prompt 其实是个很好的面试题。他们是希望你加明确的 null check，还是在考别的点？
由 AI 翻译，查看原文
de_derek (Primly starter)
既看 null 检查，也看对引用完整性的预期。还问了我会在 pipeline 周围加什么监控，用来捕捉那些假设在不知不觉中被打破的情况。运维视角很重要。
由 AI 翻译，查看原文
analyst_ana (Primly starter)
SCD 的问题问到多深？比如 type 1/2/3 这种，还是会深入到具体实现层面的 tradeoff？
由 AI 翻译，查看原文
de_derek (Primly starter)
Type 2 问得挺深入的。什么时候更偏好 type 2 而不是直接覆盖，存储成本多少，point-in-time 查询会怎么变。没到特别深，但基础得非常熟。
由 AI 翻译，查看原文
Primly Team
在 data engineering loops 里，有个环节候选人经常低估：介于「query 能跑」和「pipeline 可靠」之间的假设审计（assumption-audit）。一个好用的答题结构（尤其适用于防御型 SQL 和 streaming-to-warehouse 设计）是：(1) 先讲你假设的数据契约是什么，(2) 你怎么检测契约被违反，(3) 你怎么控制影响范围，(4) 你会对哪些信号告警。
具体来说：在 SQL 里，明确说唯一性、可为空性、以及事件顺序。然后加一些检查，比如 COUNT(*) vs COUNT(DISTINCT key)、null-rate 阈值、以及迟到事件窗口。在 pipeline 设计里，点出故障模式（schema drift、重复、重试、回填），并把每个都绑定到一个幂等策略、watermarking、以及清晰的重处理计划。
你在生产 pipeline 里见过最常见的「隐藏假设」是什么？你当时是怎么设计护栏的？
由 AI 翻译，查看原文