Meta面试官扎心实录：487道算法题白刷

487道。按每天3道的节奏，整整刷了5个月零11天。Devrim Ozcay把LeetCode刷到"贡献值"页面能当简历附件用，却在Meta第3轮面试里，被"设计Instagram"这个问题直接送走。

他后来把这段经历写成了文章，标题带着自嘲，但数据很诚实——6个月算法训练，换不来一张L4级别的offer。这不是个例。2024年FAANG（脸书、亚马逊、苹果、奈飞、谷歌）面试数据显示，系统设计在L4及以上岗位的权重占比已从2019年的15%飙升至35%，而纯算法题的决策权重首次跌破40%。

「我解完了所有中等题，直到面试官说'设计一个feed流'」

Devrim的刷题路径很典型：从Easy起步，三个月内扫完Medium，最后硬啃Hard。他的GitHub提交记录像心电图一样规律，周末不断档。面试前一周，他甚至能闭着眼写出红黑树的旋转逻辑。

Meta的前两轮很顺利。编码题是"合并K个有序链表"的变体，他用了最小堆，时间复杂度讲得清清楚楚。面试官点头，他也点头，双方都觉得这事成了。

第三轮换了个房间，换了个人。对方没给LeetCode链接，只抛了一句话："假设你是Instagram的早期工程师，从零设计feed流系统。"

Devrim后来回忆：「我的大脑瞬间切换到'这题我做过'的模式，然后开始背诵——用Redis做缓存，MySQL存关系，Kafka处理事件。像报菜名一样。」

面试官打断了他："如果用户有1亿粉丝，你的推送延迟是多少？"

他愣住了。487道题里，没有一道问过这个。

算法题考的是"解"，系统设计考的是"猜"

Devrim把这次失败拆解得很细。他发现两者的考核逻辑完全不同：

算法题有标准答案。输入、输出、复杂度，像数学证明一样可验证。你写对了，机器就给你绿勾。

系统设计没有。面试官要看的不是你"知道"什么，而是你"怎么猜"——在信息不完整的情况下，做出合理假设，权衡取舍，然后为自己的选择辩护。

Devrim当时犯的错，是试图用"背诵"代替"推导"。他说"用Redis"，但没解释为什么不用Memcached；他说"Kafka"，但没讨论如果消息丢失怎么办。面试官每追问一层，他的回答就越像从博客里抄来的。

「我后来意识到，」他写道，「算法题练的是肌肉记忆，系统设计练的是决策肌肉。一个是闭卷考，一个是开卷辩论。」

这种错位在行业内很普遍。Hacker News上有个帖子统计过：刷题300道以上却挂在系统设计的候选人，2023年比2021年增长了217%。不是题变难了，是考核的重心在转移。

从"做题家"到"架构师"：一个被验证的框架

Devrim没放弃。他花了8周重新准备，第二次面试拿到了Google L4的offer。他的方法不是找更多题，而是建立一个可复用的思考框架。

他把这个框架称为"4S"——Scope（范围）、Sketch（草图）、Scale（扩展）、Solidify（固化）。

第一步Scope最关键。面试官说"设计Instagram"，你不能直接开始画框图。Devrim的做法是：先问清楚场景边界。是侧重发布流程，还是推送分发？日活用户多少？读写比例如何？这些不是客套，而是展示你理解"问题比解法更重要"。

第二步Sketch要求你在5分钟内给出端到端的草图。不是完美架构，是能跑起来的骨架。Devrim的习惯是：先画客户端、API层、数据层三层，用箭头标出主要数据流。这时候不纠结技术选型，先让面试官看到你有全局视角。

第三步Scale是拉开差距的地方。Devrim会主动抛出瓶颈假设："如果用户增长到10亿，这个数据库分片策略还能撑住吗？"然后自己给出两种方案——垂直扩展和水平扩展——比较各自的代价。这种"自问自答"的节奏，让面试官从考官变成听众。

最后一步Solidify，是把讨论过的点固化成可落地的细节。缓存策略用写穿透还是写回？一致性要求强一致还是最终一致？每个选择都要有回退方案。

「这个框架的价值，」Devrim总结，「是让你从'被拷问'变成'带节奏'。面试官的追问，其实是在帮你展示深度。」

数据不会说谎：为什么FAANG越来越"重设计轻算法"

Devrim引用了一些内部数据。Meta的L4面试评分表里，"系统设计"和"编码能力"的权重各占30%，但编码的容错率更高——小bug可以当场修复，设计方向的偏差很难挽回。

Google的招聘数据更极端：2024年L5及以上岗位，系统设计面试的通过率（34%）显著低于算法轮（52%）。不是因为设计更难，而是候选人准备不足。大多数人还在用刷题的思维准备设计——找"标准答案"，背"最佳实践"。

这种错位的根源，是两种能力的习得路径完全不同。算法题有LeetCode、Codeforces、AtCoder，有即时反馈的在线判题系统。系统设计没有。你没法在20分钟内知道自己设计得好不好，反馈周期以月计，而且依赖真实场景。

Devrim的解法很务实：他找了三个在职工程师做模拟面试，每次录屏复盘。他发现，自己第一次在"扩展性"讨论中平均停留90秒，第三次能撑到8分钟——不是话变多了，是学会了用数字支撑假设。

「当你说'延迟要小于200毫秒'，比说'要很快'专业十倍。但数字从哪来？得靠平时积累，看论文、看工程博客、看故障复盘。」

一个被忽略的细节：面试官真正在听什么

Devrim第二次面Google时，注意到了一个变化。当他开始讨论数据库分片策略时，面试官突然问："如果让你牺牲一致性来换可用性，你愿意吗？在什么条件下？"

这是个陷阱问题。CAP定理（一致性、可用性、分区容错性三选二）没有标准答案，只有场景适配。Devrim当时停顿了3秒，然后说：「如果是点赞数，我可以接受最终一致；如果是支付状态，我必须强一致。这个决策的边界，我会和产品经理一起定义。」

面试官笑了。后来他被告知，这个回答是关键加分项——因为它展示了"工程师不是技术的奴隶，是业务的翻译者"。

Devrim把这段经历写进总结时，加了一个脚注：「487道题让我进了面试房间，但让我拿到offer的，是学会在不确定中做决策。」

他现在的GitHub主页上，LeetCode的刷题记录还在，但置顶的是一个系统设计笔记仓库， starred数已经超过了前者。最近一条commit的message是："Added: How to say 'I don't know' without sounding incompetent."

如果你明天就要面试，而今晚只能准备一件事——是再刷10道Hard，还是画一遍你最喜欢产品的架构图，然后问自己三个"如果规模扩大10倍"的问题？