“工程A卷”这四个字，对我来说记忆太深了。2020年秋招那会儿，我投了快手后端开发岗，点开笔试链接看到试卷标题的瞬间，心跳直接加速。那套题不算特别难，但它的考察覆盖面、题目类型和埋坑方式，基本代表了当年互联网大厂工程类岗位笔试的主流水准。现在回头梳理这套笔试的整体思路和备考逻辑，对正在准备校招的人应该还有不小的参考价值。
1. 时隔几年回看“工程A卷”：它到底在筛选什么样的人
先说结论：快手这套工程方向的笔试卷，本质上不是在考“你会不会写代码”，而是在考“你在真实工程环境里能不能活下去”。这句话听起来有点玄，但拆开看就清楚了。
当年工程类岗位的笔试，普遍由两大块组成：一块是计算机基础知识的选择题，另一块是算法编程题。快手这套卷子的特点是，选择题量不小，而且很多题目不是单纯背概念就能答对的，它会用一道题同时考察两个知识点，或者给一个代码片段让你判断运行结果。这种考法对应届生来说非常不友好，因为很多人在学校里学知识是分门别类地学，计算机网络是计算机网络，操作系统是操作系统，但试卷把两者拧在一起的时候，知识体系不够扎实的人就会开始乱。
举个很典型的例子。如果一道选择题描述“一个TCP连接在四次挥手过程中，服务端处于TIME_WAIT状态时，进程还剩下哪些资源没有释放”，这道题表面是网络协议题，但如果你对操作系统的进程管理、文件描述符分配不够熟悉，你就很难想象“连接”这个抽象概念在操作系统里到底对应着什么实体。这恰恰是工程岗位日常要面对的问题——线上报了一个连接数异常，你既要在网络层面排查，也要看进程的文件描述符是不是被耗尽。
所以说，“工程A卷”筛选的并不是“知道最多知识点的人”，而是“能在压力下把分散的知识点快速串起来解决问题的人”。这个定位从笔试一直贯穿到面试，甚至贯穿到入职后的实际工作。
1.1 从试卷结构反推岗位能力模型
我当时做完题之后，仔细回忆了一遍卷面的出题结构，大致是这个感觉：
- 选择题：约20到30道，覆盖数据结构、操作系统、计算机网络、数据库、Linux基础、编程语言特性。
- 编程题：2道或者3道，难度从LeetCode中等偏简单到中等偏难不等，有的题目会结合一点实际业务背景。
- 整体时间：90分钟到120分钟，时间紧张是普遍体验。
这套结构对应到具体能力模型，其实就是五大块：算法基本功、操作系统和网络的底层认知、数据库与缓存的设计直觉、代码风格和工程意识、还有临场的时间分配能力。
这里要特别提醒一下，很多同学会把精力全压在编程题上，觉得刷题刷得多就能过。但实际上，选择题错得太多一样会挂。尤其像快手这种大厂，笔试系统通常有各模块的得分权重参考，算法题是权重最高的模块，但选择题的正确率是基础线。基础线过不了，算法题写得再漂亮也可能进不了面试。
1.2 一份工程笔试卷背后的业务信号
还有一个容易被忽略的点：试卷的出题风格其实会透露出这家公司当前的技术偏好。快手2020年正处于短视频业务高速增长阶段，后端面临的最大挑战是海量视频的上传、转码、分发，还有直播场景下的低延迟通信、弹幕系统的高并发写入。如果仔细回想那套试卷的选择题侧重，会发现它明显加强了对高并发、缓存、消息队列相关基础概念的考察，而不是像某些纯业务公司那样侧重Spring框架细节。
所以备考的时候，不要只是孤立地刷题，要知道你投的这家公司、这个部门，日常业务到底在解决什么问题。对着业务倒推考点，比对着考点目录一通瞎背要高效得多。
2. 高频考点的分层复盘：哪些题决定了你能不能进面
虽然我不能把当年的原题一字不差地复述出来，但“工程A卷”的题型框架和考察重心，在同类大厂笔试中非常有代表性。下面我把考点按照“必拿分”“拉分项”“区分项”三个层级拆开讲，这个分类方法我后来也推荐给了好几个学弟学妹。
2.1 第一层：必拿分的基础题，错一道都可惜
这一层主要包含：
- 数据结构的基础操作复杂度，例如数组和链表的插入删除区别、哈希表的冲突处理、二叉搜索树和平衡树的查找复杂度、堆的调整过程。
- 计算机网络的基础协议机制，TCP三次握手和四次挥手、TCP和UDP的区别、HTTP状态码的含义、DNS解析过程。
- 操作系统的基础概念，进程与线程的区别、死锁的四个必要条件、虚拟内存与分页、常见进程调度算法。
- 数据库的基础知识，索引的数据结构、B+树特性、事务的ACID、隔离级别、乐观锁与悲观锁。
这些内容有一个共同特点：都是《王道考研》或者大学课本里的标准知识点，只要系统性过一轮，基本不会丢分。当年很多同学栽在“以为简单所以没复习”的心态上。比如TCP的TIME_WAIT状态为什么要等待2MSL，这种题几乎年年考，但每年都有人答错，原因不是不知道，而是没有真正理解设计这个状态的初衷。
TIME_WAIT这个点值得稍微展开一下。它等待2MSL的核心目的有两个：第一，保证最后一个ACK报文能够到达对端，如果ACK丢失，对端会重传FIN，此时TIME_WAIT状态下的连接还能响应；第二，让本连接产生的所有报文在网络中自然消亡，防止旧连接的延迟报文影响到新连接。这个知识点在笔试里通常只是选择题，但如果你能把它理解到这个深度，面试阶段聊到“线上大量TIME_WAIT怎么处理”的时候，你就比那些只背答案的人有优势得多。
2.2 第二层：拉分项的中等题，决定你的笔试排名
这一层的题目，通常需要两个以上的知识点结合起来才能解。我印象比较深的几类组合方式：
- 给一段代码，问你它的输出，但代码里同时涉及指针/引用的传递、变量的生命周期、内存分配位置（栈上还是堆上）。
- 描述一个线上故障场景，例如数据库连接池被打满，让你判断最可能的原因是什么，选项里混着网络、连接池配置、慢SQL、死锁等多个因素。
- 给一个系统设计场景，比如“设计一个短链接系统”，但笔试阶段不会真的让你写系统设计，而是把这个场景拆成若干选择或简答，考察哈希取模、布隆过滤器、缓存淘汰策略等单点知识。
这里想重点聊一下“代码读输出”这种题型。很多人觉得这种题就是考细枝末节，没什么意义。但实际上面试官想看的是你对程序的运行机制有没有完整的心智模型——变量在哪一步被创建、在哪一步被销毁、内存里发生了什么、最终结果是什么。你如果只能写出代码但不知道它为什么这样输出，说明你对编程语言的底层理解还停留在语法层面。
我当年备考这个模块的时候，用的方法是自己给自己出题：选几个容易混淆的语言特性，写一段短代码，先在脑子里推演输出结果，再放到机器上验证。C++的深拷贝浅拷贝、虚函数表、静态变量初始化顺序，Java的自动装箱缓存、String不可变性、finally和return的执行顺序，这些都属于高频考察范围。
2.3 第三层：区分项的难题，决定你能不能拿高分
最后一类题目，是真正拉开差距的部分，通常出现在编程题里。
“工程A卷”的编程题难度，我个人的体感是：第一道题偏简单，基本是LeetCode中等偏下的难度，考察基础的遍历、双指针、哈希表使用；第二道题开始上强度，可能涉及动态规划、贪心算法，或者一个需要仔细处理边界条件的模拟题；偶尔还会有一道带业务包装的题目，比如“根据用户观看记录推荐排序”之类的，但剥掉外表还是经典算法问题。
这里要说的一个关键策略是：笔试的编程题，不需要最优解也能过，但需要能跑通大部分测试用例。系统判题通常是跑若干组数据，按通过比例给分。如果你能快速写出一个暴力的正确解法，拿到60%到70%的分数，就已经比那些死磕最优解但最后没写完的人强很多。
当年我第二道编程题一开始也没想到最优的DP状态转移，但我先写了一个回溯解法，把能过的小规模数据全过了，最后剩几分之一的时间才优化到部分剪枝。成绩出来以后编程题这一块的得分率很不错，靠的就是这个“先暴力保底，再逐步优化”的思路。
3. 笔试现场的答题节奏和取舍策略
这一节说点实战的东西。笔试和平时刷题最大的区别在于：你的做题策略不再是从简单到难顺序推进，而是需要根据整张卷子的情况动态调整。我当年就因为策略失误，在前面的选择题上耗了太久，导致最后编程题差点没写完，这个教训印象深刻。
3.1 拿到试卷前五分钟：不要急着点开编程题
很多人习惯拿到卷子之后先跳到编程题，觉得编程题分值高，要先啃硬骨头。这个策略在大厂笔试里其实是有风险的。因为编程题一旦卡住，你的心态会迅速崩塌，再回头做选择题的时候，注意力已经涣散了。
更合理的做法是，拿到试卷后的前5分钟，先快速扫一遍整张卷子：
- 浏览选择题，心里标记哪些是秒选的，哪些需要稍微推演，哪些完全没底。
- 浏览编程题，判断每道题的题型和大概难度，分配预期时间：简单的题15到20分钟，难的题25到35分钟。
- 给检查留出至少5到10分钟的时间，专门复查选择题里容易粗心的计算类题目。
这套流程看起来简单，但很多人在紧张的笔试氛围里根本不会执行。他们点开卷子就开始做，做到哪算哪，结果往往是前面选择题耗费太多时间，后面最值钱的编程题草草收场。
3.2 选择题：遇到不确定的题，不要死磕
选择题的解题策略，核心就两条：第一，不会的题先标记跳过；第二，遇到计算题要熟练运用排除法。
做题过程中你一定会遇到一两道完全没见过的题，这很正常。大厂笔试偶尔会故意放一两道超纲题，考察的就是你在不确定情况下的决策能力。应届生没有完美的知识覆盖，但你要学会承认这一点，然后果断跳过，做完其他题以后再回来用排除法处理。
排除法也不是随便排除。比如一道关于数据库索引的选择题，四个选项里，你要抓住最核心的判断标准——B+树的叶子节点存储数据、非叶子节点只存索引键值，这两个特性决定了它能支撑范围查询和高扇出。知道了这两条核心特性，即使选项设计得很绕，你也能排除掉两个明显矛盾的选项，剩下的二选一正确率就高多了。
3.3 编程题：先跑通，再跑好，最后才跑快
这一节的标题就是我当年笔试编程题全部的心得总结。具体展开说：
第一步，跑通：用最直接的方式把题目给的示例跑通。这个阶段不要管时间复杂度，暴力解、枚举解、递归解都可以，先保证你的思路在逻辑上是正确的。 第二步，跑好：把暴力解法中明显冗余的循环或重复计算去掉。比如两数之和从双重循环优化到哈希表，这步通常不难，但能把大部分测试用例的耗时压下来。 第三步，跑快：如果时间还有富余，再追求最优解。动态规划的状态设计、贪心的正确性证明，这类深度优化只在第一步和第二步都完成之后再考虑。
还有一个很重要的细节：多花一点时间读题，尤其是限制条件。数据范围是10的3次方还是10的9次方，直接决定了你能不能设计O(n²)的算法，抑或是必须用O(n log n)甚至O(n)。边界条件里藏着的坑，往往是整张卷子最阴的地方。
当年有一道题，描述的是“给定一个数组，求连续子数组的最大和”，标准答案就是动态规划经典题——最大子序和。但题目在边界条件里写了一句“子数组长度至少为1”，有些同学没注意，把空子数组也算进去了，结果测试数据一跑就错。这种丢分真的太亏了。
3.4 时间不够时的止损方案
如果你在编程题上已经完全卡住，或者时间已经严重不足，最后一个止损方案是：写出完整的解题思路注释，然后按最简单的方案实现。很多笔试系统的评分不是只看测试用例通过率，还会人工抽查代码的可读性和解题思路。你写一个暴力解法加清晰注释，比写一个只有半截的“最优解”得分要高得多。
4. 从笔试到面试：复盘记录比刷题量更重要
笔试结束之后，很多人就彻底把题目忘了。这是很浪费的一件事。大厂笔试的考点和面试高度相关，你可以在笔试题目中看到公司当前的技术关注点，这些关注点大概率会出现在面试官的提问里。
4.1 笔试后立即做一份“错题复盘表”
我的习惯是，笔试结束后一到两天内，趁记忆还有余温，立刻把试卷里所有的考点整理成一张表，分三列：题目涉及的知识点、我当时的选择/答案、正确的解析和我的理解偏差。
这张表不需要很正式，自己看得懂就行。但它有一个非常重要的作用：它会把你的知识盲区具象化。你可能会在复盘时发现，原来自己不懂的并不是“TCP四次挥手”，而是“为什么主动关闭方要进入TIME_WAIT”这个深层次的机制。找到这个盲区之后，你再针对性地看资料、补知识，效率比漫无目的地刷题高得多。
4.2 把考点按照“笔试题”重新梳理成“面试题”
笔试的知识点，正是面试的高频考点。比如：
- 笔试考了TCP三次握手的状态转换——面试就会追问：SYN Flood攻击的原理是什么？半连接队列和全连接队列有什么区别？如果队列满了会发生什么？
- 笔试考了数据库索引的B+树——面试就会追问：为什么用B+树而不用红黑树？索引失效的场景有哪些？覆盖索引和回表是什么？
- 笔试考了进程和线程的区别——面试就会追问：协程跟线程相比有什么优势？什么时候用多进程，什么时候用多线程？
这个过程其实就是把“被动刷题”变成“主动构建知识体系”。我遇到很多刷了几百道LeetCode的同学，算法题很溜，但一到面试问底层原理就露怯，原因就是他们从来没把笔试和面试用一条逻辑线串起来。
4.3 一个亲测有效的“三天复盘法”
这里分享一个我后来一直用的复盘节奏，不一定适合所有人，但对我自己帮助很大：
- 笔试当天：考完立刻记录所有能记起来的题目和答案，不用整理，能记多少记多少。
- 第二天：整理错题表，把每个考点的正确理解写清楚，查阅资料补齐深度。
- 第三天：基于错题表给自己出三道题，检验是否真的理解了。
这套方法的精髓在于“后来再做题”而非“当场对答案”。当场对答案容易产生“我会了”的错觉，隔了一天再检验，才会计较自己是不是真的想明白了。
5. 写给后来人的避坑清单：那些我踩过的和见过的坑
最后一部分，说说我在整个校招笔试季中踩过、以及身边同学踩过的一些坑。这些细节看起来很小，但关键时刻真的会左右结果。
5.1 设备与环境的坑，比想象中多得多
笔试前的环境准备，我建议至少提前一天做好。包括：
- 找一台性能稳定的电脑，确保摄像头能正常使用，光线充足、背景干净。
- 网络环境提前测试，最好准备一个有线网络作为备份，Wi-Fi不稳定的时候果断切换。
- 确认浏览器版本和笔试系统的兼容性，关闭所有的弹窗拦截插件。
- 准备好草稿纸和笔，放在手边，不要考试中途再去找。
这些准备工作看起来不起眼，但每年都有人因为摄像头黑屏、网络断线而错过整场笔试，这个教训太惨了。
5.2 审题的坑：题目里的每个字都不是废话
大厂笔试的题目描述，信息密集度很高。限制条件、输入范围、边界情况、输出格式，每一句话都可能影响你的解法。我见过太多同学在群里抱怨“我的思路明明是对的，为什么通过率为0”，结果一问，原来是没有处理多组输入，或者输出格式多了空格和换行。
这里强烈建议：编程题写完以后，至少用三组不同的输入做测试——第一组是示例输入，第二组是边界输入（空数组、只有一个元素、最大数值范围），第三组是随机输入。三组都通过，这题才算基本稳了。
5.3 心态的坑：不要被周围人的进度影响
笔试的时候，网上会有人同步直播讨论题目，甚至有人会在群里发答案。这里我的态度很明确：不看、不提、不服。原因有两个：第一，大厂笔试通常开考后一段时间内各套试卷的题目顺序不同，别人发的答案不适用于你的卷子，反而会干扰你的判断；第二，笔试过程中分散注意力去看别人都在做什么，纯粹是消耗自己的心理能量。
你要相信，你在考场上做出的每一个判断，都是你当前能力水平的最真实反映。与其焦虑别人写得怎么样，不如把精力用在可控的事情上——审题、做题、查边界。
5.4 知识体系广度与深度的平衡：以工程视角去备考
最后想说的，是写在最前面那句“工程岗笔试到底在筛选什么样的人”的延续。我建议在准备笔试的过程中，不要只做一个“技术名词收集者”，而是尝试用工程师的视角去理解每个知识点：
- 学TCP的时候，想一想为什么你的视频App看直播偶尔会卡顿，和TCP的拥塞控制有没有关系。
- 学MySQL索引的时候，想一想为什么表数据量大了之后查询突然变慢，索引失效是怎么发生的。
- 学操作系统的时候，想一想为什么一个进程能同时处理几万个网络连接，IO多路复用到底复用了什么。
当你开始用“解决真实问题”的心态去复习这些内容，而不是用“应付考试”的心态去死记硬背，你会发现笔试和面试的题目其实都是在围绕这些真实问题展开的。这个认知转变，是我整个秋招过程中最大的收获。
快手“工程A卷”只是无数校招笔试卷中的一份，但它的出题思路代表了大厂工程类岗位对候选人的普遍期待：基础扎实、思路清晰、能在有限时间内做出合理取舍。真心希望这些复盘和分析能帮到正在准备笔试的你，少走一些我当年走过的弯路。
