Meta 系统设计面试问题
作者 Aaron Cao · 更新于
Meta的设计面试通常会让你设计一款面向消费者的产品系统——信息流、消息服务、通知管道，或是“附近的朋友”功能。面试官对产品需求和数据模型的重视，不亚于对可扩展性的重视，而且这一环节是高级别岗位的标配，而非入门级别。
Meta 会问哪些类型的设计问题？
你可能准备了大量分布式系统的知识点，但这一环节不会考这些。这部分讲的是真实的题型，它们更接近产品工程，而非基础设施。反复出现的模式是：把一个你已经在用的消费级功能，作为开放性问题交给你。
- 设计一个信息流。排序方式、写扩散与读扩散的取舍，以及粉丝数上百万的账号该如何处理。
- 设计一个消息或聊天系统。投递保证、顺序、在线状态，以及跨设备的离线同步。
- 设计一个通知系统。去重、批量处理、按用户限流，以及推送、邮件、应用内通知的分发。
- 设计“附近的朋友”或位置类功能。地理空间索引、更新频率，以及隐私模型。
- 设计搜索或热门趋势组件。索引新鲜度与查询延迟之间的权衡。
有些面试流程会把这拆成产品架构变体，更贴近用户可见的行为。可以问问招聘方你面对的是哪一种，因为准备方式会不同。
这 45 分钟该如何分配？
常见的失败模式是，第二分钟就开始画框图。一种可行的时间分配是：先明确需求和范围，再勾勒API和数据模型，然后画出高层架构，最后按面试官指向的方向深入。
- 需求优先。面向哪些用户、哪些平台，是读多还是写多，以及明确不做什么。
- 其次是数字。大致的日活量级、请求速率和数据包大小，为后续的权衡提供依据。
- 先有数据模型，再画图。一个实体长什么样、如何被查询，通常决定了架构走向。
- 一次深挖。预计会被引导深入某一个组件，并被问到它会如何失效。
把你的假设说出来。面试官如果不认同某个假设，会当场纠正你，这其实是免费的信息；而没说出口的假设，只会显得像是一个漏洞。
优秀回答和普通回答的区别在哪里？
普通的回答只是描述一个正确的架构。优秀的回答会说出自己接受了怎样的权衡、愿意容忍怎样的失效。比如说“我选择写扩散，因为这里读多于写，我接受名人账号写入变慢，会用单独的拉取路径来处理”，这比一张完美的架构图更有说服力。
设想一位正在面试高级职位的后端工程师。她被要求设计一个通知系统，前六分钟只谈需求：同一事件用户是否会收到两条通知、顺序是否重要、留存窗口是多久。面试官后来说，去重的讨论才是这个环节的决定性部分，而她始终没有画完一页架构图。
独自在桌前演练这种讲述方式是最难的部分。你可以在 /mock-interview 页面向AI面试官练习这类设计题，习惯边思考边说出来。
实时助手在哪些地方有用，哪些地方没用？
在语音视频面试环节，SubcueAI会转写面试官的问题，并在你这一侧显示建议的回答结构——在macOS和Windows上是桌面悬浮窗，在Chromium浏览器扩展中是侧边栏。没有机器人加入通话，也不会向会议页面注入任何内容。对设计类环节来说，它真正的价值是一份清单，帮你记住压力下容易忘记的要点，比如容量估算或失效模式，而不是让你照着念一个现成答案。
但限制也很明确。设计环节通常在共享的白板工具上进行，你的屏幕会被共享，屏幕上的一切对面试官都是可见的。照着念生成的答案也会立刻穿帮，因为面试官接下来一定会问“为什么不用另一种方案？”。其他雇主的相关流程，可参考公司面试专题。