老有人问我十年前的美团笔试到底考什么和现在的互联网公司笔试有什么区别。我也翻出过不少老题其中“美团2013湖南研发工程师笔试卷”这份流传很广的卷子确实是观察国内互联网研发岗早期面试风格的一个不错样本。那时候移动互联网刚起来美团还在“千团大战”里厮杀研发岗笔试考的东西跟今天动不动就系统设计、机器学习八股、源码深挖的路子不太一样反而是最朴素的计算机基础、逻辑思维和手写代码能力。这套卷子在我看来检验的不是你背了多少框架而是你有没有一个工程师的基本盘。如果你是准备秋招的在校生或者想跳槽到互联网公司做后端、客户端的社招选手这套题都值得认真看一遍。它帮你把“基础到底重不重要”这个问题回答得很清楚——真的重要。这篇文章我会从试卷结构、核心考点、做题策略、背后的能力模型几个角度把这套经典笔试卷彻底拆开顺便聊聊它对我后来面试别人、带新人的实际影响。1. 试卷整体结构与命题逻辑1.1 从“2013湖南”这个标签能读出什么很多人看到这个标题第一反应是“为什么是湖南”。2013年前后美团虽然总部在北京但已经在大量铺开城市站研发团队也不是全部都锁在北京。湖南有高校集群有不错的技术人才储备在长沙设立研发岗位或者针对湖南地区集中招聘是很正常的做法。所以这份笔试是“区域招聘”背景下的产物但题目的含金量一点都不低因为招聘目标很明确招能直接上手的研发工程师而不是培训生。那个年代笔试的通用套路是选择题刷基础、填空题抠细节、编程题考手写代码、简答题看理解深度。美团这份卷子基本沿用了这套框架但有些地方明显带着业务思考。比如有的题会结合“团购、海量订单、商家数据”这种场景来出不像一些大厂早期卷子纯粹出数学题。这说明美团当时就非常看重一个工程师能不能把技术和业务场景绑定起来。1.2 研发工程师笔试的四大模块与考察意图从后来流传出来的考生回忆和题目片段看2013年这套题大致可以分成四个模块模块占比估算典型考察点命题意图数据结构与算法35%~40%链表、二叉树、排序、动态规划、复杂度分析判断编码基本功和逻辑思维操作系统与网络20%~25%进程线程、死锁、TCP/IP、HTTP判断是否具备后端服务的基础认知数据库与SQL15%~20%索引、事务、SQL查询编写判断数据建模和数据操作能力逻辑题与开放题10%~15%推理题、场景设计、压力应对判断思维方式和工程判断力这种结构在今天的笔试里依然常见只是难度和形式有些变化。当年最让我感慨的是它的“裸考友好度”——不依赖特定语言C、Java都可以关键是思路清晰、代码可读。这比现在某些直接出“源码头头是道”的题要更考验真本领。2. 算法与数据结构笔试的绝对主角2.1 为什么大厂笔试总绕不开链表和二叉树美团这套卷子里算法题占了大头。选择题和填空题里反复出现链表、二叉树、排序算法的时间复杂度比较编程题也有一道典型的链表操作题。很多人会觉得链表、二叉树工作里根本用不上但笔试为什么要狂考因为这类题目能在最短时间内检验出一个人是否理解内存模型、指针/引用、递归和边界条件。链表题尤其适合现场手写因为它代码量不大却能逼你把每个指针的指向理清楚。一个候选人如果把链表反转都能写出死循环那基本可以判断他的工程代码里也会有相似的边界隐患。反过来能把链表题写得干净利落的人通常对“空指针”“头节点”“尾节点”这些细节有天然敏感这种敏感在真实开发里非常重要。2.2 一道经典链表题的完整推导反转链表假设试卷上出现了“反转一个单链表”这道题这是那个年代笔试的标配今天也依然高频。要求现场写出迭代和递归两种实现。我先说迭代实现思路就是三个指针prev、current、nextTemp。每次循环把当前节点的 next 指向前一个节点然后整体向后移动。需要注意的就是初始 prev 必须为 null否则反转后的链表尾部会指向一个未知地址这是一个极其经典的错误点。用 Java 写出来大概是public ListNode reverseList(ListNode head) { ListNode prev null; ListNode curr head; while (curr ! null) { ListNode nextTemp curr.next; curr.next prev; prev curr; curr nextTemp; } return prev; }时间复杂度 O(n)空间复杂度 O(1)。面试官如果追问递归版本核心是先递归到最后一个节点然后从后往前改 next 指针。好多人在这一步犯迷糊写出来发现 return 的节点不对。递归的返回值应该是“新的头节点”也就是原链表的尾节点。如果你在递归过程中丢失了这个返回值整个反转就断了。我觉得这题最值得练的不是能不能写对而是能不能用口头描述把每一步指针变化讲清楚因为在笔试现场有时候面试官会要求你在代码旁边写出思考过程。2.3 二叉树遍历与递归陷阱二叉树在笔试里出现频率也非常高。美团当时的卷子里选择题喜欢考“已知前序和中序求后序”这类题型编程题则可能要求“求二叉树最大深度”或者“层序遍历”。如果只写递归代码很简单public int maxDepth(TreeNode root) { if (root null) return 0; return Math.max(maxDepth(root.left), maxDepth(root.right)) 1; }但这道题有好多隐藏考点。第一递归终止条件必须写对root 为 null 时返回 0否则会无限递归第二如果树的深度极大递归方案会爆栈这时候就要考虑用栈模拟或者 BFS 层序遍历第三有些题目会要求层序遍历那本质上就是在用队列做广度优先搜索。我在帮新人准备笔试的时候一直强调二叉树是“递归思维”的试金石。你可以在真实项目里一辈子不写二叉树但通过二叉树能看出你懂不懂递归、懂不懂分治这是后端工程师解决复杂问题的基础能力。2.4 动态规划从暴力递归到状态转移2013年美团的试卷里已经开始出现动态规划内容了最常见的是最长公共子序列LCS和背包类问题。遇到这类题新手最容易犯的错是一上来就想写最优解结果卡死在状态定义上。我的建议永远是先用暴力递归思考再找重复子问题最后改成动态规划。拿最长公共子序列举例暴力递归就是把两个字符串从后往前比较。如果字符相等结果就是“两个子问题结果加一”如果不等就分别尝试跳过其中一个字符取最大值。这个思路用递归写出来很顺public int lcs(String s1, String s2) { return lcsHelper(s1, s2, s1.length() - 1, s2.length() - 1); } private int lcsHelper(String s1, String s2, int i, int j) { if (i 0 || j 0) return 0; if (s1.charAt(i) s2.charAt(j)) { return lcsHelper(s1, s2, i - 1, j - 1) 1; } else { return Math.max(lcsHelper(s1, s2, i - 1, j), lcsHelper(s1, s2, i, j - 1)); } }但这样会重复计算大量子问题所以笔试时要在递归基础上简化为二维 dp 数组。定义 dp[i][j] 为“s1 前 i 个字符和 s2 前 j 个字符的最长公共子序列长度”转移方程就是上面递归逻辑的直接翻译。这类真题即使放到现在依然是各厂笔试的常客。你想想电商、团购这种业务搜索、推荐、订单匹配背后都有这类算法思想美团出这种题完全是为了筛选能处理海量数据关联的人。3. 操作系统、网络与数据库后端研发的硬底座3.1 进程、线程与死锁不只是背概念操作系统相关题目在这份卷子里也有不小分量。选择题集中在进程和线程的区别、线程同步方式、死锁产生的条件。这些东西看起来是纯理论但美团作为一家重线下、重实时服务的公司后端系统要同时处理海量用户请求进程模型、线程池调度、资源竞争这些问题几乎每天都会遇到。死锁这块我记得有个很经典的简答题请说明死锁产生的四个必要条件并解释如何避免。四个条件分别的互斥、持有并等待、非剥夺、循环等待。备考时我建议不要死记硬背试着用生活场景理解。比如两个人面对面过独木桥A拿了一根棍子挡在桥中间B也拿了一根棍子挡着谁也不让谁先走这就是“持有并等待”加“循环等待”。解决的办法可以是“谁先放下棍子再等”或者“规定只能单方向通过”。理解了场景笔试里遇到变种题才能举一反三。3.2 TCP三次握手与四次挥手网络题怎么答才能得高分美团2013年的网络题基本是老三样TCP为什么是三次握手而不是两次、四次挥手为什么需要 TIME_WAIT、HTTP 和 TCP 的关系。如果只是把背好的答案默写出来能拿基础分但要拿高分需要补一层“为什么”。三次握手的本质是让双方确认彼此的收发能力都正常。第一次客户端发 SYN服务端知道客户端发送能力正常第二次服务端回 SYNACK客户端确认自己的发送、接收和服务端的发送、接收都正常第三次客户端再回 ACK是为了让服务端确认客户端的接收能力正常。如果只有两次握手服务端无法确认自己发出的 SYN 被客户端收到了就可能出现已经失效的连接请求突然传给服务端产生资源浪费。答题的时候有个技巧要画出状态转移的过程把 CLOSED、SYN_SENT、ESTABLISHED 这些状态写清楚阅卷人一眼就知道你是真懂还是假装懂。还有要提到 SYN 攻击的基本原理——服务端在收到 SYN 后进入 SYN_RCVD 状态如果迟迟收不到 ACK会占用半连接队列资源。这个补充能让答案立刻显得有实战感。3.3 数据库索引与事务SQL场景题实战数据库题在当年美团笔试里一般会有一道 SQL 编写题和若干选择题。选择题喜欢问聚集索引和非聚集索引的区别、事务的 ACID 特性、脏读不可重复读幻读的区别。SQL 题则是给一个订单表/商家表让你写出某个查询语句。这种题我建议所有候选人去把常见的表连接彻底吃透。比如有张订单表 ordersorder_id, user_id, merchant_id, amount, create_time和商家表 merchantsmerchant_id, merchant_name, city。出题人经常会问统计每个城市的下单总金额输出城市名和总金额按总金额倒序。答案必然要涉及 JOIN 和 GROUP BYSELECT m.city, SUM(o.amount) AS total_amount FROM orders o JOIN merchants m ON o.merchant_id m.merchant_id GROUP BY m.city ORDER BY total_amount DESC;笔试里容易丢分的点在于没加别名导致可读性差、忘记考虑 NULL 值、JOIN 条件和 WHERE 条件位置搞混。我见过不少人把过滤条件写在 JOIN ON 里结果统计结果完全不对。要记住ON 是连接条件WHERE 是结果集过滤条件两者语义不同混用的后果非常隐蔽。3.4 场景简答题缓存穿透与缓存雪崩的朴素解法美团这套卷子里还有一种题现在看起来特别有前瞻性——给一个“高并发读多写少”的典型团购场景问你会怎么设计缓存策略。大概类似“热门商家信息被频繁访问数据库压力很大你会怎么优化”。这其实就是今天的缓存穿透、缓存雪崩、缓存一致性问题的雏形。我当时复习这类题习惯按照“是什么、为什么、怎么办”三层来答。缓存穿透是查了一个不存在的数据导致每次请求都打到数据库缓存雪崩是大面积 key 在同一时间失效流量直接打到数据库。解决办法分别是对空值也做缓存但设置短过期时间、用布隆过滤器挡一层雪崩则可以用不同的过期时间打散、加随机值、多级缓存。答这种题不是要你把一堆名词堆上去而是要展现出“在压力下分析系统瓶颈并给出分步优化方案”的思考过程这对所有后端工程师来说都是核心能力。4. 现场做题的节奏与答题策略4.1 120分钟怎么分配最合理我对这套卷子比较深的一个感受是题量不算少时间并不宽裕。如果按120分钟来算我的建议是选择题控制在35~40分钟填空题和简答题控制在20~25分钟编程题留足40分钟最后15~20分钟用来检查。很多人一上来就在算法题上死磕结果后面的操作系统、数据库题完全没时间做这是最亏的。做题顺序上我个人的习惯是“先快速扫一遍全卷把有把握的题先做掉再回头啃硬骨头”。因为笔试是有时间压力的考试不是开放性的技术讨论最大化得分才是目标。如果你发现自己卡在某道题超过十分钟立刻标记一下跳到下一题。很多人在考场上是“不甘心”结果一卡卡掉半小时后面明明会做的题也拿不到分。4.2 手写代码的规范性阅卷老师的真实感受2013年的笔试大概率是纸质手写代码这对书写规范的要求其实很高。一张卷子上如果字迹潦草、变量名全是 a、b、c算法思路再正确阅卷人也很难给你高分。这里分享几个当年我和同事改笔试卷时总结的加分习惯函数签名写清楚入参出参注释一下。变量名用有含义的单词比如 head、node、prev、next。边界条件处理放在代码最前面通常是 null 判断。写完代码后在旁边简单写几句思路万一代码有一点点问题思路分还能保住。递归函数要画清楚递归停止条件。后来我自己面人的时候也会下意识看候选人在白板上写代码是不是先写边界条件。这个习惯一旦养成对真实开发也有好处因为一份代码最容易出 bug 的地方往往就在边界。4.3 遇到不会的题怎样“抢”到步骤分笔试不可能每道题都会。遇到完全没思路的题最忌讳直接空白。我会采用“暴力解 复杂化分析”的策略。比如一道动态规划题没想出来先写一个暴力递归或者全排列的解法让阅卷人看到你的思路是能跑通小数据量场景的然后补上一句“这样的时间复杂度是 O(2^n)但在数据量小的时候可以 work数据量大时可以用 dp 优化”至少能拿一部分思路分。还有一招就是利用题目给出的示例数据手跑一遍你的算法把中间结果写在旁边。很多阅卷人看卷子看多了会产生一种“这个人是逻辑清晰只是没想出最优解”的印象分数自然比纯空白要高。我见过不少人靠着“暴力解 复杂度分析”硬生生把编程题从0分拉到了5分甚至8分满分10分这在竞争激烈的岗位筛选中就是天壤之别。4.4 笔试中常见的隐形扣分点有些扣分点考生自己往往完全意识不到。我复盘过大量同学的表现总结了几个高频“隐形坑”题目要求“写时间复杂度”你只写了代码忘记标注复杂度。选择题里把“不属于”看成“属于”丢分丢得非常冤。SQL 题没有考虑去重出现了重复统计。手写代码时用了“伪代码”来糊弄比如写了个sort(arr)就当排序实现了这会被扣得很惨。简答题只答要点不展开少了“为什么”的部分导致阅卷人觉得你只是背了结论。要避开这些坑做题时一定要养成“看题两遍再下笔”的习惯。第一遍圈出题目的关键词比如“错误/正确”“不属于/属于”“最优/可行”第二遍判断题目真正想要的是什么。这个习惯在真实工作中也同样重要需求评审时漏看一个限定词可能导致整个方案返工。5. 从笔试卷看美团的技术文化与工程师素质模型5.1 题目背后隐藏的能力模型看一套笔试卷不能只看题目还要看命题人想选什么人。美团2013年这套卷子虽然难度不像今天那么卷但它非常清晰地体现出了三个能力偏好。第一是基础要扎实。数据结构和操作系统、网络、数据库都是大学核心课程没有太多偏题怪题考的是“你大学四年有没有真学”。第二是边界意识要强。链表题、二叉树题、SQL 题都在不断考察你在极端条件空表、空指针、递归终止下的反应。第三是工程思维要在线。开放题结合业务场景说明他们希望工程师不是一个纯粹的“刷题机器”而是能理解技术服务于商业。这三个能力模型放在今天依然是研发工程师的核心竞争力。5.2 对今天准备校招研发岗的启示很多人觉得十年前的笔试已经过时了我不这么看。现在的互联网公司笔试确实加了很多新东西比如线程池源码、JVM 调优、Redis 底层结构、分布式事务但基础部分依然是被反复考察的。我在带新人的时候如果发现一个人连 TCP 挥手为什么要 TIME_WAIT 都说不清楚那就算他框架用得很熟练我也不敢把核心服务交给他。因为“知道怎么做”和“知道为什么这样做”是两种完全不同的能力基础功底决定了你在系统出问题时的排查边界。所以如果你现在准备校招我的建议是不要把全部精力都放在刷“面经”和“高频题”上而是把计算机网络、操作系统、数据库原理这三本经典书认真过一遍。美团2013年这套卷子提醒我们技术在变但核心知识没有变。今天你在生产环境里遇到诡异的网络问题、性能瓶颈真正帮你解决问题的往往还是底层基础。5.3 关于“真题”的正确打开方式现在网上能搜到很多“美团2013研发工程师笔试卷回忆版”之类的内容但我不建议你到处找“标准答案”来背。最好的用法是把卷子里涉及的知识点摘出来盖住题目自己尝试出题考自己。比如看到卷子里考了“反转链表”你就接着练习“K个一组反转链表”“环形链表判断”“合并K个有序链表”把一个点练成一片。我自己在复习时有个习惯每做一套真题就把错题对应到书里的章节在旁边写上“这个题其实在考 XX 章节的 XX 概念”。笔试结束之后再根据这些标记回到课本去把薄弱环节补起来。以十年的视角回头看真正让我在职业生涯里受益的不是那一次笔试的通过而是这套“通过真题校准知识体系”的学习方法。这套卷子里的每一道题都是一个起点而不是终点。6. 一些个人体会这段历史教会我的事美团2013年的这套笔试题目对我个人而言最有意思的地方在于它让我第一次意识到“大厂笔试不是高考的延续而是一次工程师思维体检”。它考的很多内容并不复杂甚至有些题目我现在看会觉得有点基础但它就是能精准地筛掉那些只会背知识点而不会落地的候选人。那时候的研发工程师岗位其实已经在盼望那种“能自己定位问题、能理解业务需求、能把代码写干净”的年轻人了。这也影响了我后来写代码、带新人的方式。我面试别人时经常会拿出类似的反转链表、SQL 统计这类“基础题”来摸底。很多人觉得我是不是在故意刁难其实不是我只是想知道他有没有建立计算机科学最基本的模型。如果连最简单的边界条件都能漏掉我怎么能放心让他去处理线上每天几千万的请求。基础思维这东西真的是用时方恨少好在任何时候开始补都不晚。如果你打算去互联网公司做技术不妨自己找一份这种老试卷掐着时间做一遍再对照知识点体系去补课。你会发现这些题目不是用来为难你的而是给你画了一张“工程师必备知识地图”。做题的过程才是这张地图真正开始发挥作用的时候。