复盘2017腾讯校招笔试题：考点、陷阱与底层能力解析
“回望2017年腾讯校招开发工程师笔试试卷，很多考点至今仍是面试题库里的常客。如果你正在准备大厂研发岗，或者想看看当年那道经典笔试题到底在考什么底层能力，这份复盘值得认真看完。我也会结合那几年腾讯面试的技术侧重点，把每类题背后的考察意图拆开讲透。”
1. 整套试卷的布局思路：拿到手先看它想考什么
2017年的腾讯校招笔试试卷，和现在很多大厂的在线笔试相比，题量不算特别大，但覆盖范围非常典型。当时我在秋招季刷这套题的时候，第一感受是：它不像在考“你背了多少知识点”，更像在考“你有没有真正写过代码、调过bug、理解过系统运行的本质”。后面我陆陆续续面了几家头部互联网公司，发现这套卷子的考点分布，基本能代表那个时代大厂对开发工程师的核心能力预期。
整套试卷从模块上大致可以分成四块：语言基础与内存管理、数据结构与算法、计算机网络与操作系统、开放型设计与逻辑推理。其中算法题的占比最高，大概在四成左右，剩下的六成分布在另外三个模块里。这个比例放到今天依然没有过时，因为算法能力是最容易标准化筛选的环节，而语言基础和系统知识，则能快速判断一个候选人是不是“只刷过题、没写过工程”。
我当时拿到试卷后的第一个动作，不是从头开始做，而是先把每道题扫了一遍，把题目按“确定能拿分”“需要推演一下”“完全没思路”分成三组。这套策略在笔试中非常重要，因为校招笔试的时间通常比较紧张，先把送分题稳稳拿下，再花时间啃难题，比按顺序死磕要划算得多。这套试卷里也确实有几道题是典型的“送分题陷阱”，看起来简单，但坑埋得很深。
我当时拿到试卷后的第一个动作，不是从头开始做，而是先把每道题扫了一遍，把题目按“确定能拿分”“需要推演一下”“完全没思路”分成三组。这套策略在笔试中非常重要，因为校招笔试的时间通常比较紧张，先把送分题稳稳拿下，再花时间啃难题，比按顺序死磕要划算得多。这套试卷里也确实有几道题是典型的“送分题陷阱”，看起来简单，但坑埋得很深。
当年腾讯笔试的出题风格，普遍偏“工程化”。什么意思呢？就是很多题目不会直接问“TCP三次握手是哪三次”，而是给你一个具体的网络异常场景，让你反推问题出在哪一层。这种出题思路，其实在筛选那些真正理解技术原理背后因果关系的人。后面我也会把这类“化知识点为场景”的题目单独拿出来讲，因为这是整套试卷最有含金量的部分。
1.1 为什么2017年的题到现在还有参考价值
很多人会问，都过去这么多年了，技术栈早就变了，做这套老题还有意义吗？我的看法是：语言和框架会过时，但底层原理和思维方式的考察，几乎不会变。2017年考的仍然是：你对内存布局的理解、你对并发竞争条件的敏感度、你能否在O(n)时间内设计出正确的算法、你能不能把一个开放问题拆解成可落地的系统模块。
尤其值得注意的是，2017年前后正好是移动互联网进入深水区、云计算和大数据开始大规模落地的节点。腾讯在那一年特别看重候选人对“高并发”“海量数据”“分布式一致性”这些概念的直觉。这套试卷里虽然没有直接让写分布式系统，但很多题目的背景设定都隐隐指向这些方向。比如有一道设计题，核心场景就是典型的读多写少、缓存穿透问题，这不就是后来Redis缓存、CDN架构的雏形吗。所以，这套题表面上是在考校招基础知识，实际上是在为“能不能上手做真业务”做预筛选。
1.2 从考点权重反推腾讯当时的技术偏好
通过分析这套试卷的题型分布，可以反推出不少腾讯当时技术团队的能力偏好。算法与数据结构占了大头，这是所有大厂通用的筛选逻辑，不用多说。但值得注意的是语言基础上，C++相关的题目明显多于Java，这和腾讯当时大量后台服务基于C++自研框架有关。如果你当年是主攻Java的候选人，做这套卷子可能会觉得有些吃亏。
另外，试卷里关于Linux操作系统和网络编程的题也不少，这就更贴合腾讯的实际业务了。无论是QQ的通信模块、游戏的网关服务，还是后来微信的消息推送，底层都离不开网络协议栈和操作系统的IO模型。笔试中出现select、epoll、socket缓冲区这类考点，本质是在提醒你：写业务代码之前，先得搞清楚数据是怎么从网线到达你的进程的。这套逻辑放到今天做云原生、做音视频传输，依然完全成立。
2. 语言基础题里的陷阱：不是考你背语法，是考你踩坑直觉
语言基础是这套试卷里最容易丢分也最容易被低估的模块。乍一看，题目好像都在问“下面这段代码输出什么”“这个关键字的作用是什么”，但真正动笔写的时候，很多人会发现自己在细节上漏洞百出。这一部分，我主要结合C++相关的几类典型题目来说，因为试卷里C++的比重确实最高。
2.1 指针、引用与内存管理的连环坑
试卷里有一道让我印象很深的题，大概意思是给出一段涉及指针作为函数参数传递的代码，让你判断最终输出的值是什么。表面上看，这道题考的是“指针传递和值传递的区别”，但实际上一深挖，它同时涉及了栈上变量的生命周期、函数调用时参数的求值顺序、以及编译器可能做的优化。很多读者可能会觉得，我平时写代码用共享指针、用现代C++特性，这种老掉牙的指针题没什么用。但恰恰是这些底层机制，决定了你在排查线上内存泄漏时，能不能从一堆堆栈信息里快速定位到问题根源。
我在实际答疑的时候发现，很多人对“指针本身也是变量”这个概念理解得不够透。指针变量也是存放在栈上的，它也有自己的地址，它指向的对象才是真正在堆上或者在其他作用域里的。把指针传给函数的时候，复制的是指针变量本身的值，也就是那个地址编号，而不是地址指向的对象。一旦你在函数里修改了指针变量本身（比如让它指向别的地方），外层是感知不到的，除非你传的是指向指针的指针，或者引用。
还有一个反复出现的坑是字符数组和字符串常量。试卷里如果出了char* p = "hello"和char arr[] = "hello"的对比，很多人会忽略两者在内存区域上的本质区别。前者指向的是只读数据段，试图修改它是未定义行为，可能直接崩溃；后者是在栈上分配了一块可写的连续内存，内容是可以改的。这个知识点在校招笔试里出现的频率非常高，而且经常以“为什么程序运行到某一行就崩了”的形式出现。
2.2 虚函数、构造析构与多态的底层逻辑
C++题目中另一大类高频考点是虚函数机制。试卷里可能会出现这样的问题：基类构造函数里调用一个虚函数，实际执行的是基类版本还是派生类版本？答案很多人知道是基类版本，但能不能解释清楚原因，就另说了。原因是，在基类构造函数的执行期间，对象的动态类型还没有完全变成派生类，此时虚函数表指针指向的是基类的虚函数表，所以虚函数调用会被解析到基类实现。这个机制是C++标准明确规定的，目的是避免构造期间调用到尚未初始化的派生类成员。
和虚函数相关的另一个考点是析构函数为什么要声明为虚函数。试卷里往往会给出一个基类指针指向派生类对象，然后调用delete的场景，问内存是否泄漏。如果基类析构函数不是虚函数，delete基类指针时只会调用基类的析构函数，派生类中申请的资源就不会被释放，造成内存泄漏。这个例子在工程实践中太常见了，我自己写代码时也养成了一个习惯：只要类会被继承，就把析构函数声明为虚函数，或者干脆用std::shared_ptr管理生命周期。
除了虚函数，对象的拷贝与移动也是2017年前后很流行的考点。那会儿C++11的移动语义已经普及，腾讯的笔试题目里面也开始出现移动构造、右值引用相关的概念。这类题目考的不只是你会不会写语法，而是你在设计一个类的时候，能不能意识到“深拷贝可能带来性能瓶颈”，从而合理使用移动语义来避免不必要的资源复制。我在做这套题时，对移动语义的理解还比较浅，后来在实习中优化一个频繁构造临时对象的模块时，才真正体会到右值引用的价值。
2.3 Java方向的题目同样绕不开JVM和集合类
如果你当年投的是Java开发岗，那试卷里也会有一批Java方向的题目。Java部分的考点重心通常集中在JVM内存区域划分、垃圾回收算法、集合类的底层实现与线程安全性这几个方向。比如HashMap在多线程环境下为什么可能死循环，这个经典问题在当年的笔试和面试中被反复问起。它的根因是JDK 1.7及之前版本中，HashMap采用头插法处理哈希冲突，在并发扩容时可能形成环形链表。
不过也有一个容易被忽略的小点：Java题里往往喜欢考察equals和hashCode的契约关系。这个看似老掉牙的问题，每年的错误率都很高。很多人能背出“equals相等则hashCode必须相等，反过来不成立”，但给你一个实际类，让你重写这两个方法时，总会有人漏掉某些字段，或者写出一个返回值恒定的hashCode，导致HashMap在查找时退化成链表遍历。这类题目在笔试卷中不是最难的，但能非常有效地筛选出有没有真正读懂过集合类源码的人。
3. 数据结构和算法：笔试的主战场，也是拉开差距的地方
算法题在整套试卷里的地位，不需要我再强调。我想聊的是，2017年腾讯这套笔试试卷里的算法题，普遍呈现出一个特点：不追求偏题怪题，而是在经典题型的基础上增加一两层限制条件，考察你对复杂度的敏感度和对边界条件的把控能力。这种出题思路比直接甩一道冷门竞赛题要高明得多，因为它在有限时间内区分了“刷过题的人”和“真正理解算法本质的人”。
3.1 链表和树的题目：高频、易错、有固定套路
链表相关题目在笔试试卷中出现概率极高。我记得当时有一道“反转链表”的变体题，要求不是简单的单链表反转，而是在指定区间内反转。这个问题如果只写迭代法，需要对指针的拼接格外小心。我当时在做这道题时的策略是：先找到区间的前驱节点，然后对区间内的节点逐个进行头插，最后把前驱节点和区间后的节点接好。整个过程需要在草稿纸上画图辅助，写完后自己再拿几个边界case过一遍：区间是空链表、区间覆盖整个链表、区间只有一个节点。
另一个高频题型是二叉树。一套试卷里通常会出现两到三道树的题目。基础的有层序遍历、前中后序遍历的递归与非递归版本，进阶一点的会有最近公共祖先、二叉树转链表、根据遍历序列重建二叉树。我印象中有一道题就是给出二叉树的前序遍历和中序遍历序列，要求重建原树，这题本身不难，但它暗含了一个二叉树的重要性质——通过中序遍历序列配合前序（或后序）序列，可以唯一确定一棵二叉树，前提是树中节点的值都是唯一的。
做树相关题目时，我觉得最重要的习惯是：不要在脑子里模拟整个递归过程，而是把递归函数当成一个已经完成的黑盒，只关心它的输入和输出。比如“求二叉树最大深度”这个朴素问题，递归函数只需要知道“左子树的最大深度”和“右子树的最大深度”，当前节点的最大深度就是二者较大者加一。这种思维方式能帮你避开很多不必要的递归细节焦虑。
3.2 动态规划：2017年那套题里的几个经典模型
动态规划是校招算法题的绝对主力，腾讯这套卷子也不例外。我做完一遍之后，总结了一下动态规划的出题场景，基本集中在：背包问题及其变体、最长公共子序列/最长递增子序列、编辑距离、区间DP、以及状态压缩DP的前奏级题目。背包问题在那几年的笔试里特别常见，可能是因为它是一个特别好的“分水岭”题：能一眼看出它是背包变体的人，和要把题目改造成背包模型才能做出来的人，功力高下立判。
以一道比较有代表性的题为例：给定一个数组，求能否将数组分割成两个和相等的子集。这道题的朴素解法是回溯，但数据范围一大就会超时。正确思路是把它转化为0-1背包问题：是否存在一个子集的元素之和等于总和的一半。实现时用一维布尔数组，从后往前更新，避免同一个元素被重复使用。我在做这道题时，第一次没注意到“从后往前”这个细节，结果把0-1背包做成了完全背包，白白丢了一部分测试用例的分数。
动态规划题目最怕的不是找不到状态定义，而是找到了状态定义却推不出转移方程。我自己的经验是，遇到DP题先写暴力递归，再从递归函数的参数中提取状态，最后用记忆化搜索或递推来优化。这个思路虽然看起来多了一步，但实际效率往往是最高的，因为递归版本更容易通过小规模测试用例验证正确性。
3.3 字符串与模拟题：边界条件才是真正的考官
字符串处理题目在这套试卷中也占了不少分量。经典的有KMP字符串匹配、最长回文子串、字符串翻转、大数加法等。KMP这类题目在校招笔试中通常不会只让你背板子，而是会通过“求字符串中出现某模式串的次数”“求字符串的最短循环节”等形式来考察你是否真正理解next数组的构建过程。我当时把KMP的next数组推导过程反复在纸上画了几遍，才彻底弄明白了为什么失配之后要回溯到next[j]的位置。
模拟题则更考验对题意理解的准确性。2017年的笔试卷中有一道和日期计算相关的模拟题，题目本身逻辑不难，但涉及闰年判断、月份天数、跨年等多种边界条件，稍不注意就会出错。我当时的做法是，把月份天数存成数组，单独实现一个判断闰年的函数，然后把“计算两个日期之间相差多少天”拆分成多个小步骤。这种拆解思路，在应对复杂模拟题时非常管用，也符合工程中“模块化处理”的思维方式。
提示：模拟题最重要的是先读清楚输入数据的范围。如果数据范围很大，那大概率不能用暴力遍历所有日期；如果范围很小，那老老实实模拟即可。一上来就套高级数据结构，有时候反而会把自己绕晕。
4. 网络与操作系统：跨界题目最能看出基本功
这一部分是我觉得整套试卷里最有“腾讯特色”的地方。腾讯的业务形态决定了它对网络和操作系统的要求特别高，因此笔试试卷里也花了相当篇幅，来考察候选人对网络协议栈和OS底层机制的理解深度。这些题往往以场景分析为主，而不是直接背概念。
4.1 TCP三次握手与四次挥手：从“背流程”到“查问题”
2017年的试卷里关于TCP的题，没有直接问“三次握手的过程是什么”，而是给了一个场景：客户端连接服务器超时，已知客户端和服务端在同一内网，ping得通，问可能是哪一层出了问题。这道题背后想考察的，其实就是你对TCP连接建立过程中每一个环节的理解。比如SYN包是否发送成功、服务器是否有进程在监听端口、防火墙是否丢弃了SYN包、 backlog队列是否已满导致内核丢弃连接请求等等。
还有一个高频考点是四次挥手中的TIME_WAIT状态。试卷里可能会问，为什么主动关闭方要停留在TIME_WAIT状态，而不是直接进入CLOSED。答案是为了确保最后一次ACK能被对端收到，如果ACK丢失，对端会重发FIN，此时如果连接已经关闭，主动关闭方会回复RST而不是ACK，导致对端无法正常关闭。另外，TIME_WAIT状态还会持续2个最大报文段生存期（MSL），防止旧连接的延迟数据包干扰新连接。这个状态在线上高并发短连接场景中会积压大量TIME_WAIT连接，如何调优也是腾讯这样的大厂在面试中非常喜欢延伸出来的话题。
4.2 HTTP与DNS：业务开发每天都在碰的基础设施
在业务开发岗位的笔试中，HTTP相关题目几乎是必考的。2017年的试卷中出现了HTTP状态码的辨析、GET与POST的区别、Cookie与Session的关系等经典考点。这些内容看起来基础，但结合具体场景就很容易出彩。比如问：用户在浏览器中登录后，刷新页面为什么不需要重新登录？这个问题牵扯到Session的存储位置、Cookie中sessionId的传递机制、以及服务端session的过期策略。能把这个问题讲清楚的人，说明他对Web开发的基础链路是有完整认知的。
DNS解析也是那几年经常出现的考点。比如一个浏览器输入网址后，到发出HTTP请求之间，发生了什么？整个链条包括：浏览器缓存、操作系统缓存、本地hosts文件、本地DNS服务器、根DNS服务器、顶级域服务器、权威DNS服务器，每一层都有对应的缓存策略和TTL。我记得当时试卷里有一道题，问的是“为什么修改了DNS解析记录之后，部分地区用户要过很久才能访问到新地址”，这道题其实就是在考DNS缓存和TTL的概念。
4.3 进程、线程、协程与并发控制
操作系统部分的考题集中在进程与线程模型、死锁产生的四个必要条件、进程调度算法、虚拟内存与页面置换算法这几个方面。2017年的试卷里有一道关于“生产者-消费者问题”的题，要求用信号量完成同步。这题本身不难，但需要你能准确写出两个信号量的P/V操作顺序，理解为什么先P(empty)再P(mutex)的顺序不能随意调换。
还有一个和并发相关的经典陷阱题：多线程同时对一个int变量执行自增操作，最终结果是否一定等于线程数？答案是不一定。因为自增操作不是原子的，它包含了读取、修改、写入三个步骤，两个线程可能同时读到了相同的旧值，然后分别写回，导致只增加了一次。这道题在试卷中的变体很多，有的会改成用volatile修饰能否解决，有的会改成AtomicInteger是否保证线程安全。这些题目背后真正想考察的，是你对“原子性、可见性、有序性”这三个并发核心概念的理解。
5. 逻辑推理与开放设计题：你写的不是答案，是思路
很多候选人看到开放设计题就发怵，觉得没有标准答案，不知道写什么。其实这种题恰恰是最容易拿分也最容易丢分的地方。拿分容易是因为你只要给出一个结构化的、考虑过边界情况的方案，就能获得基础分；丢分容易是因为一旦你只写零散的点，或者只写结论不写理由，评卷人根本不知道你的思维过程是什么。2017年腾讯这套试卷里的开放题，典型的有“设计一个短链接系统”和“设计一个抢红包系统”。
5.1 短链接系统设计：看似简单，实则五脏俱全
短链接系统是校招设计题中的常青树。它的核心诉求很简单：把一个长URL转换成一个短URL，并且通过短URL能够跳转回原始长URL。这道题真正想考察的，是你能不能把“跳转”这个动作扩展成一个完整的读写链路。
基本的数据存储方案，是维护一张映射表，存短码和长URL的对应关系。短码的生成方式有很多种，我当时的思路是：用自增ID做基数62编码（包含大小写字母和数字），这样能够生成6位左右的短码。ID自增策略可以保证短码唯一，而62进制编码比十进制要更紧凑，7位就能表示数十亿条记录，足够日常业务使用。问题在于，这个方案需要保证ID生成的并发安全，可以借助数据库的自增主键、分布式ID生成器（如雪花算法）来实现。
除了短码生成，这道题还要考虑重定向方式。使用301还是302？301是永久重定向，搜索引擎会缓存这个跳转结果；302是临时重定向，每次都会重新请求短链接服务。如果链接会被修改，那么使用302更合适。这一细节非常能体现候选人的业务敏感度，很多人会忽略重定向状态码对缓存行为的影响。
再往下延伸，还有高频访问的缓存设计、短码过期和清理策略、数据分库分表方案、甚至恶意链接的检测风控。你不需要把这些全部写到试卷上，但能写出两到三个层次，并说明取舍理由，就已经能在众多候选人中脱颖而出了。我当时在试卷里重点写了缓存设计，因为我在项目中碰过类似问题，知道缓存穿透和缓存雪崩对读服务的伤害有多大。
5.2 抢红包系统设计：海量并发下的经典考题
抢红包系统在这几年大厂面试中出现频率非常高，2017年腾讯笔试就已经在考了。核心难点并不在“如何拆红包金额”，而在“如何支撑海量用户同时抢一个红包时的并发控制与数据一致性”。
抢红包首先涉及几个关键接口：发红包，生成一个红包记录并扣减余额；抢红包，从剩余金额中随机分配一笔并写入用户红包记录；查红包详情，返回剩余金额和领取列表。最容易出问题的就是“抢”这个动作。如果直接对数据库中的红包记录加行锁，在大量并发下会迅速打满数据库连接。更合理的方案是，把“抢”这个动作在内存中完成，比如使用Redis的原子操作来扣减剩余金额，写入领取记录时再异步落库。
金额拆分算法也值得深入思考。最简单的方案是“每次随机抢到剩余金额的一定比例”，但这样会导致前面的人抢到的金额普遍偏大。更公平的做法是“二倍均值法”：每次抢到的金额等于剩余金额除以剩余份数的两倍以内的随机值。这样能让每个人抢到的金额都在一个相对均匀的区间内，不会出现极端不公平的情况。腾讯那几年对这类算法的细节非常看重，因为抢红包业务一旦出现明显不公平，用户投诉量会非常大。
除了算法和并发，还要考虑数据一致性。用户抢到红包后，如果异步落库失败怎么办？我的思路是引入消息队列，抢红包成功只是标记了内存中扣减成功和用户领取记录写入，真正更新数据库红包表、资金流水表的操作通过MQ异步消费完成。这样既保证了用户体验，又能通过消息重试机制保障最终一致性。
5.3 如何用“说人话”的方式把思路写明白
开放设计题最忌讳的，是只堆名词不解释逻辑。写“用Redis缓存”“用MQ解耦”“分库分表”这几个词，谁都写得出，但如果不说明为什么要这样选、数据量级多大时需要这样做、出现异常时如何兜底，这几个词就没有任何区分度。
我个人的习惯是采用“总-分-总”的结构来回答开放题：先一句话说明整体方案，然后分存储、接口、并发控制、扩展性四个维度展开，最后总结一下这个方案的瓶颈在哪里，怎么进一步优化。这种做法可以让评卷人快速抓住你的思路脉络，也能向对方展示你不是在背模板，而是具备系统性的设计思维。
注意：开放设计题没有唯一标准答案，但有一条通用标准——你的方案必须能在给定的业务规模下自洽地运行。如果数据量只有一百万，却设计了一套复杂的分布式事务方案，这种“过度设计”反而会扣分。匹配业务规模的方案，才是最好的方案。
6. 回看这些题：2017年的考点，放在今天还成立吗
整套试卷做完一遍之后，我最深的感触不是“这些题好难”，而是“这些题反映的能力模型，到现在依然不过时”。从腾讯云、腾讯地图，到微搭、小程序开发，再到今天大模型应用开发、AI Agent开发，技术热点一直在变，但工程师的基本功要求，其实非常稳定。
6.1 底层原理知识在今天的技术栈里如何体现
以前笔试考的epoll、socket缓冲区、Reactor模型，放在今天的云原生和微服务架构里，变成了你要理解服务网格中sidecar代理的转发机制，理解负载均衡为什么能做到毫秒级故障摘除。以前考的HashMap哈希冲突与扩容，放在分布式缓存场景里，变成了哈希一致性算法和数据分片。以前考的TCP半连接队列溢出，放在今天大流量秒杀场景下，依然是网关调优必须关注的核心指标。
这几年很火的AI应用开发工程师、大模型全栈工程师这些新岗位，表面看好像和2024年、2025年的技术热点绑定得很紧，但剥开来看，底层依然是代码能力、数据结构和算法能力、以及对系统设计的基本认知。我最近接触了很多做LLM应用落地的团队，大家头疼的问题，往往不是Prompt写不好、模型选型不对，而是高并发请求下如何做缓存、如何限流、如何保证多个下游依赖之间的稳定性。这些问题，本质上还是那套计算机网络、操作系统和架构设计的底层能力。
6.2 最近刷到的一些腾讯技术热词，和老考点有什么关联
我在整理这篇文章时，顺手看了下近期网上和腾讯技术相关的热搜词：腾讯地图、腾讯云上传、腾讯乐固、腾讯天御滑块、uniapp页面里H5地图定位报错、腾讯视频ckey算法等。这些词串起来，恰恰说明了技术栈的演进方向，但底层逻辑没变。
比如地图定位报错，典型的问题是坐标系不一致。不同地图服务商采用的坐标系可能不同，GCJ-02是国测局坐标，WGS-84是国际标准坐标，如果混用，定位点会偏移几十米到几百米。这类问题放到2017年的笔试里，其实就是“不同类型数据需要适配、转换”的一个具体案例。再比如腾讯天御滑块验证，核心是风控和反作弊，背后的算法和数据结构基础，和当年考的哈希、布隆过滤器、状态机设计有着千丝万缕的联系。
如果你现在正在准备腾讯或其他大厂的开发岗校招，我的建议是：不要只盯着最新的技术名词刷题，更要花时间把2017年这套试卷里体现的基本功打牢。LeetCode可以刷，但别只刷难题偏题，经典题型的边界条件和复杂度分析更重要。计算机网络和操作系统可以只看面经总结，但最好自己动手把三次握手、TCP状态迁移、虚拟内存页面置换在纸上画一遍。这样无论技术热点怎么变，你的技术底座都是稳的。
6.3 给准备校招的同学的一点经验
从这套2017年的笔试卷出发，结合我后来参加面试和带新人的经历，我觉得校招准备最应该重视三件事：一是要动手写，只看题解和自己写出来是完全不同的体验；二是要复盘错题，尤其是笔试中暴露出的知识点漏洞，往往是比刷十道新题更有价值的收获；三是要有体系地学习，把知识点连成网络，而不是零散记忆。比如学TCP，就顺便把HTTP、DNS、WebSocket一起串起来；学集合类，就把HashMap、ConcurrentHashMap、红黑树一起对比着看。
这套笔试的题目难度，放在今天来看并不算地狱级，但它考察的广度和深度，足以让一个基础扎实的同学和一个只会背题的同学被明显区分开。我当时做完这套题之后，最大的收获不是“我会做某道题了”，而是“我知道了接下来该往哪个方向查漏补缺”。这份认知上的提升，比分数本身要值钱得多。