Databricks sde 面试这两年明显在筛工程能力上限——不只考 coding，还覆盖并发、网络、系统设计、文件系统，software engineering 全家桶的味道越来越重。流程是 OA → 两轮 VO → 一轮 Manager 面 → Offer。
别一上来就刷题，先把简历改到和 JD 对齐。能不能进 VO，很多时候简历匹配度和 OA 成绩一样重要，这一步省不得。算法题基本是 LeetCode Medium 偏上，喜欢套一层大数据场景，但剥开外壳还是经典题。下面按几个环节分别聊。
OA
OA 是一道 coding 题，主题是设计一个支持 set / get 的缓存系统，但缓存本身不用实现，重点是统计过去 10 分钟内的操作频率。
整体思路比较直接，用 deque 维护时间窗口，每个节点记录 (minute, count)。每次操作的时候更新当前分钟的数据，同时清理掉 10 分钟之前的记录，然后维护一个总操作次数，查询的时候返回总次数除以 10，也就是过去十分钟平均每分钟的操作量。
这题本身不算难，但是隐藏测试比较多，时间边界很容易出问题。比如刚好卡在窗口边界的请求、连续大量请求集中在同一分钟、过期数据没有及时清理导致内存增长，这些都是容易挂的地方。
这道题是 Databricks 一条主线的起点:时间窗口内的频率统计，后面 VO 会层层加深。
VO 第一轮：BQ + Coding
BQ
第一轮前面会有一部分 BQ，大概十几分钟，问题比较经典，比如让你介绍做过的最复杂的数据项目，过程中遇到什么困难，最后怎么解决。
这部分不要只介绍项目背景，重点还是放在自己的判断、技术选择和结果上。尤其是为什么这么设计、遇到问题之后怎么定位、最后效果怎么样，这些比单纯讲项目功能更重要。
Coding
OA 频率题的加深版：用 Python 的 time 库维护一个 300 秒滑动窗口算访问频率。考点就三个——数据结构、窗口维护、边界。逐秒记录，同一秒已存在就计数加一、否则新建 [timestamp, count]；关键是每次访问都要用循环清掉队首超 300 秒的记录，漏了会内存爆掉。平均率就是队列内 count 求和除以 300。
写的时候主动提两个边界：空队列和时间回退，忽视了容易在测试 case 下挂。
两个 follow-up 很有 Databricks 风格：请求稀疏时怎么省内存（别逐秒存，记时间戳加累计总数、用差值推算）；多机怎么统计全局频率（Kafka 收集日志，上层用 Flink / Spark Streaming 聚合）。
VO 第二轮：工程全家桶
这轮明显更深入，并发、网络、系统设计都会考到，不同批次题目有差异，高频的几类如下。
Hit Counter 设计
像 LeetCode 362，但重点在按业务规模做取舍。支持 hit、get_load、get_qps，先做 300 秒窗口再扩到一天、一周。层次是:deque 基础版 → 300 桶循环数组把查询降到 O(1) → 窗口变大后改分层聚合（短窗按秒、中窗按分、长窗按小时，换来精度损失和写放大）。重点是主动说清每种方案的优缺点。
Tic Tac Toe 变种
棋盘 N×M、连续 p 子获胜，input 很大。胜负判定别全盘扫，只从刚落子那格沿四个方向数连续同色，单次 O(p)，否则超时。真正考的是边界 + 搜索优化。
多线程 pub/sub 聊天系统（Databricks 最爱考）
单机多客户端，一个 user 订阅多 channel，发消息时所有订阅者都收到。本质 mini 版 pub/sub，核心难点是多线程同步——thread-safe 队列 + subscription registry + broadcast，用锁保护 registry、并发队列做缓冲。会追问锁粒度和死锁。
IP to CIDR 变体
加了非连续 IP、不同 block size、精确算 mask。核心是每块大小取两者较小——IP 的 lowbit（能对齐的最大 2 的幂）和剩余待覆盖数量，再换算 mask。坑在位运算精度和边界，多写 case 验证。
分布式文件系统
支持 create / list dir、put / get file，追问大文件怎么办——基本是 HDFS 那套。主线:目录用树，大文件做 chunking 切块分散存，metadata server 记录 chunk 位置，replication 多副本容错。说清 chunk、metadata、replication 各解决什么即可。
Manager 面
Manager 面基本不会再考算法，主要围绕项目经历展开。建议提前准备一个性能优化或者稳定性相关的项目，而且一定要准备具体数据。不要只说“优化了性能”“提高了稳定性”，最好能说清楚 P99 降低多少、成本下降多少、失败率降低多少，这些数字会让回答更有说服力。
Databricks 的项目追问通常集中在两个方向：你怎么确认真正的问题在哪里，以及上线之后怎么保证没有引入新的风险。
所以除了技术方案，也要准备监控、灰度发布、回滚机制这些内容。很多候选人项目讲得不错，但一追问线上保障就容易断掉。
整体感受
Databricks 现在的面试已经不是单纯刷题型公司了。算法难度其实没有特别夸张，但每一道题都会继续往工程方向延伸。频率统计会追问系统扩展，并发题会追问线程安全，文件系统会追问分布式设计，最后还会结合项目判断你的工程经验。
如果准备 Databricks，建议不要只刷 LeetCode，把时间窗口、缓存、并发、多线程、分布式系统这些方向一起准备，再把自己的项目经历重新梳理一遍，通过率会高很多。
写在最后
如果你也在准备 Databricks 或其他大厂 SDE，Interview Show 专注北美技术岗位的面试辅助，团队来自一线大厂，提供一对一 mock、coding 与系统设计题型梳理、项目深挖演练。有需要的同学可以联系我们做一次免费评估，按你的背景和时间给出合适的方案。