我参加的是 Splunk 的 SDE 面试，整体流程下来感受是非常结构化，题目几乎都可以在面经中找到原型，核心在于执行的扎实程度。真正最难的是不是面试题，而是能不能通过简历筛选进到第一轮。

第一轮是纯 coding，考了一道和 Leetcode 329 类似的题：在一个 h × w 的矩阵里，每个格子都包含从 1 到 n 的一个独特整数（n = h * w），顺序是任意的。你需要找出一条最长的路径，这条路径上相邻格子的数值必须是连续的（即相邻格子的差值为 1），路径可以上下左右走。和标准的 DFS + memoization 思路一样，这一题的关键在于如何避免重复计算。我首先用 DFS 探索每个起点，然后加了一个 DP 缓存表来记住每个格子的最长路径。整体思路清晰后，面试官更关注的是我如何验证 correctness 和边界，比如单个格子的处理、是否能走回头路、有没有 cycle 等等。

第二轮是半简历半系统设计，前半小时我们聊的是我在简历上提到的一个分布式日志处理系统，面试官深入问了我对数据倾斜、sharding 和高可用的理解。后半段是设计题：给你 100 亿条 URL，内存不够，怎么去重并合并。这个题和外排序的经典设计非常接近，但你得把工程细节说清楚。我首先讨论了可以用多路 merge + external sort 的思路，每次处理能装进内存的部分，把中间结果写到磁盘；接着用 heap 做多路合并来最终归并所有 URL 并去重。我还提到为了减少磁盘 I/O，可以先做 hash partition，把 URL 写到多个 bucket 文件里，然后每个 bucket 单独去重、合并。这一题其实就是看你有没有做过真正处理“数据大于内存”的设计。

第三轮是 full design，题目是设计一个 web crawler：接收一堆 HTML 页面的 URL，递归爬取这些页面的内容，并把内容写入一个持久化存储系统供后续分析使用。这一题不算难，但点很多。我从高层拆成几个模块：URL frontier、Fetcher、Parser、Storage、Scheduler。然后一一展开细节，比如：

- 如何避免重复爬取（用 Bloom Filter / URL 去重队列）；
- 如何控制并发抓取（比如通过 token bucket 或者对 host 做 throttling）；
- 对 robots.txt 的处理；
- 如何应对网页挂掉、抓取超时、重试；
- 内容如何存储（KV 存 URL-to-content 映射，或者直接存到对象存储如 S3）。

面试官追问了 crawler 的扩展性，比如支持分布式部署、多 worker 协作、状态 checkpoint、断点恢复等等。还顺带问了下 storage 的 schema，是否需要 indexing 和后续的分析接口。