别背方案了，面试官看的不是这个
别背方案了，面试官看的不是这个
“设计一个短链接系统。”
我坐在面试桌对面，刚把这句话说完，候选人就开始了——打开白板，唰唰画了三个方框，写上”Nginx → Application Server → Redis”，然后抬头看我：”我打算用 Redis 做 KV 映射，短链用 Base62 编码，预估 QPS 大概……”
我微笑着点头。但我心里已经默默写下了第一行评语：上来就画架构，没有问任何一个需求问题。减分。
这哥们技术功底不差，Redis 用法也没毛病。但他犯了系统设计面试里最普遍的错误——把面试当成了知识竞赛，而不是思维展示。
你以为考的是方案，其实考的是决策
大多数候选人走进系统设计面试，脑子里装的是一套”标准答案”：短链系统用 Redis、消息队列用 Kafka、分布式锁用 ZooKeeper……他们花了大量时间背方案、记架构图，生怕面试官问到一个自己没见过的系统。
但真相是——我根本不在乎你选 Redis 还是 MySQL。
我在乎的是：你凭什么选的？你考虑过什么替代方案？你知道这个选择会带来什么代价吗？
系统设计面试不是开卷考试，是开放式讨论。没有标准答案，甚至同一道题，不同面试官心里的”好答案”都不一样。我见过候选人用 MySQL 做短链映射，照样拿了 Strong Hire——因为他能把为什么用 MySQL 而不用 Redis 说得头头是道，trade-off 分析滴水不漏。
也见过候选人把 Redis、Kafka、Elasticsearch 全堆上来，搞了个”完美架构”。我给的评价是：过度设计，不考虑实际约束。
面试官打分的不是你的方案有多完美，而是你面对模糊需求时怎么拆解、怎么选择、怎么取舍。
面试官的评分卡，跟你想的不一样
做了这么多年面试官，聊了上百个候选人，我发现一件事：候选人以为分数都在”方案”上，但我的评分卡根本不是那么分的。
最值钱的 30% 给了需求澄清。你拿到题目后的前五分钟，是最能拉开差距的环节。”日活什么量级？”“需要支持自定义后缀吗？”“有过期时间的需求吗？”这些问题不是在浪费时间——每一个好问题都在帮你缩小设计空间，也在向我证明你懂得先想再做。
40% 给了核心设计和 trade-off 分析，这是重头戏。我不怕你选错方案，怕的是你选了却说不出为什么。”我用 Redis 因为它快”——这叫说了等于没说。”我选 Redis 是因为高读低写场景下 KV 天然匹配，代价是持久化弱，所以加一层异步写 MySQL 兜底”——这才叫 trade-off。差距就在这一两句话里。
剩下的 20% 给技术深度——我会揪住一个点往死里挖，比如”Base62 会不会碰撞？碰撞了怎么办？”你不用样样精通，但总得有一两个点能让我觉得”这人有真功夫”。最后 10% 给扩展性思考，分值不高，但答得好是加分项。
注意到没有？“正确答案”这四个字，压根不在我的评分卡上。因为开放题没有唯一正确答案。你用 Redis 拿高分，用 MySQL 也能拿高分——关键看你怎么说。
这就像现场做菜，不是背菜谱
我喜欢用一个比方来解释这件事——系统设计面试就像厨艺比赛。
你走进厨房，台面上摆着一堆食材：鸡肉、土豆、西红柿、各种调料。考官说：”做一道菜。”
糟糕的选手上来就做宫保鸡丁——因为他背过这道菜的做法，管你桌上有没有花生米和干辣椒。做到一半发现没花生米，慌了。
好的选手会先看一圈食材，再问一句：”几个人吃？口味偏好？有没有忌口？”然后根据实际情况决定做什么。没有花生米？那就做番茄炒鸡丁，照样好吃。
评委看的从来不是你做了哪道菜，而是三件事：
第一，你有没有先搞清楚谁要吃——这就是需求澄清。第二，你能不能在有限食材里选出最合适的搭配——这就是 trade-off。第三，遇到缺食材的时候你怎么应变——这就是工程判断力。
背了一百道菜谱的人，遇到没见过的食材组合还是会懵。但真正会做菜的人，给他任何食材都能整出一盘能吃的东西。
系统设计面试考的就是这种”现场做菜”的能力，不是”背菜谱”的记忆力。
45 分钟怎么分配？聊聊我见过的聪明打法
说了半天”考什么”，你肯定憋着一句：那到底怎么答？
我不想给你一个”万能模板”——背模板进考场，面试官比你更熟那套路，一眼就穿帮。但我可以告诉你，那些拿到 Strong Hire 的候选人，他们的 45 分钟大致是怎么花的。
头 5 分钟，他们一笔没画。
这是最反直觉的地方。你拿到题目，肾上腺素飙升，手痒得要命，恨不得立刻抓起笔画三个方框写上”Load Balancer”。但我印象最深的一个候选人，拿到”设计一个聊天系统”之后，愣是问了我六个问题——群聊要不要支持？已读回执要不要做？离线消息存多久？文件传输算不算 MVP？
五分钟过去，白板上干干净净。但我评分卡上已经写了四个字：需求感强。
90% 的人做不到。他们太急着证明自己”会”，结果暴露的恰恰是自己不会”想”。
接下来 15 分钟，最好的候选人都有一个习惯：自言自语。
不是真的嘟嘟囔囔，而是每画一个方框、每做一个选择，都顺嘴说一句为什么。
我遇到过一位，画到消息推送的时候说：”这里我用长轮询不用 WebSocket，因为刚才确认了用户量级不大，长轮询实现简单、兼容性好。等日活过百万再切 WebSocket 也不迟——架构留好口子就行。”
这段话值多少分？在我心里，它一个人顶了三个方框。因为他不是在”画架构图”，他是在做可见的决策。我能看到他的脑子在转，看到他在权衡、在取舍——还知道什么阶段做什么事。
反面教材呢？默默画了五个方框，回头看我一眼：”嗯，大概就是这样。”我内心 OS：你脑子里到底想了什么，我一个字也没听到。
20 到 35 分钟，控制权到我手里了。
这一段像审讯——我会盯着你某个设计细节往下挖。”Base62 编码碰撞了咋办？”“缓存和数据库数据不一致你怎么处理？”
说实话，我问这些不全是为了考倒你。我是在给你机会——机会展示你在某个点上有真功夫。你不用每个领域都精通，能在一两个地方聊出深度就够了。
遇到不会的怎么办？我见过最聪明的回答是：”这块我实战经验不多，不过按照刚才的分析，我倾向于……”坦诚但不放弃思考。承认不知道扣一分，硬编被我抓住扣十分。这笔账，你自己算。
最后 10 分钟，我喜欢聊”如果”。
“流量翻 10 倍，你觉得哪里先扛不住？”“产品经理说要加个数据分析功能呢？”这些问题我不期待完整方案——我就想看你能不能从眼前这盘菜里，看到一桌宴席的可能性。能聊到这一步的人，通常段位不低。
回到那个短链接系统
还记得开头那位候选人吗？上来就画 Redis，方案本身没问题，但他跳过了最值钱的环节——需求澄清。
如果你拿到”设计一个短链接系统”这个题目，第一句话是”请问这个系统预计的日活用户大概是什么量级？”，面试官已经在心里给你加分了。
不是因为这个问题有多高深，而是因为它说明你知道——不同量级的系统，设计方案完全不同。 给 1000 人用的短链服务和给 1 亿人用的短链服务，架构差了十万八千里。你问这一句，就已经和那些上来就画 Redis 的人拉开了差距。
系统设计面试不是知识竞赛，是思维展示。面试官坐在你对面，不是在等你说出那个”正确答案”。他是在观察你怎么处理不确定性、怎么做取舍、怎么在有限信息下做出合理的工程判断。
会背菜谱的厨师到处都有，能用任何食材现场做出好菜的，才是大厨。