这个标题我先说明一下：猿辅导的校招笔试批次编号，并不是说“（二）”比“（一）”难，而是说明这是第二批次的技术岗笔试场次。出现这种命名，通常意味着企业把校招周期拆成了多个笔试批次，每一批的题面都有差异，考察范围则保持稳定。我参加过类似规模的线上笔试，这类考试的核心特征是：题量不大、单题分值高、场景贴合业务、时间紧张到刚好做不完。它更像是对“工程思维+算法基本功+业务理解”的三合一压力测试，而不是单纯的OJ刷题比赛。
这篇文章我打算从笔试的整体结构、高频算法题、工程场景设计题、常见扣分点和备考路线四个方向做完整拆解。全文不涉及具体答案泄露，只讲方法论和题型规律，属于经验总结，适合正在准备2023届及之后校招的同学参考。
1. 笔试整体结构与考察逻辑
1.1 从卷面构成看技术岗的考察侧重
猿辅导2023校园招聘技术岗笔试（二）的卷面结构，我根据参加过同类考试的同学反馈和公开面经，做了个推断模型。整张卷子一般分成三块：编程题、客观选择题、场景设计题，这三块的占比和考察目标完全不同。
编程题一般是2到4道，每道题起步就是20分，分值非常高。这类题不完全是裸算法题，通常会套一个在线教育的业务外壳，比如课程安排、错题统计、直播观看记录、作业提交批改等。核心是考察候选人能不能在有限时间里，把一道有业务背景的题目抽象成数据结构与算法问题。客观选择题覆盖面很广，从语言基础、操作系统、计算机网络到数据库索引，都有涉及。这部分更看重基础功底的广度和准确性，答错会倒扣分吗？就我了解的一般在线笔试系统而言，大部分不会倒扣，但会按正确率排名，错太多就基本出局了。
场景设计题是猿辅导这类教育科技公司特别爱出的题型。它不是LeetCode那种有标准答案的题目，而是给一个业务场景，让你设计技术方案。典型问法包括：在线直播课如何应对几十万人同时进入、课程回放的存储成本如何优化、一套题目如何避免被学生截图秒传题库等。这类题没有唯一答案，但能非常清晰地区分出“背过八股文”和“真的理解系统设计”的候选人。
1.2 为什么笔试会分成“一”“二”“三”批
很多同学看到“（二）”就纳闷，是不是说这是补考或者更难的一批？其实不是。我的理解是猿辅导校招笔试走的是批次制，也就是多个时间段各开一场，每一场用不同的题面，保障公平性。你投得早，就参加第一批；投得晚，可能被排到第二批或第三批。代码题和场景题的难度会做平衡，不会出现第二批次明显更简单或更难的情况。
批次制对候选人的实际影响有两个。第一，你没法通过“先考的人透露题目”来押题，因为不同批次题面会换，但题型骨架不变，所以备考时更应该抓稳定的题型规律。第二，批次排名是按每场内部来的，建议尽早投递，不是因为后一批难度高，而是因为越靠后的批次，HC（招聘名额）可能越少。从我这几年观察校招的经验来看，早投的在同等水平下优势确实更大。
2. 高频算法题的解题思路拆解
2.1 基础算法熟练度的“及格线”
想在这场笔试里不空手而归，基础算法必须达到一个明确的及格线。这个线我认为是：排序、二分查找、双指针、哈希表、栈与队列、链表操作、二叉树遍历这七类，能做到读题后五分钟内想到思路、二十分钟内写出无bug代码。超过这个时间，基本说明刷题量不够或者总结不够，在笔试限时环境下会非常被动。
很多人有个误区，觉得题目难在算法本身，其实笔试挂掉的最常见原因是基础题写得太慢。我自己刷题时统计过，如果一道“中等难度”的题需要35分钟以上才能AC，那考试时基本没有时间做后面的场景题，因为真实考场上还会有阅读题面、调试、心理压力这些额外开销。建议备考时，用番茄钟模拟考试节奏：每道题给自己20到25分钟，超时就标记为薄弱点，然后针对性重刷同类题。
线性数据结构之外，图论和动态规划也是重点。这里有个小规律：在线教育业务的笔试，特别喜欢出拓扑排序（比如课程依赖关系）和区间类问题（比如直播时间段冲突检测）。动态规划则喜欢出背包和最大子数组变种。不是说其他类型不考，而是这些类型的出题概率明显更高，性价比也更高。
2.2 在线教育场景下的高频题型：拓扑排序与区间合并
我得说一个很多人忽略的事实：在线教育公司的笔试算法题，出题人偏好是有明确倾向的，而这个倾向直接来自业务。最能体现这一点的就是“课程安排”类题目。它看起来像套了层壳的拓扑排序：给定N门课的依赖关系，让你判断能不能完成所有课程，或者输出一种可行的学习顺序。
这类题的标准解法是：把课程看作图的节点，依赖关系看作有向边，然后做拓扑排序。可以用Kahn算法，维护一个入度为0的队列，也可以用DFS加状态标记检测环。如果考的是“能否完成”，本质上就是判断图里有没有环；如果考“输出顺序”，那就是完整的拓扑排序。还有变种会考“最少需要几个学期”——这个就变成了分层拓扑排序，每轮把入度为0的节点当作一层处理，层数就是答案。我建议把这类变种都刷一遍，因为它涵盖了拓扑排序的主要考点。
另一种高频题是“直播时间段合并”和“会议室预定冲突”，这是区间类问题。常见问法有两种：一是给一堆半开区间，问重叠最多的时刻有多少人同时在线；二是给一个总时间段和若干预约片段，问哪些时间可以安排新课。前者用差分数组或扫描线解决，后者则是排序后贪心合并。这种题写起来不难，但边界条件极易出错——区间是左闭右开还是左闭右闭、区间端点是否算重叠、合并后要不要保留原区间信息，都是失分点。
提示：做区间题时，先把区间按起点排序，再维护一个当前合并后的右端点。处理下一个区间时先判断起点是否小于等于当前右端点，如果是就更新右端点，否则开新区间。写完后一定要自己造一个跨零点或跨整天的时间数据来验证边界。
2.3 动态规划与数据结构的组合考法
动态规划在猿辅导笔试（二）中属于“区分选手档次”的题。它一般不会单独出裸DP，而是包装成“课时收益最大化”“错题最优分配”这类业务场景题。解题关键在于识别状态定义和转移方程。比如“选择一组不冲突的课时，使得总收益最大”，可以把所有课时按结束时间排序，定义dp[i]为前i个课时能获得的最大收益，然后二分查找不冲突的上一课时完成转移。
这里有个容易被忽略的点：动态规划的题目经常和高频数据结构一起考。你会不会在“线上直播同时在线人数达到峰值”这道题里想到用差分数组？会不会在“维护学生近期错题Top N”里想到用堆？会不会在“按题目标签聚合做题数据”里想到用Trie树？在线教育的业务特性决定了出题人喜欢考察数据结构和算法的组合应用，而不是单一算法。笔试前把堆、Trie树、并查集、树状数组的模板过一遍，会大大提升临场发挥的确定性。
从我的实测经验来看，不建议在笔试时硬想一个从未见过的新算法。正确策略是：读完题先判断这道题属于哪一类经典问题，然后快速套模板，再针对题目条件剪枝或优化。笔试只看结果，不看你解题过程有多巧妙。能用O(n log n)的二分过，就别去写什么花哨的线性算法，万一写错反而全盘皆输。
顺便说一句，代码的输入输出格式也要提前准备好。在线笔试不像LeetCode，不是只写个函数就完事，而是要处理标准输入输出，尤其是多组测试数据的情况。我见过有人因为忘了用while循环处理多组输入，导致只通过一个用例而心态崩掉的。这一块不值钱，但丢了分特别冤枉。
3. 工程与场景设计题的实操要点
3.1 线上笔试中的设计题怎么答才不丢分
场景设计题对大多数人来说是笔试里的“盲区”。有人看到题目要求设计一个系统就懵了，脑子里只有一堆零散名词，高并发、缓存、消息队列、分库分表，全堆上去，但逻辑不成体系。这类答案在阅卷人眼里就是“背了八股文但没消化”，得分很有限。
我个人建议用四层递进结构来组织答案：功能需求分析、技术架构设计、数据存储设计、关键链路容错。先说清楚这个系统到底要做什么，再说用哪些组件，然后说数据怎么落库，最后说挂了怎么办。这四层写下来，不管题目是什么，至少结构完整，逻辑能站稳。
比如一道题要你设计“大班直播课的互动消息系统”。第一层功能需求：支持进入房间、发送弹幕、点赞、老师连麦，还要区分消息类型和优先级。第二层架构：客户端通过WebSocket长连接接入，前边挂一个网关做连接管理，消息投递走Redis发布订阅，持久化用MQ异步写库，再配一个消费者把消息写入MySQL或对象存储。第三层数据设计：在线状态存Redis Hash，消息流水存Kafka或RocketMQ，历史消息冷备到对象存储。第四层容错：连接断开重连怎么续传消息，消息积压怎么降级，点赞这种高并发低要求的消息允许丢失但不允许阻塞主链路。
这样的答案就是有层次的，能看出你确实思考过业务和技术的关系。反过来，如果你只写“用Redis做缓存、用MQ削峰”，那就太粗了，基本等于没答。
3.2 结合在线教育业务的技术取舍
在线教育公司的技术岗笔试，设计题永远不会离开自己的业务场景。所以你要对在线教育的技术特性有一个基本认知，否则设计题根本不知道往哪个方向写。我总结下来，在线教育有四个非常突出的技术特征。
第一，高并发洪峰明显。直播课开课那一瞬间，几十万学生同时进入；寒暑假促销季，流量瞬间拉满。这种流量曲线是陡峭的，不像普通网站那样平稳。设计的时候就要考虑入口层的限流、网关层的伸缩、房间维度的隔离。第二，数据强一致和弱实时并存。作业提交后的批改结果必须准确，不能乱；但在线观看人数可以允许略有误差。所以数据库要保障一致性，而统计类的数据可以走异步链路。
第三，富媒体链路复杂。视频、语音、图片、文档，各种各样的媒体类型，涉及上传、转码、分发、播放、防盗版，这些都不是一道题能写完的，但设计时至少要提到“走异步任务处理媒体文件”，否则会显得完全不懂业务。
第四，教与学的双向互动要求高。不仅是老师讲到哪学生跟到哪，还有实时问答、随堂测验、小组讨论等场景。这类功能对实时性要求高，通常需要WebRTC、IM、白板同步这些技术栈。你在设计题里如果能把这些组件用起来，会明显体现出对业务的理解。
注意：场景设计题不是让你写论文，而是展示“需求分析—技术选型—落地实现”这条链路的思考。每一层写两三句关键实现即可，不要写大段废话。重点是让阅卷人看到你脑子里有完整的架构图，而不是背了一堆中间件名字。
3.3 一道综合设计题的完整思路演示
我拿一个比较有代表性的题演示一下：请设计一个“学生错题本系统”，支持学生上传错题、按知识点分类、定期推送复习计划。这是个看着不难但答题时容易写散了的题。
第一步我会先拆功能：上传错题（拍照/文本）、自动打标签（知识点/难度）、错题检索、复习计划生成。第二步架构：客户端调用后端API上传图片，对象存储存原图，异步队列触发OCR识别和题目解析，解析结果回写数据库和搜索引擎。学生查询走ES，复习计划用一个离线任务每天扫描错题数据，生成计划后推送到用户的待办列表。第三步数据设计：错题表、知识点标签表、用户复习记录表，错题表用MySQL分片，按用户ID取模分库，图片地址存OSS，审核状态用状态机标记。第四步容错：OCR识别失败时先保存原图，标记为“待人工校对”；复习计划生成任务失败要允许重跑，且不能重复推送。
这个答案就是完整的，它能体现你对业务场景的理解，也能体现技术选型的合理性。如果笔试时间紧张，至少要把功能需求、架构、数据设计这三层写出来，容错这层可以简单提一句，但最好不要完全省略。
4. 常见问题与排查技巧实录
4.1 代码提交中的隐藏扣分点
整理一下我在校招笔试里踩过、以及问身边同学收集到的真实丢分点，这些不是算法不会，而是各种“非智力因素”造成的。首先就是读题速度。很多人不是不会做，而是理解错了题意，特别是“题面里带业务描述”的题，容易把核心约束看漏。例如“每个学生最多只能选3门课”这种限制，如果没注意，写出来的解法复杂度就完全不对。
其次是测试用例的边界处理。笔试系统判题会跑很多边界用例，比如空数组、只有一个元素、数据量特别大、重复元素、数值溢出等。这些都是真实比过赛的人才知道的坑。我在笔试结束后对过几道题，发现经常是“主流程对了，边界挂了”，丢分丢得特别冤枉。
再就是语言选择的稳定性。我强烈建议所有人都用自己最熟悉、提交模板最熟练的语言去笔试，不要在考场上临时换语言。比如用Java刷题时，HashMap和PriorityQueue你还得想一下构造方法怎么写；而转用C++后又要注意迭代器失效和内存释放问题。用不熟的语言，每道题至少慢10分钟，这种隐性成本极度亏本。笔试前把常用数据结构的API打印一份，考前快速过一遍，非常管用。
变量命名和注释也算分吗？说实话我不会判你命名不规范就零分，但如果代码可读性太差，阅卷时很容易让人看不到你真实的思路。我建议局部变量用简单词意，关键逻辑旁边写一行注释。比如“//按结束时间排序，贪心选择最早结束的课程”这种注释，虽然不会加分，但能让阅卷人快速看出你的思路，避免误解。
4.2 时间分配策略：3分钟定生死
笔试时间管理是一门核心技能。不像之前刷题可以慢慢磨，一场笔试通常120分钟，包含2到3道编程题加若干选择和设计题，时间紧张是常态。我实测下来的比较合理分配是：选择题控制在20到25分钟内，编程题每题留25到30分钟，场景设计题留30到35分钟，最后留5到10分钟检查。
这里有个小技巧：拿到卷子先把所有题目快速扫一遍，标记出“一眼会写”和“需要想一想”的题，先做会写的，再做难的。不要在第一道题上卡一辈子，如果一道题超过20分钟还没思路，赶紧跳。千万不要有“我做出来这一道就赢了”的心态，因为系统看的是总分和提交率，不是单题正确率。
还有一个小分必争点：部分在线笔试系统会保留你每一道题的“部分通过”得分。即使你只能写出来一个暴力解法，能过30%的小数据用例，也一定要把暴力版本提交上去，比空着不交强得多。很多同学只顾想最优解，到头来连暴力分都没拿到，这是最可惜的事。
实操心得：我先写一个最暴力、最容易写对的版本保底AC一部分用例；然后在这个版本基础上优化。如果优化过程发现状态混乱，至少我还有保底分。这个策略我一直用到校招结束，屡试不爽。
4.3 备考路线的最后冲刺建议
行文到最后，我给正在准备这类教育科技公司校招笔试的同学一条可执行路线。如果距离笔试还有两周，第一周用来补基础和刷高频题型，第二周全部走模拟考试。模拟时一定要用真实的OJ系统或者在线笔试平台，不能用本地IDE，因为真实考场的代码补全、缩进、编译信息都非常原始，很多人第一次用会极其不习惯。
同时，要花半天时间了解这家公司的产品矩阵。猿辅导的产品线包括K12网课、斑马AI课这类启蒙产品、以及后来的阅读、素养等方向。笔试题目里的业务场景，大概率就是从这些产品线里提炼的。你如果知道斑马这类产品面向的是低龄儿童，就不难理解为什么可能出现“家长端”“作业打卡”“学习报告生成”这类设计题。提前预判场景，比临场硬想强太多。
最后说说心态。校招笔试的通过率通常不高，一场考试难免有几道题你就是做不出来，这很正常。我见过太多人因为一道题卡住，后面节奏全乱了，本来能拿的分也没拿到。笔试是一场“限时拿分”的游戏，目标不是满分，而是尽量把会做的题都做对、把能拿的分都拿到。我自己的经验是：一道题看了10分钟没思路，立刻标记，先做后面的；回头再看如果还没思路，就写个暴力解法交上去，然后赶紧去补设计题。这种节奏能保证你不会在一道题上浪费掉整场考试。
4.4 笔试后的复盘方法论
笔试结束后，不管感觉自己考得好不好，复盘都是必须的。我建议做个表格，把每道题考察的知识点、你自己当时的第一反应、实际解法、最终是否通过记录下来。特别是那些“当时没做出来、后来看到题解觉得很简单”的题，说明是你的题型熟练度不够，不是能力问题，下一轮复习就要针对这个类型专项突破。
另外，笔试过程中如果允许使用本地编译器，建议把代码保存下来，结束没来得及提交同样要存。出结果后跟标准题解对照，重点看自己的复杂度分析和边界条件处理差在哪里。这个过程很枯燥，但确实是我见过提升效果最快的方法。我身边秋招拿大厂offer的朋友，几乎无一例外都坚持复盘，而且复盘的深度比刷题数量重要得多。
还有个容易忽略的点：笔试成绩有时会和面试官看到的简历一起流转。所以笔试时设计题里提到的项目、技术栈，一定要是你真实接触过的。如果你在笔试卷上写了“熟悉Kafka”，面试官大概率会在后续面试里深挖Kafka，答不上来反而减分。宁可写“了解”“使用过”，也不要为了显得厉害就乱写。诚实评估自己的技术水平，是校招里的一种隐形竞争力。
