Meta SWE VO 的 Coding 轮很赶，写出主逻辑还不够，必须留时间跑边界和解释取舍。先把图、数组、哈希表这些基础题练到能在白板上快速拆解；这份 E4 Product SWE 分享里的课程依赖变体和前缀和追问，就很像这种节奏。
第一面：Coding – 课程依赖与可完成任务数
Topic：给定课程数和先修关系 [[course, prerequisite]]，找出在不违反依赖的前提下最多能完成多少门课。follow-up 把输入扩展为带优先级的任务，并要求输出一条可执行顺序。
解答思路：先建邻接表和入度数组，把入度为 0 的课程放进队列。每弹出一个节点就减少后继入度，新的 0 入度节点继续入队。遍历结束后，出队数量就是可完成数；如果要固定顺序，用优先队列代替普通队列。任务带优先级时，只在当前可执行集合里比较优先级，不能先全局排序，否则会破坏依赖关系。测试覆盖独立节点、环、重复边、孤立课程和多条依赖同时解除的情况。Complexity：时间 O(V + E)，空间 O(V + E)。
第二面：Coding – 两个有序事件流去重合并
Topic：两个按时间排序的事件流都含有同一个 event_id，每条事件还有 created_at,version 和 payload。合并后要按时间输出，并且同一 event_id 只保留版本最高的一条；流可以持续追加。
解答思路：离线输入用双指针推进两个数组，先比较时间；时间相同再按 event_id And version 判断。去重不能只看相邻记录，因为同一事件会在后面出现更高版本，所以哈希表保存每个 event_id 的当前最佳版本，最终再按时间排序输出。流式输入则保留一个按事件时间排序的小缓冲区，并用 watermark 决定何时可以落盘，避免迟到事件直接打乱已确认结果。测试要有同时间不同事件、同 ID 的跨流重复、旧版本晚到、空流和 payload 不同但 version 相同的冲突规则。
第三面：Product Design – 关注列表 Feed 排序
Topic：设计一个关注列表 Feed，支持发帖、删除、拉取首页、屏蔽作者和按时间分页。热门创作者有千万级关注者，读取必须稳定，删除后不能一直出现在缓存页。
解答思路：写入路径把帖子写进内容库，再把轻量索引投递给 fanout worker。普通创作者走 fanout-on-write，热门创作者只写作者时间线，在读路径合并，避免一次写入生成海量收件箱记录。首页读取先取用户收件箱和热门作者候选，再按排序分数合并；cursor 使用 (score, created_at, post_id)，这样分页不会漏项或重复。删除和屏蔽事件写进单独的过滤索引，读缓存命中时也要做一次过滤。计数、缓存命中率、cursor 重复率和删除传播延迟都要单独监控。
第四面：BQ – 用数据推动一次技术分歧
Topic：讲一次你和负责人对技术方案看法不同的经历。追问包括你如何收集证据、怎样处理反对意见、上线后结果怎样，以及后来是否改变了判断。
解答思路：别从 STAR 模板开始，先把分歧说具体，例如同步写库还是先写队列。接着交代约束：峰值流量、错误预算、交付日期和迁移成本。你做过的实验、压测数字、灰度范围和最终取舍要能连起来。如果结论不是自己最初支持的方案，也要说清接受决定后怎样把风险收住。Meta 的 BQ 不怕讲失败，怕的是没有自己做过的判断。
Exam preparation advice
两道 Coding 题放在同一段计时里练，35 分钟内写完第一版并留出 dry run。Product Design 不要一上来画十个服务，先说对象、读写链路和最难的一处容量问题。BQ 准备冲突、线上事故和跨团队推进三个故事，每个都写下数字和反问。
FAQ
Meta VO 的 Coding 题要写完整可运行代码吗？
按能运行的标准写最稳。变量命名、函数边界和异常输入都要照顾到；时间不够时先完成主路径，再明确说下一步会补哪些测试。
Feed 设计里为什么要同时用两种 fanout？
普通作者的写入量可控，预先分发能让首页读取更快。热门作者直接分发会放大写入，读时合并更划算。
关于 CSOFFERPREP
准备 Meta VO 时，CSOFFERPREP 可以提供算法训练、模拟面试、项目深挖和系统设计辅助。导师来自北美一线工程团队，能按岗位把题目追问和表达节奏拆开练。无论是 OA辅助、OA 辅导、VO 辅助、VO 模拟面试、VO 辅助还是系统设计辅助，都可以获得更有针对性的准备方案：CSOFFERPREP · 服务详情
