前阵子整理旧资料的时候，翻出一套搜狐2016年的研发工程师笔试题。那段时间我在给团队做校招面试题参考，正好拿出来对比了一下现在的笔试题风格，发现挺有意思的：几年过去，题型包装变了不少，但底层要考的东西几乎没变。这套题在准备校招的技术圈子里一直是经典练习素材，原因其实很简单——搜狐的笔试题出得很规范，难度梯度比较合理，既能筛掉基础不牢的人，又不至于让思路正常的人完全无从下手。如果你正在准备研发岗位的笔试面试，或者已经工作几年想回头补一补基本功，这套题都值得当一面镜子。
很多人一听到“笔试题”三个字就头大，觉得无非是刷题背答案。但2016年这批题目有意思的地方在于，它不完全是算法题库式的题目，里面掺杂了不少操作系统、计算机网络和逻辑推理的东西。说白了，笔试不是在考你会不会某道题，而是在考你有没有形成一套完整的工程思维。下面我就按考察维度、典型题型、实战策略和避坑经验这几个方向，把这套题拆开聊聊。
1. 2016年搜狐笔试题的考察逻辑与能力模型
1.1 研发笔试到底想筛什么样的人
先说一个很多人搞错的前提：校招笔试不是用来招“算法竞赛选手”的，而是用来筛掉基础不扎实、思维混乱、动手能力差的候选人。2016年那会儿互联网公司普遍的做法是笔试筛一轮、技术面筛两三轮，笔试的定位是“海选门槛”，题目设计得既要保证区分度，又要控制整体难度，不然简历全进面试环节，负责面试的工程师就得累趴下。
从这套题的结构来看，考察维度大致分四块：数据结构和算法、操作系统基础、计算机网络基础、逻辑推理和智力题。这个结构在当年的校招笔试题里非常典型。数据结构和算法不用说，这是程序员的核心基本功；操作系统和网络考的其实是“你对计算机系统有没有整体认知”；逻辑智力题则是在考察你把一个陌生问题转化成计算模型的能力。这四块加在一起，正好对应了一个研发工程师日常工作中最常用的几种思维模式。
这里有个容易被忽略的点：笔试中的基础概念题，往往比算法题更能反映一个人的真实水平。算法题可以靠短期刷题突击，但进程和线程的区别、堆和栈的差异、TCP为什么需要三次握手这类问题，如果理解不到位，写出来的答案会显得很虚。面试官看笔试卷的时候，重点也是在找那些“会做题但不懂原理”和“懂原理但做题粗糙”之间的平衡点。
1.2 题型结构对备考方向的启示
我之前帮团队整理过几个校招季的笔试试卷，发现搜狐这套题在结构上有一个很典型的特点：客观题占了一部分比例，剩下的全是手写代码和简答。客观题考概念和细节，手写题考实现能力，简答题考表达和逻辑。这种结构其实是合理的，因为它避免了“只会背书”和“只会写码”这两种单腿走路的情况。
备考的时候，针对这种结构要做的事情也很清楚。概念题部分，把《深入理解计算机系统》里关于内存、进程、线程的章节吃透，再把TCP/IP协议栈的基本流程理清楚，基本就够了。手写代码的部分，常见数据结构的增删改查、排序查找、链表二叉树相关操作，必须能闭着眼睛写出来。简答题考的是你组织语言的能力，别写流水账，按“背景-思路-关键点”三段式来答，印象分能高不少。
我自己的体会是，如果你能在一份笔试卷里同时看到“基础概念”和“算法实现”占据几乎相同的比重，那这家公司要的就是“基础扎实的工程型选手”，而不是“只会刷题的竞赛型选手”。对号入座去准备就可以了。
2. 核心考点拆解：从高频考点到很容易丢分的地方
2.1 数据结构与算法：不只是刷题，要理解“为什么这么设计”
数据结构和算法在笔试里占了大头，这是肯定的。但2016年笔试题的风格和现在很多公司喜欢出偏题怪题不同，它更看重对经典内容的掌握程度。高频考点集中在几个方面：数组和链表的相关操作、栈和队列的应用、二叉树的各种遍历、排序算法的时间空间复杂度对比、二分查找的变种、动态规划入门。
举个例子，排序算法是每年必考的，但考法有讲究。聪明的考法是让你比较快排和归并排序在时间复杂度和空间复杂度上的差异，或者让你分析堆排序为什么不稳定。如果你只是背了“快排平均O(n log n)，最坏O(n^2)”这种结论，却说不清楚划分不均匀会导致退化，也没有自己动手实现过，那遇到变体题就很容易露馅。
链表相关的题目也是重灾区，尤其是单链表反转、判断链表是否有环、找链表中倒数第K个节点这类。这些题思路不难，但手写代码时很容易栽在指针操作上。笔试的时候没有IDE帮你调试，全凭脑子里模拟指针变化过程，这本身就是一种能力筛选。我的建议是，平时练习时不要只在IDE里写完就跑，要尝试用纸笔走一遍代码逻辑，特别是链表、二叉树这类指针操作比较多的题目，这个习惯在笔试现场会很占便宜。
还有个容易被忽视的点是复杂度分析。很多同学写得出代码，但问时间复杂度就含糊。2016年的笔试题里很多算法题会要求你写出算法的时间复杂度，如果你只写代码不分析复杂度，会扣分。这背后其实是一个很实际的要求：工程师不仅要写出能跑的代码，还要能预估代码能不能撑住线上流量。所以备考的时候每做完一道题，顺手写一下时间复杂度和空间复杂度，养成这个习惯，面试时你会感谢自己。
2.2 操作系统：进程、线程、内存，这些概念为什么反复考
操作系统这块是很多人备考时容易忽略的部分，觉得“跟算法没关系”，但实际笔试里出现频率极高。搜狐这套题里涉及到进程和线程的区别、死锁产生的四个必要条件、堆和栈的区别、虚拟内存和页面置换、进程间通信方式等等。这些内容听起来很“八股”，但你细想就会发现，它们和日常开发是直接相关的。
举几个实际的场景：排查线上服务响应变慢时，如果不懂线程上下文切换的开销，你就很难解释为什么线程数翻倍后性能反而下降；做缓存淘汰时，如果不理解LRU和LFU各自的适用场景，就选不对方案；处理内存泄漏时，如果不理解栈上分配和堆上分配的区别，连排查方向都可能找错。笔试考这些，本质上是在确认你有没有这些底层认知。
教科书式的答案好背，但想真正理解这些概念，我建议换个角度：不要问“什么是进程”，而是问“为什么操作系统要引入进程这个概念，为什么有了进程还要线程”。顺着这个思路想，你会发现进程是为了隔离资源，线程是为了共享资源、降低切换成本。理解了这层设计意图，面试官再追问“协程和线程有什么区别”时，你也能从容应对了，因为万变不离其宗，都是在回答“如何更好地利用CPU”这个问题。
2.3 计算机网络：从TCP三次握手看面试官想听什么
网络部分的考点非常集中，基本就是TCP/UDP、三次握手、四次挥手、HTTP协议这些。搜狐这套题里考了TCP三次握手的过程和为什么需要三次握手，这类问题几乎是所有公司笔试面试的标配。但很多人只背了“SYN、SYN+ACK、ACK”这三步，却解释不了为什么是三次而不是两次。
这里分享一个我当时觉得挺好用的理解方式：三次握手的核心目的是让双方都确认自己和对方的收发能力都是正常的。第一次握手，客户端发出SYN，服务端收到了，服务端知道自己接收没问题、客户端发送没问题；第二次握手，服务端回SYN+ACK，客户端收到后，知道自己发送没问题、接收没问题，也确认服务端发送没问题、接收没问题；第三次握手，客户端回ACK，服务端收到后，确认客户端接收没问题、自己发送没问题。到这里，双方才都确认了彼此的收发能力正常。如果只有两次握手，服务端无法确认客户端的接收能力是否正常，也没法处理自己发出的SYN超时重传可能带来的资源浪费问题。
这样去理解三次握手，笔试简答时就不会答得干巴巴了。把设计意图讲清楚，比列出三个步骤要加分得多。类似的还有四次挥手为什么客户端要等待TIME_WAIT，这些设计背后的道理才是面试官真正想听的。
关于网络部分，我还有个具体建议：最好能自己动手抓一次包，用Wireshark或者tcpdump看看TCP三次握手和四次挥手的实际过程。纸上得来终觉浅，真实看到SYN、ACK的报文交互，比你背十遍状态转移图都管用。而且面试时如果你能说“我实际抓包验证过”，这个细节会让面试官眼前一亮。
2.4 逻辑与智力题：考的是建模能力，不是脑筋急转弯
2016年的笔试题目里还有一类让很多人头疼的题：逻辑推理和智力题。比如经典的25匹马找最快的3匹、在天平上找异常球、倒水问题等等。很多同学一看到这种题就觉得是脑筋急转弯，其实不然。这些题考察的是建模能力——把一个具体问题抽象成可以用算法或数学工具解决的形式。
以“25匹马5个赛道找出最快3匹，最少需要几次比赛”这道题为例，多数人第一次做都会答错。这题的正确思路是先分成5组比5次，每组排出名次；然后每组第一名再比一次，假设这场比赛结果出来后，就可以排除掉大量不可能进入前三的马。这个过程中，真正有价值的不是答案本身，而是你推理时能不能把信息量用足。面试官其实想看你面对一个开放式问题时，怎么分析、怎么假设、怎么把问题规模降下来。
我的建议是，笔试前可以适当做几道经典的逻辑推理题练练手，但不需要花太多时间，因为这类题通常占比不大。如果考试时遇到，先冷静画个图或者列个表，把条件理清楚，通常不会完全没思路。反而是那些一看不会就放弃的同学，丢分会比较可惜。哪怕最后没推出完整答案，把分析过程写出来，批卷人也会认为你有基本的逻辑素养。
3. 经典题型的解题思路与代码实现
3.1 手写二分查找：边界条件才是真正的考点
二分查找是笔试中的“钉子户”，几乎年年考。这题看着简单，但能一次写对的人不多，因为边界条件太容易错了。我记得当年刷题时统计过，第一次手写二分查找能完全通过边界测试的同学，比例不到一半。
先看一个最常见的写法：
def binary_search(nums, target): left, right = 0, len(nums) - 1 while left <= right: mid = left + (right - left) // 2 if nums[mid] == target: return mid elif nums[mid] < target: left = mid + 1 else: right = mid - 1 return -1这个写法里有两个关键点容易被忽略。第一，mid = left + (right - left) // 2而不是(left + right) // 2，前者可以防止left和right都很大时相加溢出，这个细节笔试时很多人想不到。第二，while left <= right这个条件的边界：当left和right相等时，mid会指向同一个位置，此时还需要判断一次，因为有可能目标值正好在这个位置。如果写成left < right，循环会提前退出，漏掉这个判断。
还有一种比较难一点的变体：找左边界或者右边界，比如找升序数组中第一个大于等于target的位置。这种题更考验对不变量的理解，写的时候建议配合一个具体数组在纸上走一遍，效果比空想好很多。面试时如果让你写二分查找，多半会跟着追问一个变体题，平时把这些变体练熟了，当场就不用慌。
3.2 单链表反转：递归和迭代的两种思维
链表的题也是笔试常客，尤其是单链表反转。这题考察的不只是你会不会写，还在考察你对指针和引用操作的敏感度。这里给出迭代和递归两种实现，代码不长，但背后是两种不同的思维方式。
class ListNode: def __init__(self, val=0, next=None): self.val = val self.next = next def reverse_list_iterative(head): prev = None curr = head while curr: next_node = curr.next curr.next = prev prev = curr curr = next_node return prev def reverse_list_recursive(head): if not head or not head.next: return head new_head = reverse_list_recursive(head.next) head.next.next = head head.next = None return new_head迭代版的核心逻辑是保存下一个节点，再翻转当前节点的指针。这里最容易犯的错是：翻转了curr.next之后，后面节点就找不到了，所以必须在翻转之前把next_node保存下来。这种错误在笔试现场特别常见，因为脑子里容易把“当前指针”和“下一个节点”混淆。
递归版的写法非常简洁，但理解门槛更高。它的核心逻辑是：递归函数每次接收一个head，如果head是最后一个节点就直接返回，否则先把后部分链表反转好，再让head.next.next指向head，也就是把当前节点接到新链表末尾。这个“反转后串回去”的过程，建议画图理解。笔试题里如果时间紧张，写迭代版更稳妥，递归版虽然优雅，但call stack太深时会有栈溢出风险，这也是面试官可能追问的点。
3.3 动态规划：从暴力递归到状态转移
动态规划是很多人笔试时的噩梦。2016年的题目里也有经典的动态规划题，基本套路是先给你一个可以用递归暴力求解的问题，然后追问如何优化。以“最长公共子序列”为例，很多同学能写出递归版本，但一说到动态规划就卡住了。
def lcs(s1, s2): m, n = len(s1), len(s2) dp = [[0] * (n + 1) for _ in range(m + 1)] for i in range(1, m + 1): for j in range(1, n + 1): if s1[i - 1] == s2[j - 1]: dp[i][j] = dp[i - 1][j - 1] + 1 else: dp[i][j] = max(dp[i - 1][j], dp[i][j - 1]) return dp[m][n]这里最关键的是理解dp[i][j]的含义：它表示s1的前 i 个字符和s2的前 j 个字符的最长公共子序列长度。理解了状态定义，状态转移方程就顺理成章了：如果当前字符相等，就在之前的基础上加1；如果不相等，就取两种“少一个字符”情况下的最大值。很多同学把动态规划写错，不是不会转移方程，而是状态定义没想清楚就开始填表了，这是大忌。
笔试遇到动态规划题，我的建议是先用文字写出状态定义和转移方程，再对照着写代码。别一上来就疯狂敲代码，先把思路理清楚，哪怕最后代码没写全，思路对了也能拿不少步骤分。搜索记忆化、动态规划、滚动数组优化这些进阶技巧，如果学有余力也应该掌握，笔试中偶尔会有压轴题用到。
3.4 手写代码时的规范与鲁棒性
除了算法本身的正确性，笔试阅卷时还有一个隐形评分点：代码规范性和鲁棒性。我老东家技术团队在评笔试时，就遇到过很多“逻辑对了但代码一塌糊涂”的情况。变量名命名不一致、缩进混乱、没有考虑空输入或者数组越界的情况，这些都会影响批卷人的印象分。
举几个具体的例子。第一个是函数入口处要判断空指针，链表题里尤其重要，很多同学写反转链表时没考虑输入是空链表的情况，直接访问head.next就崩了。第二个是变量名要能见名知意，不要写p1、p2、t1这种让人猜的命名。第三个是代码缩进和括号对齐要清楚，手写代码没有IDE帮你格式化，自己一定要注意可读性。
我见过不少同学笔试通过率很高，但代码风格一直被面试官吐槽，后来才意识到这个问题的严重性。实际上，笔试代码的规范性加在一起可能有5到10分的差距，在竞争激烈的校招中，这几分可能决定能不能进入面试环节。所以备考时就要养成好习惯，每次写题都当成面试现场来写，该判空的判空，该写注释的地方写注释，别想着“笔试而已，没人看细节”。
4. 现场笔试的答题策略与节奏控制
4.1 时间分配：先拿保底分，再冲难题
笔试的时间通常比较紧张，搜狐这类公司一般会给60到120分钟，要完成选择题、简答题和编程题，时间并不宽裕。很多同学容易陷入“死磕一道题”的陷阱，花40分钟做一道20分的题，导致后面30分的题完全没时间看，这是非常亏的。
我自己的策略是“两步走”：进考场先花3到5分钟快速浏览全卷，给每道题标注一个大致的难度和分值；然后先把有把握、分值高的题做掉，主要目标是确保拿到80%的保底分，把选择题、简单代码题稳定拿住，再来啃动态规划或智力题这类有难度的。如果前面有题卡住超过10分钟，果断先标记出来，去做后面的题，最后有时间再回来补。
这个策略听起来简单，但实际操作中很多人做不到，因为心理上不愿意放弃一道已经投入了时间的题。这里有个比较实用的心理暗示：你来笔试的目标是“总分过线”，不是“每道题都做对”，只要保证过线就行，战略性放弃某道难题是完全正常的。尤其是那种分值不高但特别耗时的智力题，放在最后做更合适。
4.2 不会做也要留下思考痕迹
笔试和面试一样，面试官希望看到你的思考过程而不仅仅是结果。这道题你会做，满分；不会做，也别空着，把能想到的思路写出来。哪怕是“我想到可以用递归，但边界条件还没理清”这种程度的过程，也比白卷强得多。批卷人在看卷的时候，其实是在寻找“这个候选人有没有培养潜力”，而“思考痕迹”是判断潜力的重要依据。
举个例子，动态规划题如果不会写转移方程，你可以先写出暴力递归版本，再写一句“这里有重复计算，可以用一个二维数组记录中间结果来优化”。这个过程本身已经展示了你对动态规划思想的理解，至少能拿一半的分数。类似的，智力题如果推不出来最终答案，把你画的状态推演表留在卷面上，阅卷人也会认为你具备一定的分析能力。
还有一点需要注意：程序题的答题区域，不要在没想清楚的情况下就涂涂改改。可以用草稿纸先理一遍思路，再往答题区誊写。有些线上笔试系统不提供草稿纸，那你就在代码注释里写思路，写完思路再写代码，这样阅卷人看到注释就知道你不是在瞎编。
4.3 环境和工具准备的细节
2016年那会儿的线上笔试系统体验参差不齐，有些支持代码高亮和自动补全，有些就是一个纯文本框，连缩进都要手动敲。现在虽然好了一些，但依然存在各种变量。所以笔试前一定要提前熟悉考试平台的操作，不然到了考场上连“怎么提交代码”都要找半天，心态就容易崩。
如果是线上笔试，提前做这几件事：准备一个稳定的网络环境，调试好浏览器和编辑器；本地装好可以离线运行的编程环境，比如Python或者Java环境；准备一张草稿纸和两支笔，用来推演链表和二叉树的结构变化；如果允许，把常用的代码模板准备好，比如二分查找、链表反转、快排这些高频代码，提前在本地编辑器中存好，进场后可以快速调用思路。
不同公司的笔试还有些小差异，有的要求全程开摄像头，有的要求共享屏幕，这些都要提前看到通知然后做好准备。我当时有一次笔试就是没提前测试摄像头，开考后折腾了10分钟才搞定，白白浪费了宝贵的答题时间。这些细节虽然不起眼，但确实能影响发挥。
5. 备考中的典型误区与避坑心得
5.1 只见题海，不见原理
备考笔试时，很多同学会陷入“刷了500道题就稳了”的误区。但真实情况是，如果只刷题不总结，同类型的题换了个问法照样不会。我见过太多同学刷了几百道LeetCode，但让他手写一个二分查找，依然会在边界条件上犹豫半天。原因就是刷题时只看了题解，没有真正理解那道题背后的“为什么”。
备考比较有效的做法是“按专题刷题+总结套路”。比如花两周专门刷链表题，刷完每个题目都问自己三个问题：这道题的核心思路是什么？用了什么技巧？如果换一种数据结构，比如改成数组，解法会有什么变化？这样总结下来，你会形成一套自己的“解题工具箱”，而不是一个零散的题单。数据结构永远是那几种，算法思想也永远逃不开那些招数，抓住本质远比刷题数量重要。
5.2 只看不写，考场手生
另外一个比较常见的坑是：看题解觉得自己都懂了，但一到了手写代码就写不流畅。这是因为“看懂代码”和“写出代码”是两种完全不同的能力。笔试场上没有IDE提示，没有自动补全，一切都是靠手敲，如果平时没有练习过手写代码，写的时候经常会出现语法错误、缩进错乱、循环边界想不清楚这些低级问题。
所以我建议，备考期间每天保持1到2小时的手写代码时间。可以用白板、用纸笔、用一个不带语法提示的纯文本编辑器，自己从零开始写，写完再对照标准答案看差距。坚持两到三周，手写代码的流畅度和准确度会有明显提升。这个过程虽然枯燥，但确实是最接近笔试现场的训练方式了。
5.3 忽视网络与操作系统的性价比
很多人备考时把所有精力都喂给了算法题，操作系统和计算机网络这两块却草草带过。我觉得这个策略不太划算。从投入产出比来看，网络和操作系统的基础题通常比较简单，只要把最核心的概念理解清楚，拿分反而比一道中高难度的算法题容易得多。算法题做得再多，遇到新题也可能卡壳，但基础概念题只要背熟原理，大概率都能答出来。
我当时给团队整理校招题目时看过一个统计数据：在笔试总分差不多的情况下，操作系统和网络部分得分高的人，更容易通过后面的面试。原因也不难理解，这两块能反映一个候选人对计算机系统是否有整体性了解，而面试官通常都会对这类候选人有更好的印象。所以备考时千万别轻视这些“八股文”，它们可能就是你和其他候选人拉开差距的地方。
6. 这套笔试题在后来的工作里给我留下的东西
6.1 基础扎实的人在真实工程里赢在哪里
说实话，很多笔试考点不会直接在工作里用到，不太可能每天写一遍链表反转或者手写快排。但准备笔试过程中建立的底层认知，会以另一种方式影响你的工作。比如你现在做接口开发，如果理解TCP的状态流转，调接口超时的时候就能猜到可能是哪一层出了问题，而不是只会无脑重试；你做性能优化，如果理解哈希表在数据量变大时会rehash，就能知道为什么有些操作在数据量上来后会突然变慢。
我刚工作那几年，接过线上服务频繁Full GC的问题，排查了很久找不出原因，后来突然想到是不是用了某些不合理的字符串拼接方式，导致产生大量中间垃圾对象。这个排查思路不是当时学的什么具体算法，而是对内存管理和对象生命周期这些基础概念有概念后自然而然形成的。所以别觉得笔试基础题和工作无关，它们是在帮你建立一套“底层直觉”，遇到问题的时候你会下意识往正确的方向想。
6.2 如何持续保持底层基本功不退化
基本功这种东西，学了之后不维护是很容易退化的。我在团队里招人时，经常遇到工作了三五年的人，基础概念反而比应届生还模糊。这不能全怪个人，毕竟工作内容很具体，平时很难接触到那些通用底层知识。但作为工程师，如果想要在技术路线上走得远一些，保持基本功的活跃度还是很有必要的。
我自己的做法是定期翻一翻经典书，或者找一套这类的经典笔试题来重做，题目本身做不做对无所谓，主要是借题来检查自己对哪些基础概念的理解还没有过时。每年我也会参加几场线上的编程赛事，或者在一些刷题平台上随机做一两道“每日一题”。这种低频但持续的训练，比突击式的学习更能维持状态。
另外，如果团队里有新人或者实习生，帮他们review笔试题、模拟面试也是很好的复习机会。教是最好的学，给新人讲清楚进程和线程的区别，表面上是帮别人，实际上你会被迫把自己的理解重新整理一遍，很多以前模糊的地方会在这个过程中被理清。这也是很多资深工程师推荐“费曼学习法”的原因——多输出、多讲、多复盘，基本功就不容易丢。
回到搜狐2016这套笔试题本身，我的最终建议是：别把它当成一次性的应试材料，看完就扔。花两三个小时认真做一遍，然后把做错的题梳理一下，看看错题背后对应的是哪块基础没有夯实，这才是这套题最大的价值。知识会更新，题目会过期，但扎实的底层能力和成体系的思考方式，什么时候都用得上。
