在 2025 年 7 月底参加了 Meta 的 SDE 面试流程，整体包括三轮 Coding、一轮 Behavioral、一轮 System Design，总共分两天进行，都是线上。这篇分享主要想记录每一轮遇到的题目类型和解题思路，重点放在题本身，方便大家复盘刷题。

第一轮 Coding 的第一题是典型的搜索题，类似 LeetCode 上的 Word Search II，但题面更开放一些。输入是一个字符矩阵和一个单词列表，要求返回所有可以从矩阵中找到的单词，路径可以上下左右移动，不能重复使用同一个位置。暴力做法当然是 DFS，但很容易超时。我一开始也这么写的，面试官提示了一下 can we avoid re-visiting certain paths（最好不要让他提示，但是他主动说了），我立马改成 Trie，把所有目标单词构成一棵前缀树，然后在矩阵上用 DFS 搜索路径并prune。实现过程中我补充了 visited 数组、路径拼接和前缀pruning逻辑，最后代码通过所有 test cases，面试官也对这个优化方案表示满意。第二题是Search in Rotated Sorted Array，老tagged题了。

第二轮 Coding 更偏向字符串处理，用到 sliding window 技巧。题目类似找出包含至多 K 个不同字符的最长子串，但加了一个 twist：除了要求不能超过 K 个不同字符外，还要求返回子串的实际内容，而不是长度。我先用 hash map 记录字符frequency，用两个指针维护窗口，每次遇到字符数超出 K 就收缩窗口，最后更新 max 长度。逻辑不复杂，但面试官对细节要求挺高，比如为什么频次为 0 的字符需要移出hash table、如何处理 Unicode 字符等。后面我还讨论了是否可以用 Counter 替代 dict，面试官比较在意对边界条件有没有考虑清楚。第二题是 Shortest Distance from All Buildings，hard题，但是之前刷过，可以说是秒了。这轮交流很充分。

Behavioral 回合整体比较标准，面试官是 TPM，问题围绕 conflict resolution、decision making 和 leadership 展开。她问我有没有遇到过跨团队collaboration困难的情况，我举了之前推动一个 schema 变更但后端资源迟迟不到位的例子。她很关注细节，尤其追问了“how did communicate”、“结果有没有影响release”。另一个问题是关于 failure，我讲了一个因对traffic高峰预估不足导致系统overloading的事件，她很认真听，并在结尾问了我怎么总结的、事后有没有做 postmortem。整体交流氛围不错，比较考察真实经验和复盘能力。

第三轮 Coding 是图论相关的问题，核心是 BFS。题目要求给定一个初始状态、终止状态以及一系列合法转换规则，找出最短的状态转换路径。转换可以是 +1、-1、×2、÷2 等等，题面上没明说限制，我就问了一下能不能重复访问状态，面试官说“yes but only if the state is meaningful again”，意思是重复状态必须有新路径。我先写了标准 BFS 结构，每次把当前状态丢入队列，同时维护 visited set 防止死循环。后面面试官问如果状态空间特别大，怎么防止OOM，我说可以加边界条件和 lazy visited marking。他认可了，并让我大致讲一下 time/space complexity 和瓶颈在哪。第二题是Product of Two Run-Length Encoded Arrays，lc原题，很顺利。

System Design 是最后一轮，题目是设计一个Real-time Notification System，需要支持海量用户subscribe、推送低延迟、多端支持，并保证HA和可扩展性。我先把系统拆成 Producer、Message Queue、Dispatcher、Device Registry、Delivery Tracker 几个模块，面试官点头让我继续。我选 Kafka 做消息队列，理由是它支持 partition 和持久化；Dispatcher 层我设计成 stateless，可以水平扩展，利用 consumer group 控制负载均衡；Device Registry 存储在 Redis，记录每个用户的活跃设备。面试官不断深入细节，比如问“如果 Dispatcher 宕机怎么办” + “如果用户设备离线怎么处理”。我提出用 retry queue 和 exponential backoff，还加了 dead-letter queue 保证消息不会丢失。我们还讨论了如何做 QoS 控制，比如 VIP 用户能优先收到消息。我补充了 Prometheus metrics，比如 delivery latency 和 fail rate，用于上线后的可观测性。整体交流很深入，明显感受到系统设计绝对不只是讲概念，还要考虑实际运行中的故障和延迟容忍度。

lesson learned：Meta 的面试题并不偏难题型，但非常注重细节和思路的完整性。Coding 部分重点是 clean code 和边界处理；Behavioral 问得深入但可以准备；System Design 要求结构清晰、合理拆分，并能深入每个模块的设计动因和可扩展策略。