LeetCode刷题没用？大厂笔试三大陷阱与破解策略

上周 LeetCode 周赛 430 一结束就有个准备秋招的学弟给我发了条消息原话大概是哥现在笔试还刷 LeetCode 还有用吗我昨晚做模拟题一道题读了三遍都不确定它在问什么感觉跟我刷的题完全不是一回事。我太懂这种感受了。他说的不是一回事并不是题变难了而是题变厚了。以前笔试是一眼能看出考点现在则像读需求文档以前只要你AC了就万事大吉现在笔试平台会记录你每个测试用例的耗时、内存甚至代码本身会被面试官调出来当面复盘。标题里那个90%我没法精确统计但说实话按我这些年看过的笔试反馈倒在这三类题上的人比例真不比90%低多少。这篇就把我觉得最要命的三个陷阱掰开讲清楚然后告诉你应该怎么调整刷题和上考场的策略。1. 先搞清楚笔试不是不考算法了是换了一种考法很多人的第一反应是大厂不考算法了——恰恰相反算法不但考而且考得更细、更隐蔽。变化的不是知识范围而是题目外衣和评价标准。1.1 一个旧题新考的样本拿最经典的 LRU 缓存来举例。老题库里的描述很短设计并实现一个满足 LRU 约束的数据结构。三行读完直接写代码。现在的大厂笔试题会长什么样我整理过真实反馈大概是这种感觉直播间的热门礼物列表需要在短时间内被高频读取同时要实时淘汰掉已经过气的礼物保证内存占用不超过 X MB。请设计一个存储结构支持在 O(1) 时间内完成查询和更新……你看本质还是实现一个 LRU但多了一层业务包装。有人读完就懵了这考的是系统设计还是算法其实剥掉外壳考点一点没变双向链表 哈希表。再比如 LeetCode 上那道 875 题爱吃香蕉的狒狒Koko Eating Bananas一直被归类为经典二分答案入门。这类题的价值恰恰在于它自带一个故事外壳——你要从几小时内吃完这种场景描述里抽象出速度 K 与用时单调递减的关系然后套二分。大厂笔试现在大量采用这种场景 算法的复合题型你光会背模板不够还得会从题面里把模板拽出来。1.2 三个让考生不适应的变化信号我把最近几批笔试反馈归了归类真正让人翻车的不是题目难而是三个变化信号没接住。第一个信号是题干变长。以前一道题三五行现在一道题能写满半屏甚至一屏夹杂着业务术语、数据规模限制、甚至输入输出的奇怪格式。这考验的是耐心和信息提取能力很多人不是不会做是压根没读懂。第二个信号是约束条件变硬。题目里直接写明空间复杂度必须为 O(1)整体时间复杂度必须为 O(n log k)这类硬性要求会直接把你的第一反应解法判死。比如你刚想用堆 哈希表做 TopK题目立刻要求不能用内置优先队列你怎么办第三个信号是评价维度变多。现在有些大厂笔试平台不只统计最终正确率还记录每组测试用例的运行时间和内存占用。极端情况下甚至会出现所有用例通过但总耗时超限判失败的机制。换句话说你的解法不再只是对与错的二分而变成了好不好的梯度评分。这么说吧LeetCode 并没有退出历史舞台但它更像健身房里的器械你练的依然是肌肉力量大厂笔试则像是实际运动场上的比赛同一块肌肉得在复杂规则下发挥。接下来逐个拆这三类让人摔跟头的题。2. 陷阱一业务包装题——从裸算法到披着场景的算法2.1 这类题的真实长相这类题最显著的特征是题干必须给你编一个业务故事。我整理几个高频出现的场景原型你对照着看就明白了。推荐系统场景给出用户的历史点击序列要求返回每个用户最常消费的前 K 个内容。剥开是 TopK 频率统计对应堆或快速选择。订单调度场景系统中有大量订单每个订单有超时时间戳要求高效清理已超时订单。剥开是优先队列 / 时间轮 / 有序集合的过期淘汰。日志合并场景多个服务产生有序日志要求按时间全局合并后输出前 N 条。剥开就是多路归并。任务编排场景一批任务存在依赖关系部分任务只能在其他任务完成后执行要求输出一种可执行顺序。剥开就是拓扑排序。你看业务故事千变万化但算法骨架就那么几十种。这类题真正难的不是解法而是你能不能平静地把故事读完然后给它祛魅。2.2 为什么大厂热衷这么出题从面试官的角度看这几乎是必然的选择背后有三层逻辑。首先是防背题。LeetCode 热门 100 题早就被翻烂了直接出原题等于给背题党送分。业务包装成本极低效果却立竿见影——没真理解算法本质的人题面一换就露馅。其次是筛选工程抽象能力。你写业务代码的时候面对的是需求文档、产品描述、线上故障你需要从中抽取关键逻辑落成数据结构和算法。笔试加一层业务包装恰恰是在模拟真实工作状态。最后是考察结构化思维。能不能把一段混乱的描述拆成输入、输出、约束、目标四个要素这在任何岗位都是基本功。有些人在故事面前乱了节奏这不只是算法问题更是信息处理能力的短板。2.3 破题方法三步剥离法面对业务包装题我自己的方法是固定的三步你也可以直接拿去用。第一步圈出题干里的行为动词。几乎每道题都有核心动作缓存、删除、合并、排序、找最大、判依赖、求连通。把这些动词抄下来你就把故事小说读成了操作指令。第二步把业务名词映射到数据结构。用户 ID、订单 ID、物品 ID 基本都是键时间戳基本都是序列或排序依据前 K 个最大的最热的全部指向堆或快速选择依赖关系先后顺序指向图论。第三步根据输入规模决定算法档次。数据量在百级、千级直接暴力万级考虑 O(n log n)百万级以上就要想 O(n log k) 甚至 O(n) 的解法。这一步能帮你避免一上来就优化过度或者暴力跑死两个极端。以爱吃香蕉的狒狒为例看到最小速度 K基本能锁定二分答案再看到H 小时内吃完确认需要在二分里套一个 check 函数去模拟每堆香蕉的吃法。这时候故事外壳已经完全脱落剩下的就是二分的标准骨架。我个人的体会是这一步剥离做得熟练以后刷题速度会明显变快。因为你不只是在记住某道题的答案而是在训练一种通用的题目阅读器。3. 陷阱二复杂度约束题——会解不等于能解3.1 一个会做却拿不到分的典型镜头第二类坑不是看不懂题而是看懂了题但解法不过关。我拿一道非常经典的题来说给定一个大文件里面有几百万行日志每行包含用户 ID 和访问次数要求返回访问次数最高的前 K 个用户。正常训练过的人第一反应是哈希表统计 全局排序然后立刻掏出 PriorityQueue 把所有元素灌进去排序最后截取前 K 个。在小数据量下这个解法没有毛病但在几百万量级下它的问题就很明显——全局排序的时间复杂度是 O(n log n)空间上还要保留全部 n 个元素。笔试题的硬约束可能就是时间复杂度 O(n log k)空间复杂度 O(k)。于是大量考生就栽在这里明明知道这题怎么做但一提交要么内存超限要么总耗时超标。这就是会解和能解之间的差距。3.2 时间与空间的博弈题目在逼你做工程决策为什么大厂一定要把约束写得这么死我做过几次内部出题讨论大家共识出奇一致真实系统里没有无限资源。线上服务的 Redis 内存是有配额的消息队列的积压是有容量上限的接口的 P99 时延是有 SLA 的。你在笔试里写一个先全部装进内存再排序的解法等于在真实系统里做了一次高风险的内存透支。这类题目考察的其实是工程权衡能力。典型场景包括用空间换时间比如哈希表 O(1) 查询但牺牲部分内存。用离线换在线比如把在线实时 TopK 改成离线批次统计用小顶堆把堆顶卡在 K 附近空间永远只有 K。用预处理换响应比如对日志做预先排序或索引查询时直接取前 K 个。处理这类题我的核心建议是先写暴力再分析瓶颈再针对性优化而不是一上来就奔向最优解。有些人怕写暴力被扣分实际上在笔试里能正常运行出结果的暴力解通常能拿到相当一部分的过程分。更重要的是先把暴力写对能验证你对题目的理解没有跑偏后续优化才谈得上。3.3 现场解题的通用顺序我自己在笔试题上有一套固定的落地顺序分享给你参考。第一步用注释把题目翻译成人话包括输入是什么、输出是什么、数据规模大概是多大。这一步能极大概率避免理解偏差。第二步判断一个可接受的时间复杂度上限。假设数据规模是 n看题目时限一般 1 到 2 秒可以粗略估算n 在 10^5 左右要 O(n log n)n 在 10^6 以上基本要 O(n)n 在 10^3 以下可以偏暴力。第三步写出暴力版本并自己在脑内跑一遍小样例。这一步不是浪费时间而是建立基准。就算最后你优化失败至少有一个正确但慢的兜底答案。第四步标记暴力解法里的瓶颈操作。是排序太慢还是查找太慢还是重复计算太多针对瓶颈选择优化策略排序太慢换堆或快选查找太慢换哈希或前缀和重复计算太多换 DP 或双指针。第五步在提交前把两种解法的复杂度都写进注释里。原因待会儿在第四个陷阱里细说。这套流程的本质是强迫自己先想清楚再动手而不是读一遍题就埋头敲。很多翻车现场都是因为跳过了前面的步骤直接凭经验选了一个看起来正确的数据结构。4. 陷阱三代码质量题——从 AC 到像样交付4.1 从AC到AC 可读的评价变化如果说前两类陷阱坑的是算法能力第三类坑的就是所有只刷题、不写工程的考生。过去我们对笔试代码的要求就一条AC。但现在不少公司会在笔试通过后把代码调出来人工看一眼面试现场也会说你先讲讲笔试第三题你的思路。那一刻你代码里的变量名 a、b、tmp写了 50 行的主函数没有任何边界检查都会赤裸裸地暴露在面试官面前。这不是危言耸听。我有一次帮人做模拟面试对方笔试题 AC 了但代码里有个全局变量在多个函数里被复用来复用去。我问这个变量为什么在第二个用例里会被重置他愣了半分钟最后承认自己没想过。本质上笔试已经从机器判分悄悄变成了机器判分 人工评审的双重评价体系。4.2 最容易暴露基本功的三处细节具体来说这三处细节最容易被放大检视也最容易拉开差距。第一处是输入边界和异常输入。数组为空、只有一个元素、值域达到题目上限、数值相加可能溢出——这些 corner case 不是附加题而是基本功。我见过不少人主流程写得很漂亮但一个if (arr null || arr.length 0)都没有。笔试平台可能不会为这些 case 单独设计样例但面试官复看时一眼就能看出来。第二处是命名与函数拆分。变量叫 idx 没问题但最好是 windowStart、kthValue、nextTime 这种带语义的名字。超过 20 行逻辑就往小函数里拆比如 splitIntoChunks、isTaskReady。很多人觉得笔试时间紧写得快就行但快和乱从来不是一回事。第三处是注释思路而不是注释过程。不要写// 这里遍历每个元素而要写// 滑动窗口右边界每次右移一位左边界用于在窗口不合法时收缩。前者是流水账后者是在展示你的思考链。面试官想从代码里看到的是你的思路不是代码执行轨迹。举个例子同样是滑动窗口求最小覆盖子串差劲的写法可能是def minWindow(self, s, t): # 初始化 need {} for c in t: need[c] need.get(c, 0) 1 l 0 r 0 cnt len(t) res s a while r len(s): if s[r] in need: if need[s[r]] 0: cnt - 1 need[s[r]] - 1 r 1 while cnt 0: if len(s[l:r]) len(res): res s[l:r] if s[l] in need: need[s[l]] 1 if need[s[l]] 0: cnt 1 l 1 return res if res ! s a else 能AC但变量名没有任何语义。换成下面的写法面试观感完全不同def minWindow(self, s: str, t: str) - str: # 用 need 记录目标串还缺多少个字符缺的字符数量为 missing need collections.Counter(t) missing len(t) left 0 res min_len float(inf) for right, ch in enumerate(s): # 右边界进入窗口如果这个字符正好是需要的missing 减少 if need[ch] 0: missing - 1 need[ch] - 1 # 窗口已经覆盖目标串尝试收缩左边界 while missing 0: cur_len right - left 1 if cur_len min_len: min_len cur_len res s[left:right 1] # 左边界移出窗口恢复 need 计数 need[s[left]] 1 if need[s[left]] 0: missing 1 left 1 return res核心逻辑一样但读代码的人不需要来回跳跃去猜变量含义。这也是我一直强调的你把笔试代码当成一段要交付的代码来写而不是一份草稿。4.3 把笔试代码当成待评审代码来写我自己的习惯是代码写完先不当场提交而是从头到尾通读一遍假装自己是面试官然后问自己几个问题为什么用哈希表不用有序列表为什么边界用小于等于而不是小于为什么先排序再二分而不是边遍历边二分为什么这里可以不用考虑整数溢出每想明白一个为什么就在对应位置加一行注释。这一步看似浪费时间但它在帮你把隐式的思维过程显性化。面试官读你代码的时候其实是在模拟和你对话。你注释里想清楚了他就不需要反复猜自然对你评价更高。甚至可以说这道题答对只拿了 60% 的分剩余 40% 全在你代码里体现的工程素养。刷题刷久了的人最容易忽略这一点但恰恰是这一点决定了你和其他候选人之间的区分度。5. 重新调整你的刷题与笔试策略说完三个陷阱最后讲怎么应对。我给你的不是每天刷十道题这种空洞鸡汤而是一套可以立刻执行的策略。5.1 把 LeetCode 当健身房而不是题库第一每周参加周赛当模拟笔试。周赛的时间压力、题目未知性和真实笔试非常接近。你不需要纠结排名而是把它当成一次限时演练练的是如何在 90 分钟内分配精力和如何面对没见过的题不慌。第二每道题尽量做多解。一道题 AC 了再想想如果数据规模扩大十倍还能不能过如果内存缩小十倍呢热门 100 题里的题至少都值得做两遍以上但每次做都要带着新约束去做最好能在注释里写出两种解法的时间、空间对比。第三训练一题三问的习惯。看到一道题不要只满足于会写多问自己如果场景换成实时流式数据怎么做如果输入是分布式的怎么拆如果返回值要求有序怎么办这个过程就是在模拟业务包装题的命题思路。5.2 笔试现场的时间分配与自测流程以一场 90 分钟 3 道题的标准笔试为例我的通用时间分配是这样的前 10 分钟通读所有题不写代码。快速判断每道题的类型裸算法、业务包装、系统交互模拟按自己熟悉的程度排个做题顺序。先做最有把握的题把保底分拿到手。每题先确认理解把输入、输出、数据规模、时限要求写在注释开头再动手。每题用暴力 优化两步走先确保一个能跑出正确结果的版本再针对性能瓶颈优化。宁可优化没做完也不能出现主流程没写完的情况。最后留 5-8 分钟做全卷检查检查变量命名给核心函数补注释跑几个边界 case空输入、单元素、最大值。一定要逼自己在最后留出自查时间。很多人不是不会做而是提前 20 分钟就写完然后干等交卷结果漏掉了最基础的边界处理。如果你能每次笔试都系统地走一遍这个流程你的得分稳定性会明显提升。5.3 长期来看这个变化是好事我知道这些变化让人焦虑尤其是准备很久的人突然发现自己刷的题不顶用。但换个角度看大厂笔试越来越像真实工作其实是在变相保护真正有代码功底的人。我见过太多简历写得天花乱坠、一到现场就露馅的候选人也见过一些基础扎实、平时写代码就注重规范和边界的年轻人笔试反而稳稳当当。这类人不需要临时突击他们平时写内部工具、写自动化脚本时养成的习惯已经在给他们加分。笔试考的不再是你刷了多少题而是你能不能像工程师一样思考这对行业、对认真做事的人都是好事。最后给你一个马上能用的小建议今天刷题的时候不必追求数量挑一道你已经 AC 过的题用业务包装 硬约束 代码评审三重标准重新做一遍。你会发现同一道题用面试官的眼光看处处都是可以优化的细节。这样的训练做满两周你会明显感觉到自己笔试时的状态不一样了。