Databricks 的 phone screen 是完整的 60 分钟，不是常见的 45 分钟结构。整个过程只有一道主要题目加一个 follow-up，但深度非常足，明显比 Meta 那种两道题拼速度的面试更考察设计与思维延展性。面试官一上来没有太多寒暄，直接进入题目讨论。题目是经典的 Design Hit Counter，要求设计一个能实时统计过去 5 分钟（300 秒）内 hits 次数的数据结构。题面看似简单，但在实现细节、复杂度控制和扩展性思考上能很快区分候选人的系统化思维。

题目与思路

题目本质是一个 time-windowed counter 问题，可以抽象为时间戳与命中次数的键值对存储。每次 hit(timestamp) 时，我们要记录该秒的命中数；在 getHits(timestamp) 时，只统计最近 300 秒的 hits。实现上有多种方式：最基础的做法是使用队列配合哈希表。队列保证时间有序，方便快速清理过期数据；哈希表保存每秒的命中次数。这样每次查询时，只需清理队头中早于 timestamp - 300 的元素，再累加剩余值即可。操作复杂度在平均情况下能保持常数级，非常高效。

Follow-up：高并发场景

面试官的追问非常到位：如果系统每秒会有上万次 hit，我们该如何优化？这时就不能再为每个 hit 单独存储记录，而是需要聚合。改进思路是将相同秒内的所有 hit 合并，只存储该秒的时间戳与总命中次数。这样整个滑动窗口的空间复杂度恒定为 O(300)，hit 和 get 操作依然是 O(1)。通过这种秒级聚合，我们不仅降低了内存占用，还能让系统在高并发环境下稳定运行。这部分的讨论更像是在考察如何把一个 toy problem 提升为可落地的工程方案，Databricks 的面试官在这方面非常注重推理逻辑和工程直觉。

沟通体验与面试印象

面试过程中沟通非常顺畅，面试官逻辑清晰、节奏掌控得当。当我尝试讲一个更fancy的数据结构时，他立刻指出其中的可扩展性问题，并引导我回到更合理的实现路径。这种交流氛围让整个面试过程像是一次思维共创而不是单向拷问。最后我最大的感受是：在 Databricks，沟通能力的重要性几乎不亚于算法本身。清晰表达、主动验证假设、和面试官同步思路，往往比多写几行代码更能打动对方。因为在真实工作中，良好的沟通往往决定了项目能否顺利推进。