2015年那会儿移动互联网正处在爆发期阿里校招研发岗的在线笔试也是出了名的“硬核”。很多人一听到“阿里巴巴在线笔试题”就先怯了三分觉得肯定全是ACM级别的算法难题。实际上我当年考下来最大的感受是它更像一场“工程思维 基础功底 边界意识”的综合体检而不是纯粹的算法竞赛。题量不大但每一道题都能看出你对底层原理和异常场景的处理能力这也是为什么这么多年过去这套题还经常被拿来当模拟练习。这篇文章我不会去复述一份所谓的“标准原题”而是把当年考场上最典型、最具代表性的几类题目拆开讲透。如果你正在准备大厂研发岗、或者想检验自己的基本功这篇内容基本可以当一份“考前自查清单”来用。1. 阿里的在线笔试题整体结构是什么样1.1 题型构成与时间分配2015年阿里校招研发岗的在线笔试并不是全编程题而是“选择题 编程题 问答题”的组合。选择题覆盖的范围非常广从计算机网络、操作系统、数据库到Java/C语言细节、数据结构、算法复杂度分析都有涉及。编程题一般是两到三道放在最后需要在线提交代码并跑测试用例。整套题的时间通常是一个半小时到两个小时看起来时间还算宽裕但实际做起来非常紧张尤其是选择题里那些需要仔细推演的题很容易一不留神就耗掉十几分钟。这里要特别提醒第一次参加在线笔试的同学时间分配比做题顺序重要得多。我当时给自己定的策略是“选择题先做一遍超过三分钟没思路的直接标记跳过编程题至少留出45分钟”。事实证明这个策略是对的因为编程题不仅要写出可运行的代码还要考虑边界条件和暴力通不过的情况一旦卡在某个分支里时间会过得比想象中快很多。1.2 阿里研发岗到底在筛什么人从题目风格能明显感觉到阿里想选的不是“只会背题”的人而是“遇到没见过的场景也能稳住”的人。很多题目表面上考一个知识点实际上考的是你有没有真正理解这个方案背后的权衡。举个例子选择题里经常出现“哪种数据结构最适合做LRU缓存”这类问题。如果你只背过“HashMap 双向链表”这个答案可能觉得很简单但后面紧接着会追问“为什么单向链表不行”“为什么不用数组”“如果并发访问怎么办”。这些追问其实是在看你有没有实战意识而不是停留在教科书层面。所以准备这类笔试的时候不能只刷LeetCode还得把每个数据结构放到真实业务场景里想一想。2. 真题拆解我在考场上遇到的那些题2.1 第一类算法核心题算法题通常是整个卷子的重头戏但2015年这批题目并不追求偏题怪题更倾向于在经典题上做变形考察你的应变能力。记得有一道题是“找出数组中第K大的数”。这题本身很经典常见解法有三种先排序取第K个、用大小为K的最小堆、用快速选择QuickSelect。我当时的做法是快速选择因为它的平均时间复杂度是O(n)比排序O(nlogn)快一个档次。不过快速选择有一个很关键的坑partititon之后要判断当前枢轴的位置和目标位置的关系而且如果数组里有大量重复元素最坏情况会退化到O(n^2)。笔试环境里测试数据往往会包含极端情况所以必须在每次partition时用随机枢轴或者三数取中法来规避。这里我贴一段用于笔试可直接改的快速选择模板public int findKthLargest(int[] nums, int k) { int left 0, right nums.length - 1; int targetIndex nums.length - k; while (left right) { int pivotIndex partition(nums, left, right); if (pivotIndex targetIndex) { return nums[pivotIndex]; } else if (pivotIndex targetIndex) { left pivotIndex 1; } else { right pivotIndex - 1; } } return -1; } private int partition(int[] nums, int left, int right) { // 三数取中避免近乎有序数据导致递归过深 int mid left (right - left) / 2; if (nums[left] nums[mid]) swap(nums, left, mid); if (nums[left] nums[right]) swap(nums, left, right); if (nums[mid] nums[right]) swap(nums, mid, right); swap(nums, mid, right); int pivot nums[right]; int i left; for (int j left; j right; j) { if (nums[j] pivot) { swap(nums, i, j); } } swap(nums, i, right); return i; }笔试里除了这种算法题还有一道让我印象深刻的链表题“判断链表是否有环如果有找出环的入口。”这题的经典解法是快慢指针快指针每次走两步慢指针每次走一步如果两者相遇则有环。找入口的时候先把慢指针移回头部然后两个指针每次都走一步再次相遇的位置就是环的入口。这道题难的不是代码而是推导过程。如果把背后的数学关系搞清楚写代码就是两分钟的事。很多人在考场上能写出快慢指针但问“为什么第二次相遇就是入口”就答不上来了说明还是理解得太浅。2.2 第二类语言与基础原理题2015年阿里笔试里Java相关的题占了很大比例而且考得非常细。有一道题我记得很清楚“在JDK 1.7环境下为什么HashMap在高并发put时会导致CPU使用率飙升甚至死循环”这个问题现在看起来可能有些偏远因为JDK 1.8已经改成了尾插法加红黑树但在当年这几乎是大厂面试的保留题目。我当时看到这道题的第一反应是“这题考的不是HashMap怎么用而是它底层怎么实现。”那时候HashMap做扩容迁移元素用的是头插法也就是把原来链表上的节点按照遍历顺序一个一个反着插到新数组的桶里。单线程下没问题但多线程同时触发resize两个线程可能在迁移同一个链表时形成环形引用。下次再get这个桶里的key时就会在环上无限循环导致CPU飙高。其实如果你在笔试里遇到了这类原理题最稳妥的答题思路是“先说结论再说成因最后说影响和规避方式”。而且要记住面试官和阅卷人想看的不是背下来的结论而是你有没有真正读过源码。我当时在答案里直接画了一下“两个线程同时resize时链表节点A和B互相指向”的过程得分点基本就拿到了。还有一类常考的语言细节是“Integer缓存范围”。这题看起来很简单就是Integer在-128到127之间会走缓存不new新对象。但很多人忽略了题目里的陷阱“Integer a 127; Integer b 127; a b 输出什么”答案是true因为缓存。如果题目改成128答案就是false。这类题在笔试里基本属于送分题要做错就太可惜了。2.3 第三类数据规模与工程权衡题除了纯算法题阿里笔试里还有一类“工程场景题”它把一个现实中可能遇到的问题抛给你考察的不是某个具体API而是你分析和权衡的能力。我印象最深的一道题是“假设你的服务器产生了海量的访问日志每条日志里有一个IP需要找出访问次数最多的Top 100 IP内存大小有限你会怎么做”这道题的核心是“数据规模超过了单机内存”。常规思路是把大文件用哈希取模的方式拆分到多个小文件比如按IP的哈希值取模200分成200个小文件每个小文件用HashMap统计IP出现次数最后维护一个大小为100的最小堆找出每个文件里的Top 100再归并。这题考的就是你有没有“分而治之”的思维以及能不能在大数据量下估算出“内存够不够”。当时我在草稿纸上做了个粗略估算如果访问日志有1亿条每个IP按15字节算HashMap存储的开销加上key和value的包装可能超过2GB单机肯定扛不住。但如果分成200个文件每个文件只存50万条日志HashMap就完全能hold住。这样把“跑不动”的问题变成“分得开、合得拢”整个方案就成立了。类似的变体还有“两个大文件里各有一批URL找出同时出现在两个文件里的URL”和“海量数据里找只出现一次的数字”。核心思路都是“哈希分片 哈希统计 堆/归并”这套组合拳在笔试里几乎是万能的。3. 从读题到通过完整答题过程复盘3.1 读题与边界分析在线笔试和平时刷题最大的不同是你面对的是真实的OJ系统有各种隐藏测试用例读题的速度和准确度会直接影响最终分数。我第一次参加这种笔试时就栽在了一个很简单的题上——题目要求“输出所有不重复的三元组”我还没来得及考虑“数组里有重复元素怎么去重”这个边界条件就直接写出了三重循环。结果本地测试通过OJ一跑超时加答案错误双重暴击。后来我总结出读题时必须问自己的三个问题输入规模最大是多少决定能不能用暴力解法元素是否有重复决定输出结果要不要去重边界值比如空数组、单元素数组、全相同元素数组是否能正确处理。这三个问题看起来基础但绝大多数考场失误都源于其中一条没搞清楚。千万不要在“好像理解了题意”的状态下直接开写在线笔试没有hr在旁边给你提示所有坑都得自己提前想好。3.2 方案设计复杂度推算笔试里写代码不仅要保证正确性还得保证能过复杂度这道坎。很多题目的数据范围明摆着就是“不允许O(n^2)”如果你没有在动手前估算复杂度写完才发现超时那基本等于白写。我自己的习惯是看到题目先在草稿纸上写一下“输入规模n是多少我打算用的方案时间复杂度是多少最坏情况下会不会超时”。比如两个有序数组合并去重数据量是10万如果我用普通两层for循环最坏复杂度是O(n^2)那就是100亿次操作肯定超时。这时候就得换成双指针归并一次遍历搞定。还有一个容易被忽视的细节是“递归深度”。如果是用递归实现的算法且数据规模达到10万以上JVM默认栈深可能不够会导致StackOverflowError。遇到这种情况笔试里最好把递归改成迭代或者明确跟出题人“表个态”——用非递归方式实现哪怕代码稍微长一点。稳妥总是比炫技重要。3.3 编码实现的几个细节笔试OJ对代码的评判是全自动的你的代码不仅要能跑通还得注意一些细节输入输出格式必须严格按照要求多打一个空格或者少一个换行都可能导致格式错误类名、方法签名、返回值类型必须和题目给的模板一致不要把调试用的System.out.println留在提交代码里否则会严重干扰OJ的判断如果题目的输入是用空格分割的一行整数不要再用nextLine()去读整行然后手动split直接用nextInt()循环读取简单又不容易错。我见过太多人代码写得完全没问题结果因为类名写错了直接编译失败。这种低级错误在笔试里是致命的因为一旦提交次数达到上限就算之后改对了系统也会记录你的错误提交记录影响最终评分。所以我建议拿到题目先不急着写业务逻辑先把输入输出框架搭好确认能编译通过再往里面填核心代码。下面是一个典型的主流OJ模板以在线读入一组整数为例import java.util.Scanner; public class Main { public static void main(String[] args) { Scanner in new Scanner(System.in); while (in.hasNextInt()) { int n in.nextInt(); int[] arr new int[n]; for (int i 0; i n; i) { arr[i] in.nextInt(); } // 在这里调用自己的算法逻辑 System.out.println(solve(arr)); } } static int solve(int[] arr) { // 具体实现 return 0; } }用这个模板至少能保证“输入解析”不拖后腿剩下的就是纯粹考察算法本身了。笔试现场和时间赛跑任何能减少低级错误的模板都是加分项。4. 在线笔试最容易踩的坑一个个说清楚4.1 本地能跑OJ上就挂这是我最常收到的问题“我在IDEA里跑得好好的怎么一提交到OJ就报错”绝大多数时候不是OJ抽风而是你的代码在本地和在线环境之间存在着隐形差异。一个典型的坑是包名和类名。本地你可以在任意包下写class Test但OJ要求Main类而且不能带package声明。另一个坑是JDK版本。本地用的是JDK 1.8的stream、lambda、var关键字OJ环境是JDK 1.7直接编译失败。所以你在笔试前最好先确认清楚环境版本至少学会写不依赖新版本特性的代码。还有一个隐蔽的坑是文件编码如果你在代码里写了中文注释而OJ默认按GBK解码编译也会出错。我一般会尽量避免在提交代码里写中文注释就算写了用英文也不会引发生僻字问题。4.2 内存限制和输出格式两个隐形杀手在线笔试的题目通常会给出内存限制比如“256MB”。如果你忽略了这个限制贸然开一个int[n][n]的二维数组当n10000时光是这个数组就占掉400MB左右直接内存溢出。很多人觉得OJ只报“超时”其实“内存超限”同样是常见的失败原因。另外输出格式的“洁癖”往往比你想的更严重。有些系统要求每行末尾不能有多余空格有些要求所有输出结束后必须有一个换行这些细节你完全可以通过看样例输出“是什么样”来判断。最简单的办法是不要自己手动拼字符串而是把结果放进List最后用StringJoiner或StringBuilder拼接这样既能统一格式又能避免大量字符串拼接带来的性能问题。4.3 答题顺序和时间分配别把编程题留到最后在线笔试的时间有限但如果非要说一个最值得秉持的原则那就是“绝不要在前面的单选填空题上恋战”。选择题分值再高也只是一分或两分编程题要是空着那直接就是十几二十分没了。我当年第一次参加某家大厂笔试就是在前面的网络题上卡了半天最后编程题只写了半道考完才意识到本末倒置了。我的建议是拿到卷子先花两分钟把全部题目扫一遍大致判断哪些选择容易、哪些大题需要写代码然后优先把会做的快速做掉最后集中精力写编程题。如果你按顺序一路磕到底很可能让后面的“大头”白白流失。5. 备考思路从做题人到命题人视角准备这类笔试刷题当然重要但更重要的是“切换视角”。如果你能站在出题人的角度去思考“这个知识点为什么值得考”复习效率会高很多。以链表环入口那道题为例出题人真正想考的并不只是“你会不会用快慢指针”而是看你能不能把相遇时的数学关系讲清楚。当慢指针走了k步到达环入口快指针已经走了2k步两者在环内相遇意味着快指针比慢指针多走了若干圈。推导出“从头节点到环入口的距离等于相遇点到环入口的距离”之后代码就顺理成章了。这个推导过程才是整道题的核心价值。再比如海量数据Top K那类题出题人想看的也不是你会不会用PriorityQueue而是你面对“内存不足以一次性加载”这种真实约束时能不能把问题拆分成子问题再用经典数据结构解决。这类题目考的就是“工程思维”平时多想想“如果这个数据量放大一万倍怎么办”就成了自然而然的能力。如果你还有比较充裕的备考时间我建议按这样的顺序准备先把基础数据结构过一遍尤其是数组、链表、栈、队列、哈希表、二叉树做到“看到题目能立刻想到用哪个结构”然后主攻高频算法排序与TopK、二分、双指针、BFS/DFS、动态规划这是笔试算法题的绝对主力接着补语言细节和底层原理Java或C选一门主攻把集合类源码、并发模型、内存管理弄清楚最后用在线OJ做限时模拟每一次都当成真正的笔试练习时间分配和抗压能力。我在实际刷题中发现很多人不是不会做某道题而是“看得懂题解、自己动手就卡住”。破解办法只有一个别只看动手敲。最好把每道题都从头到尾写一遍然后故意改一两个条件观察代码会怎么变化这样才能真正形成自己的解题手感。再分享一个小技巧笔试前可以准备一份“代码模板备忘录”把常用的快排模板、二分模板、图遍历模板、并查集模板都用自己的语言整理一遍。考场上遇到类似的题直接套模板能省下大量思考时间把精力留给真正需要推导的部分。这份备忘录不用背下来关键是“写过、理清过”用的时候自然手到擒来。