猿辅导技术岗笔试攻略：核心考点与编程题思路解析

1. 笔试整体设计思路与考察逻辑

1.1 为什么是“筛人”而非“教人”

先聊聊我当年做猿辅导这套笔试时的第一感受。无论是2023还是往后几年，校招技术岗笔试的核心目的始终只有一个：在尽可能短的时间内，用尽可能少的题目，把候选人的硬实力筛出来。你指望一场120分钟的笔试教会你什么新知识，那不现实，它的逻辑恰恰相反——它默认你已经掌握了《数据结构》《操作系统》《计算机网络》这些必修课的核心内容，笔试只是验证你有没有“真正学会”。

很多同学把校招笔试当成一次考试来准备，每天刷一堆偏题怪题。这个方向其实跑偏了。我做了三场猿辅导技术岗笔试之后最大的体会是：它考察的不是你做过多难的题目，而是你在有限时间内，能不能把最基础的知识点用对、用熟、用完。比如同样的双指针，你平时在LeetCode上可以慢慢想，但在笔试环境里，它考察的是你能不能5分钟内识别出“这题该用双指针”，然后10分钟内把边界条件全部写对。

1.2 猿辅导技术岗笔试题型与时间分布

从整体结构上看，技术岗笔试（三）基本保持了“选择 + 编程”的组合。选择题覆盖的范围比较固定，主要集中在以下几个方面：

• 操作系统（进程调度、死锁、内存管理、并发同步）
• 计算机网络（TCP/IP、HTTP、DNS、滑动窗口）
• 数据结构与算法（时间复杂度分析、排序特性、树与图的基本操作）
• 数据库（索引机制、事务隔离级别、SQL执行过程）
• 编程语言基础（C++内存模型、Java虚拟机基础、Golang的goroutine调度等）

编程题一般是3道，从易到难排列。第一题通常偏向于“模拟实现”或者“简单数据结构应用”，很多人15分钟内能搞定；第二题开始上强度，通常是一道需要分析贪心策略或者动态规划的题目；第三题往往是图论或者较复杂的动态规划，用来区分高手和普通人。

这里给第一次参加校招笔试的同学一个关键建议：不要一开始就盯着第三题。正确策略是先把所有题目快速扫一遍，然后用25到30分钟解决第一题和大部分选择题，留下充足时间给第二题，第三题视剩余时间决定是写暴力解还是直接放弃。笔试的评分往往按用例通过率计算，一个通过了80%测试用例的第二题，远比一个只跑通10%的第三题划算。

2. 选择题高频考点与失分点精讲

2.1 操作系统与网络的选择题陷阱

在我做的那份猿辅导笔试（三）里，操作系统和网络相关题目占比很高，而且很多题有明显的“陷阱”设计。我挑几个最有代表性的场景来拆解。

第一个常考的点是进程同步与互斥。题目往往给你一段“用信号量实现生产者消费者”的伪代码，然后问你哪个步骤错乱会导致死锁。这种题第一眼看上去很简单，但一旦信号量P、V操作的顺序颠倒，生产者先执行V(empty)再执行P(full)，就可能出现两个进程同时访问临界资源的情况。很多同学死记硬背“先P后V”的顺序，但不理解为什么，遇到稍微变化的场景就懵了。

我一直强调的理解方法是：把信号量理解为“资源计数器的锁”。P操作是“申请资源”，如果资源不够就阻塞；V操作是“释放资源”，同时唤醒等待进程。谁先谁后，决定了资源释放的时机，也就决定了是否会形成循环等待。你在笔试前最好能自己白板推导一遍生产者消费者问题，而不是停留在背代码。

第二个高频陷阱是TCP连接的状态变迁。比如题目问“服务端收到FIN后处于什么状态”，正确路径是CLOSE_WAIT，但如果前面还经历了四次挥手的过程，很多人会把CLOSE_WAIT和LAST_ACK搞混。我用了一个记忆方法：只要记住“谁主动关闭谁进入TIME_WAIT”，其他状态顺推就出来了。服务端在收到FIN、回复ACK后进入CLOSE_WAIT，随后自己调用close发送FIN，再进入LAST_ACK，直到收到客户端最后的ACK才关闭。这样一层层推，比死背状态图可靠得多。

2.2 数据结构和语言基础类题目的出题套路

数据结构相关的选择题，猿辅导的偏好是“给一段代码问复杂度”或者“给一个数据结构场景选最优解法”。比如栈和队列经常组合在一起出题，问你用两个栈实现一个队列，入队和出队的复杂度分别是多少。答案大家应该都知道是入队O(1)，出队摊还O(1)，但“摊还”这个词其实暗藏玄机——笔试题经常在这里埋坑，把摊还复杂度写成最坏复杂度，问你对不对。

