这个标题我先说明一下猿辅导的校招笔试批次编号并不是说“二”比“一”难而是说明这是第二批次的技术岗笔试场次。出现这种命名通常意味着企业把校招周期拆成了多个笔试批次每一批的题面都有差异考察范围则保持稳定。我参加过类似规模的线上笔试这类考试的核心特征是题量不大、单题分值高、场景贴合业务、时间紧张到刚好做不完。它更像是对“工程思维算法基本功业务理解”的三合一压力测试而不是单纯的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答不上来反而减分。宁可写“了解”“使用过”也不要为了显得厉害就乱写。诚实评估自己的技术水平是校招里的一种隐形竞争力。