Databricks FDE 面试：Spark、Unity Catalog，以及把模糊目标变成系统的那一轮

设想面试官开场只说一句话：“一家零售连锁想用 AI 留住客户，请设计一下。”没有表结构，没有数字，也没人提截止时间。

根据 Aced.io 的一份面试指南，Databricks 的拆解轮就是这个样子：用大约 60 分钟，从一个仍然模糊的业务目标出发设计一套系统。

这一轮难，是因为它很像真实的工作。Databricks 的高级前线部署工程师（Sr. FDE，Fullstack）岗位描述写道，工程师要与客户一起构建解决其数据和 AI 问题的方案，并推向生产环境。职责部分说得很直白：FDE 负责主导技术项目，交付生产级系统。

所以只刷 LeetCode 是不够的。真正考察的有三项：对 Spark 的深入理解，对 Unity Catalog 治理的掌握，以及把模糊需求转化为架构的能力。下面每一节都附有一个可以自己动手练的例子。

五轮面试，其实只考三项能力

Aced.io 的指南描述了五轮流程：30 分钟的招聘方沟通、技术初筛、在 notebook 中写代码的一轮、拆解轮和领导力轮。这是第三方描述，并非官方文档，顺序和时长可能因招聘团队而异。

更可靠的是岗位描述本身列出的要求。首尔岗位要求候选人拥有丰富的 Apache Spark 分布式计算经验，并了解 Spark 的运行时内部机制。

它还要求候选人理解并使用 MLOps、ML/AI 模型和 AI API，并能用多种语言写代码。苏黎世的高级岗位赋予 FDE 架构决策权，前提是方案安全且可扩展。

把这两个来源放在一起看：notebook 轮考 Spark，拆解轮考架构与治理，领导力轮考你如何与客户协作。围绕这三项能力准备，不要把时间平均分给五轮。

Spark 问题考的是 API 之下的东西

“运行时内部机制”这个说法意味着，面试官希望你能解释作业为什么跑得慢，而不只是写出一个 join。经典例子是数据倾斜。

假设你用 customer_id 把 orders 表和 customers 表做 join，Spark 在 shuffle 之后把数据分成 200 个分区。如果某个批发客户占了 orders 中 40% 的行，这 40% 会全部落进同一个分区。结果是：199 个任务几秒内跑完，整个作业却在等一个承担了近一半工作量的任务。

好的回答分三步。首先是发现：在 Spark UI 里，同一 stage 中某个任务的运行时间远长于其他任务。其次是原因：shuffle 会把同一个 key 的所有行发往同一处。

最后是解决办法：广播小表以避免 shuffle；给倾斜的 key 加“盐”，把它打散到多个分区；或者开启自适应查询执行，让 Spark 自行拆分过大的分区。

不要只看不练。在 notebook 里造一张倾斜的表，分别记录修复前后作业的耗时。面试时用自己测出的数字来讲，远比背定义有说服力。

Unity Catalog 是给关心安全的人的答案

Databricks 文档把 Unity Catalog 定义为内置于平台的数据与 AI 统一治理层。被问到时，有两点必须能脱口而出。

第一是三级命名空间 catalog.schema.object。在上面的零售问题中，客户特征表可以命名为 retail.churn.customer_features。在白板上把名字写清楚，说明你考虑过数据放在哪里、谁可以访问。

第二是血缘。Unity Catalog 会自动追踪数据和 AI 资产如何流动、如何关联，从源数据一直到模型、服务和仪表盘。好处很具体：市场总监问仪表盘上某个数字从哪来时，你不用读代码就能追溯到源表。

前十分钟决定拆解轮的成败

Aced.io 的指南建议把开头几分钟用来澄清目标，因为这一轮模拟的是一次真实的客户会议。针对“留住客户”这个需求，可以按这个顺序提问：

“留存怎么衡量：90 天内复购的客户占比，还是平均客单价？”“谁使用输出结果：每周发优惠的市场团队，还是门店员工？”“交易数据现在存在哪里，多久更新一次？”“有没有只允许部分人查看的个人数据？”

假设得到的回答是：市场团队每周发一次活动，数据每晚更新，客户手机号属于敏感信息。在这些条件下，架构几乎自己就成形了。

数据每晚加载到 retail catalog，Spark 计算特征，模型给流失可能性打分，结果写入市场团队可读的表。手机号这一列只对活动运营组开放。

画出架构图只完成了一半，另一半是解释为什么选这个方案而不是别的。比如，选择批处理而不是流处理，是因为活动按周进行，实时打分只会增加成本，不会增加价值。

加入 MLOps 式的模型监控，是因为购物行为会随季节变化。指出血缘，是为了说明系统可以审计。

投递之前，先选对岗位

Databricks 的三个 FDE 岗位侧重点明显不同，简历应当针对每个岗位分别撰写。

	FDE（首尔）	Sr. FDE – Fullstack（苏黎世）	AI Engineer – FDE
侧重点	Spark 分布式计算，运行时内部机制	生产级系统，架构决策	GenAI 应用
需要展示的经验	深入的 Spark；MLOps、ML/AI 模型、AI API；多语言编程	6 年以上数据工程、数据平台与分析或软件工程经验	RAG、多智能体系统、Text2SQL、微调
与客户的节奏	—	主导客户的技术项目	视需要每 4–8 周拜访客户

无论申请哪个岗位，简历中的每一条都应写清三件事：一套你推上生产环境的系统、一个实测数字、你如何处理访问控制或数据血缘。例如，“通过修复倾斜把 join 耗时从 X 降到 Y”，分量远远超过“精通 Spark”。

让强候选人栽跟头的错误

最常见的错误是一听完需求就开始画架构。面试官扮演的是客户，跳过澄清问题，就相当于面对真实客户时跳过了需求调研。

第二个错误是在 API 层面回答 Spark 问题，而首尔岗位明确要求运行时知识。第三个错误是只有被追问时才提治理，而高级 Fullstack 岗位要求方案从设计阶段就保证安全。

在领导力轮，“我很擅长团队合作”这类泛泛的故事，比不过一个有具体客户、具体冲突、由你拍板做决定的故事。

你不需要把 Databricks 的每个功能都背下来。你需要让面试官相信：如果明天派你带着一个模糊需求去见客户，你会问对问题，选对架构，并留下一套别人能追溯的系统。