结束 Meta NG 的全流程面试，整体节奏比我预期的要舒服很多。Coding 在 CoderPad 上写，不强制跑通测试，但必须自己做 dry run、主动讲边界；后面几轮 BQ 追问很深，还会夹带一点业务向的设计讨论。下从投递到结果大概 3 周，每轮结束基本两三天就有反馈。
第一轮：Gen AI 经历 + 机架分配
前半段围绕 Generative AI 辅助开发聊。面试官重点问 AI 生成代码的风险：幻觉、不可复现、错误信息，以及你怎么用 Code Review、自动化测试、回归和 Human-in-the-loop 把质量兜住。不要只说“用了 Copilot”，要讲清楚你实际怎么卡质量门。
Coding 是机架分配：多个 Server Rack，各自剩余功率不同。给定一项 Power Requirement，要找能满足需求、且分配后剩余容量最小的机架（Best Fit）。
暴力是扫一遍所有机架。优化可以用 TreeMap 按剩余容量建有序索引，ceilingKey 找到第一个不小于需求的容量，单次查询降到 O(logR)。分配后删掉旧记录，把更新后的容量重新插回去。
相关练习可以看 LC 1845（座位资源分配）和 LC 729（基于有序结构的范围查找）。
第二轮：餐厅座位管理系统
设计 Restaurant Seating System。桌子容量不同，一组客人来了，要找能坐下且容量最小的空桌，减少浪费。
可以用 TreeMap 按容量维护空闲桌。客人到达后 ceilingKey(groupSize) 取最小合适桌；暂时没有就进 FIFO 等待队列，有桌释放再从队首开始尝试分配。
面试官追问：队首要 8 人桌，当前只释放了 4 人桌。如果 Strict FIFO，队首不能被跳过，后面即使有合适的小桌也动不了，容易出现 Head-of-line Blocking。可以对比：
- Strict FIFO：公平，但利用率可能差
- 允许跳过队首的 Best-fit：利用率更高，公平性弱一些
- 加 Maximum Waiting Time：在公平和吞吐之间折中
每组只用一张完整桌，不做拆桌或拼桌。相近题：LC 1845、1942，以及调度向的 1834。
第三轮：Behavioral 深挖
这一轮 BQ 追问很细。
技术经历里聊到 Kafka Hot Partition，可以从 Key Salting、随机后缀、重新设计 Partition Key、增加 Partition 数量等方向讲流量打散；再结合 max.poll.records、max.poll.interval.ms 和 Consumer Lag，说明消费批次、处理时长和 Rebalance 风险的关系。
负面反馈题建议选真实、有后续改进的例子。比如一次大 PR 因 Review Cost 太高被吐槽，后来拆成 Smaller PR、上 Feature Flag、用标准化 PR Template，把协作流程改顺。按 STAR 讲清楚：情境、任务、你做了什么、结果如何验证。重点不是“我从没犯错”，而是你会接收反馈、定位问题、推动改进。
第四轮：Leadership BQ + Playlist 洗牌
先问 Leadership 相关 BQ，再进入 Coding。
Playlist Shuffling 歌曲要分轮生成播放顺序：同一轮内不能重复；相邻两轮的末尾歌和开头歌也不能相同。
按轮构建列表，用 HashSet 保证单轮无重复；记下一轮最后一首，生成下一轮时避开它当开头。总播放次数 N、歌曲种类 M 时，复杂度可以做到 O(N+M)。
要主动提 Impossible Case：候选只剩一首，且正好和上一轮末尾相同，当前约束下可能无解。这时系统是返回失败、重新洗牌，还是放宽“相邻不能相同”，需要说清楚取舍。
没有完全一致的 LC 原题，可练 384（Fisher-Yates）、767 / 1054（避免相邻相同），若按权重出现再补 Weighted Random / Alias Method。
Coding 结束后还聊了 Tech Stack 和 On-call，建议提前准备 Incident Response、Alert Triage、RCA、Postmortem 一类案例。
高频 Coding 与对应练习
| 题型 | 参考 |
|---|---|
| 有效数字 | LC 65（FSM / 规则解析） |
| 子树平均值相等节点 | LC 2265（后序同时返回 sum 与 count） |
| Top K 高频 | LC 347（HashMap + 大小为 K 的堆，或桶排序） |
| 区间最大重叠 | LC 253 / 2406 思路（扫线、差分数组、端点排序） |
| 合并区间 / 课程表 | LC 56、207（拓扑排序判环）——CoderPad 上很常见，写完一定要 dry run |
Meta Coding 轮更看思路和 dry run，不强制 AC 所有用例。空输入、单元素、相邻端点、有环/无环，主动讲出来加分。
System Design 补充：实时排行榜
若碰到类似 Real-time Leaderboard：分数变更后如何及时更新排名，并高效取 Top K、查某用户名次及附近名次。
先 Clarify：DAU、读写比、更新频率、榜单维度、一致性、保留策略；再粗估 QPS、存储和峰值。
高层设计可围绕 Score Ingestion → MQ → Ranking Service → 存储 / Cache → Query。小规模用 Redis Sorted Set（ZADD / ZREVRANGE / ZREVRANK）很直接；规模上来要考虑分片、Hot Key、全局合并、异步更新、乱序与幂等（版本号 / 序列号拒掉过期更新）。测试要覆盖并发更新、重复事件、乱序、消费者重启和部分失败。
经典还可准备 News Feed、Messenger、爬虫、Typeahead。
一点体会
今年 Meta NG / 偏 MLE 的方向，更贴近业务：推荐、排序、上线后的工程取舍，而不只是刷题和调参。Coding 要熟 tag、会 dry run；BQ 要有能深挖的真实故事；设计题把 trade-off 讲清楚。
若也在准备 Meta，可以把区间、图、堆、有序结构和一轮排行榜设计过一遍，再准备 3–4 个能经得起追问的 BQ。需要的话也可以了解 InterviewShow，大厂OA/VO带过不少人。