Phone Screen

Phone screen 一小时，结构很标准。前面是常规的 behavior question，后面两道 LeetCode 风格的 coding 题，难度不高，属于常规题型，没有什么特别刁钻的点。整体节奏比较平稳，只要平时刷题扎实，表达清晰，一般问题不大。

Phone screen 本身没太多可展开的，重点其实在 VO。

Virtual Onsite 总体结构

VO 一共 3 轮：两轮 coding，一轮 system design。

Coding 轮：高强度 + 高频 challenge

这一轮结构很清晰。前 5 分钟自我介绍，接着 10 分钟 BQ。虽然只问了一个问题，但 follow-up 非常多，而且明显偏技术导向。这里的一个重要感受是，准备 BQ story 的时候一定要有合理的 metric 支撑，否则 interviewer 深挖时很容易露馅。比如问到性能提升多少、延迟下降多少、流量规模是多少，如果答得含糊，很容易被 challenge。接下来是 coding，大概 35 分钟一道题。题目是口述的，而且描述得比较模糊，明显是故意不讲清楚，需要你一边问问题，一边澄清需求。这一点非常关键，如果直接闷头写代码，很容易方向跑偏。

题目是设计一个函数，用来检测一个用户在滑动时间窗口内是否存在异常 burst 行为。听起来简单，但细节非常多，比如时间窗口怎么定义，是固定窗口还是 sliding window，阈值如何设定，是否要支持动态调整，数据是否有序等等。写完代码后，面试官要求写 test cases。我当时写完之后一次性通过，结果 interviewer 追加了很多非常特殊的 corner cases，比如极端时间间隔、重复事件、窗口边界重叠等。结果 test failure，只能现场修改。

这一段其实是强度最高的部分。你在改逻辑的时候，interviewer 会不断 challenge，你为什么要这么改，这种情况在真实系统里是否合理，会不会引入新的问题。整个过程有点像 production code review + oncall debug。时间也会被压缩得很紧，所以一定要保持思路清晰，不要 panic。总体来说，这一轮考察的不只是算法，而是需求澄清能力、边界处理能力，以及在压力下 debug 和 defend 设计的能力。

第二轮coding的面试结构是一样的。题目是LC 978。

System Design：更像真实生产环境讨论

最后一轮是 system design。开头 5 分钟自我介绍，然后 10 分钟 BQ。这一轮的 BQ 很多问题都围绕 Snap 自己的业务场景，明显是在看你是否有贴近实际系统的经验，而不是纸上谈兵。设计题是：设计一个支持自动删除（24 小时后消失）的消息存储系统。题目描述同样比较宽泛，interviewer 一开始就强调希望多沟通，不希望变成单方面的长篇大论。所以这轮的核心是交流，而不是展示背稿。我按照比较标准的流程来讲，从 requirement 开始，区分 functional 和 non-functional，然后定义 entities，设计 API，画出整体 architecture，再讲 control flow。显然 interviewer 最关心的是 architecture 的取舍，比如存储怎么分层，冷热数据如何处理，如何保证 24 小时自动删除的准确性和性能，是否用 TTL，是否需要异步清理机制，如何处理跨 region。

在画完一个基本的 diagram 之后，剩下 15 分钟基本没有再往 whiteboard 上写新东西，而是针对 interviewer 的 follow-up 进行 deep dive。很多问题都是他们在生产环境里真实遇到过的问题，比如大规模 TTL 批量过期导致的负载尖峰，删除一致性问题，消息恢复场景，延迟删除对用户体验的影响等等。这一部分非常考验实战经验。如果只是 textbook 级别的回答，很容易被问穿。interviewer 明显更关注你是否踩过类似的坑，以及你是怎么解决的。最后五分钟是反向 BQ。

总结

整体感觉 Snap 的面试风格偏实战，尤其是 VO。coding 轮强度很高，需求模糊 + corner case 持续加码，非常考验抗压能力。system design 更像真实工程讨论，而不是模板化答题。BQ 一定要准备扎实，尤其是 metric，一旦被追问细节，没有数据支撑会很被动。如果有真实大规模系统经验，优势会非常明显。反之，只靠刷题和背 design 模板，可能会比较吃力。