再说说C++和Java的题目。校招笔试里语言题不会考太偏，但会考到面试官认为“你作为科班生必须知道”的内容。C++里最常见的有：虚函数表指针大小、局部变量和全局变量的存储位置、delete和delete[]的区别、vector扩容机制。Java里常见的有：HashMap在JDK 1.7和1.8之间变化的原因、G1和CMS的区别、ThreadLocal的内存泄漏问题。

如果你对这些问题还没有形成肌肉记忆，笔试前需要集中突击一遍。有个笨办法但很有效：把高频考点整理成一页A4纸，正反面各写一面，考前一小时来回看。我当年就是这样干的，选择题准确率提升明显。

2.3 时间分配建议：选择题不要恋战

关于选择题，我踩过最大的坑是“恋战”。遇到一道拿不准的操作系统题，心想再想一分钟肯定能想出来，结果五分钟过去了，编程题才开始。这是笔试大忌。

我的建议是：选择题单题用时不要超过90秒，拿不准的先标记，全部做完编程题后再回头检查。为什么？因为选择题答案即便错了，影响的可能只有一两分，而编程题一个测试用例不过可能就差了10%甚至20%的通过率，权重完全不同。先把大头拿到手，再回头啃硬骨头，这才是合格的应试策略。

3. 算法编程题核心思路与手撕代码

3.1 第一题：偏模拟与哈希表管理的题型

猿辅导笔试的第一题通常不会太难，目的在于让大多数人能“动笔”，不至于一上来就被打懵。比较典型的一道题是“多个有序数组合并去重，并找出第K大的数”。这类题目现在看起来很简单，但笔试里它会故意把输入规模写得很大，考察你是否知道怎么处理海量数据下的时间和空间复杂度。

正常的解法是维护一个小顶堆，先把每个数组的第一个元素放进去，然后每次弹出堆顶元素并压入同一个数组的下一个元素。这样得到的输出就是整体有序的。去重方面还可以再加入一个剪枝：如果当前弹出的元素和前一个相同，直接跳过。整个过程的时间复杂度是O(n log m)，其中m是数组个数，空间复杂度是O(m)。

如果你平时对堆不够熟悉，这道题还有一个取巧的方案：把所有元素全部塞进一个列表，通过内置排序函数处理，然后暴力去重取第K大。在笔试环境中，如果题目给出的数组总量不超过10^6，这样的解法可以拿到70%左右的测试用例分数，剩下的30%会因为超时被卡掉。我的经验是：实在写不出最优解，也要先把暴力解提交上去，至少能得分。

下面是我当时在白板上写的一个参考实现，语言用的C++，系统也支持Java和Go，思路都通用：

#include <bits/stdc++.h> using namespace std; int kthLargest(vector<vector<int>>& nums, int k) { priority_queue<int, vector<int>, greater<int>> pq; unordered_set<int> seen; for (auto &arr : nums) { for (int x : arr) { if (seen.count(x)) continue; seen.insert(x); if (pq.size() < k) { pq.push(x); } else if (x > pq.top()) { pq.pop(); pq.push(x); } } } return pq.top(); }

这个方法比“全部排序再取值”稍微优化了一些，它维护了一个大小为K的小顶堆，堆顶就是第K大的数。需要注意的是，这里的“去重”用了一个unordered_set，如果数组元素范围很大而且重复率不高，这个set本身也会占用不少内存。笔试时如果题目没有要求去重，可以省掉这一步，内存占用会更稳。

3.2 第二题：动态规划与状态转移的识别策略

第二题通常是一道“你一看就知道是动态规划，但状态转移要想一会儿”的题目。我遇到的一个改编版本是“给定一个数组，每个位置代表能跳跃的最大步数，问能否跳到最后一个位置”。这个题看起来可以贪心，也可以用动态规划，但笔试考察的点在于你能否准确判断用哪种策略。

贪心思路比较直接：维护一个当前能到达的最远位置，遍历数组，不断更新这个最远值。如果某个位置已经超出最远可达范围，说明跳不过去，返回false；如果最远值已经覆盖了末尾，直接返回true。这样时间复杂度O(n)，空间O(1)。但如果你在考场上一紧张，容易把边界条件写错，比如数组长度只有1时应该直接返回true，有人会漏掉这种情况。

动态规划写法虽然复杂度稍差，但思路更通用，适合作为兜底方案：

bool canJump(vector<int>& nums) { int n = nums.size(); vector<bool> dp(n, false); dp[0] = true; for (int i = 0; i < n; i++) { if (!dp[i]) continue; for (int j = 1; j <= nums[i] && i + j < n; j++) { dp[i + j] = true; } } return dp[n - 1]; }

这段代码的时间复杂度是O(n^2)，在笔试中如果数组长度不超过10^5，有几个用例会被卡超时。所以只能拿它当保底，不能当最优解。如果你能一眼看出这题适合贪心，就尽量写贪心版本。判断依据很简单：如果一个“局部最优选择”不需要回溯修正，那大概率是贪心；如果需要枚举所有子状态，那才是真正的动态规划。

3.3 第三题：困难图论题的一点点总结和取舍

第三题我在考场上基本是只写暴力、拿部分分数。这类题通常涉及图的连通分量、拓扑排序或者带权最短路。猿辅导比较喜欢考“有向无环图上的最长路径”或者“带障碍物的网格最短路径”这一类，因为它们既考验你对基础算法的理解，又设置了很多边界条件。

我当时遇到的题目大意是：给定一个有向图，每个节点有一个权重，求从某个起点出发到终点的所有路径中，路径上节点权重之和的最大值。如果图没有环，直接拓扑排序加动态规划就能解决；但笔试为了增加难度，图里可能混入环，要求你判断环的影响。

这种题想完全做对的难度确实不低。我的策略很明确：用深度优先搜索加上记忆化，先处理无环的情况；如果检测到环，则直接返回一个标志位或者跳过环上的节点，争取通过部分用例。因为第三题往往是压轴题，大家水平层次不齐，只要你能写出没有语法错误且有基本思路的代码，已经拉开不少人差距了。

int dfs(int u, vector<vector<int>>& graph, vector<int>& weight, vector<int>& memo) { if (memo[u] != INT_MIN) return memo[u]; int res = weight[u]; for (int v : graph[u]) { res = max(res, weight[u] + dfs(v, graph, weight, memo)); } return memo[u] = res; }

这段代码在无环情况下是正确的，但如果图里有环，它会导致无限递归。笔试时如果你时间不够，宁可加上一个访问计数数组，超过某个阈值直接返回一个默认值，也不要以“裸DFS”去赌测试用例里没有环。这里说的“取舍”不是让你放弃，而是让你在有限时间内获取最高分。

3.4 笔试环境下的输入输出处理细节

很多人程序逻辑写得没错，却在输入输出上被扣分，这是非常可惜的。猿辅导的笔试系统一般支持从标准输入读取数据，多组测试用例之间用空行或特定格式分隔。你需要在刚开始写代码时就确认好：第一行是测试用例组数T，还是直接给一组数据。

处理多组输入时，常见写法有两种。第一种是循环读取，先读一个整数T，然后循环处理每一组；第二种是使用while(cin >> x)这样的判断方式，直到文件结束。我比较推荐第二种，因为它在笔试场景下更稳妥，不需要关心一组数据和下一组数据的边界到底是用换行还是空格分隔。

int main() { ios::sync_with_stdio(false); cin.tie(nullptr); int n, k; while (cin >> n >> k) { vector<int> arr(n); for (int i = 0; i < n; i++) cin >> arr[i]; cout << solve(arr, k) << endl; } return 0; }

一定要记得关掉C++的输入输出同步，否则数据量大的时候很容易超时。Java可以用BufferedReader和StringTokenizer，Go用fmt.Scan性能也还可以。这些细节不复杂，但在笔试环境中每一点提升都很关键。

4. 笔试过程中的常见问题与排错实录

4.1 本地能跑，提交却报错怎么办

这是所有笔试考生最崩溃的时刻：本地IDE跑得好好的，复制到在线判题系统里，要么编译错误，要么答案错误，要么运行超时。结合我自己的经历和周围同学的反馈，常见原因有这几类。

第一类：头文件缺失。本地编译器可能默认带了某些头文件，但在线系统的编译参数更严格，比如直接用了unordered_map但忘记#include <unordered_map>。解决办法是写代码时把所有用到的容器头文件全部加上，别只依赖bits/stdc++.h。

第二类：数组越界。本地运行时，越界不一定立刻崩溃，可能只是读取了一个脏数据，输出刚好对；但在线系统有内存检测，越界直接报运行时错误。排查思路是检查所有循环边界，尤其是vector下标访问，优先使用at()方法临时定位越界点。

第三类：栈溢出。如果第三题用了递归且递归深度达到10^5以上，很容易栈溢出。可以把递归改成显式栈的迭代写法，或者在C++中把递归函数中较大的局部变量改为全局变量，减少栈占用。

4.2 时间不够用，要不要提前交卷

时间管理在笔试里真的很重要。我的建议是：如果还剩30分钟，已经写完了三道题，别急着交卷，逐个检查边界条件。怎么检查？对每道题，自己脑补几个特殊的测试用例，比如空数组、只有一个元素、全是重复元素、数值极大极小的组合。把这些输入代入自己的代码，看看输出是否符合预期。

如果还剩10分钟但第三题完全没思路，我的个人经验是不要死磕了。把已经做过的题目的答案再扫一遍，尤其是选择题，检查有没有误选、漏选。很多时候你回头一看，能发现之前在选项上画错了位置，或者把一个理解错的选项当成了正确答案。多复查一遍选择题，远比坐在那里对着第三题发呆有价值。

4.3 选择题拿不准时的排除法技巧

选择题丢分，很多时候不是知识不够，而是方法不对。我在做猿辅导笔试时，如果碰到单选题拿不准，会先把明显违背常识的选项划掉。比如操作系统里问进程间通信方式，如果混进来一个“全局变量直接共享”的选项，在没有任何额外说明的情况下，这个选项大概率是错的，因为进程间默认无法直接访问对方内存空间。

多选题要更小心，宁可少选，不要错选。如果系统规定选错一个就不得分，那在不确定某个选项是否正确时，最好别勾。如果系统按“漏选给部分分”来计分，那可以大胆地把确定正确的选上，不确定的放掉。这些计分规则一般会在笔试开始前说明，记得先看清楚再动手。

4.4 复查检查清单参考

下面这个清单是我自己在笔试最后15分钟会过一遍的内容。你可以直接拿来用：

• 输入输出：是否关了输入输出同步？打印的格式是否以空格结尾？要不要换行？
• 数组边界：是否有地方访问了n-1以外的下标？是否处理了n=0或n=1？
• 大数类型：中间累加过程会不会溢出int？是否换成了long long？
• 排序稳定性：题目要求的是稳定排序吗？如果用sort，会不会破坏顺序？
• 多组数据：当前解法能否处理多组输入？每组之间有没有错误累加？
• 异常情况：输入里如果有特殊字符，代码会直接崩溃吗？

这套清单看起来琐碎，但能帮你挽回大量因为“粗心”丢的分。校招笔试竞争激烈，有时候就是两三分的差距决定你能不能进入下一轮。

5. 考后复盘与后续面试衔接

5.1 如何科学地复盘一份笔试卷

笔试结束不是终点，反而是下一轮面试准备的起点。我当年会在笔试结束后，趁记忆还热乎，把每道题涉及的知识点记录到表格里。比如某道选择题考的是InnoDB索引结构，我就记下“B+树为什么适合范围查询，和B树的区别是什么”；某道编程题考的是状态机，我就记下“什么时候该想到用状态机而不是DFS”。

这样整理出来的清单，就是你个人专属的高频薄弱点。面试官在后续面试中，有很大概率会追问笔试相关题目的思路。比如笔试考了一道动态规划，面试环节可能就会让你现场讲一下“为什么要这样定义状态，有没有可能优化空间复杂度”。如果你只停留在“AC了”的程度，面试时很容易露怯。

5.2 利用笔试节奏反推面试准备方向

从猿辅导这类教育公司的笔试题倾向来看，它们对算法和数据结构的重视程度很高，因为在线教育的核心业务场景里，自适应学习系统、课程推荐、用户行为分析都需要扎实的数据处理能力。如果你通过笔试进入面试，面试官大概率不会只盯着项目经历，还会继续深挖算法底子。

这时候我的建议是：把笔试中那些“做对了但讲不清为什么”的题拿出来，重新用白板法做一遍。什么叫白板法？就是不开IDE，只拿一张纸和一支笔，把解题思路、复杂度分析、边界条件处理全部写出来。等到能流畅地把每一步讲给一个虚拟听众听，你对这道题的理解才算真正到位。

另外，结合猿辅导自身业务特点，可以适当了解一下海量并发场景下的缓存设计、消息队列应用、微服务拆分等内容。这些不一定会直接考，但会体现你对教育业务场景的技术理解，面试时是加分项。

5.3 个人体会：笔试成绩之外的收获

说实话，一场笔试最终能不能过，影响因素很多，包括竞争对手的整体水平、当年的招聘名额、岗位匹配度。但无论结果如何，认真对待每一场笔试并充分复盘，对个人的成长价值非常大。我自己的经历是，每次笔试后把错题整理成文档，几个月积累下来，就成了一个针对性极强的复习资料库，比任何市面上的题库都适合自己的薄弱环节。

校招季漫长的等待最消耗心态，一次笔试没发挥好，不代表后续没有机会。保持刷题手感，坚持复盘错题，这个节奏坚持到秋招结束，你会看到自己的进步曲线其实非常陡峭。祝大家都能拿到心仪的offer。