BAT实习内推笔试复盘：考点解析与备考策略全揭秘

每次在朋友圈发“拿到了BAT的实习笔试邀请”总有人回一句“BAT批处理脚本吗”在代码的世界里.bat是Windows的批处理文件后缀但在互联网求职圈BAT是百度、阿里、腾讯三家公司的合称是当年上百万应届生挤破头想进的名字。2015年春天我参加了BAT实习内推笔试卷的第二场——这件事本身并不稀奇但那一场笔试的考点密度、出题风格和后续连锁反应几乎重塑了我对“大厂面试”这件事的整个认知。这篇文章写给正在准备互联网大厂实习笔试的人尤其是那些拿到了内推资格、却对“笔试到底考什么、怎么考、怎么准备”一脸茫然的朋友。我会完整复盘BAT 2015实习内推笔试卷第二场的题型构成、三家公司的出题差异、核心考点的解题思路以及在线笔试环境下那些不容易被说破的实操细节。内容不保证每个字都适用于今天的题库但出题逻辑和备考方法放到现在依然有很强的参考价值。1. 内推笔试的“隐藏规则”第二场题目为什么更值得琢磨1.1 内推笔试和统招笔试差的不只是时间很多人对内推有一个误解觉得“内推免笔试”或者“内推走个过场”。实际上大厂内推最大的优势只是让你的简历能被人力资源部门或业务部门先看到笔试这道关卡基本躲不掉。BAT三家在2015年的实习生招聘都是这个套路先内推简历然后统一安排线上笔试过了笔试才有面试资格没过笔试就直接进人才池后续能不能被捞起来全看运气。内推笔试和统招笔试的差异主要体现在三件事上时间提前内推批次通常在3月中下旬开考统招批次可能要等到4月甚至5月早一批参加意味着能更早锁定实习名额。简历门槛不同统招批次简历量大筛选时会用学历、专业、实习经历做硬性过滤内推批次因为有内部员工背书简历筛选相对宽松笔试成绩反而成了更硬性的通行证。面试轮次内推批通过了笔试后续面试流程通常更紧凑有的部门两轮技术面一轮HR面就能发offer而统招批次可能要三轮技术面起。我在第二场笔试前其实还没完全想明白这些差异。后来复盘才意识到内推笔试的成绩不仅决定你能不能进面试还会直接进入面试官的系统。面试官在面你之前会看到你的笔试分数、每道题用了多长时间、代码提交了几次。也就是说笔试不是考完就结束的“入场券”它在很大程度上影响了面试官对你的第一印象。1.2 第二场意味着什么不是“备用卷”而是“复刻卷”很多同学会好奇“第二场”是不是题更难或者“第二场”是不是就是补考都不是。2015年BAT实习内推笔试安排得比较密同一个批次往往会在同一天开两场甚至三场线上笔试目的只有一个防止作弊和泄题。第一场考完题目截图可能已经传开第二场如果还用同一套题那考上来的全是“演员”。所以第二场是一套全新的、知识点分布和难度系数高度对位“第一场”的卷子。这就是我所说的“复刻卷”含义它不会简单也不会故意超纲而是和第一场保持同等难度覆盖同样的核心考点但具体题目完全换掉。那第二场有什么值得琢磨的因为出题人在编排第二场时会刻意把第一场里“考得不好”的知识点再做一次强化。如果你身边有朋友参加了第一场考完跟你吐槽“网络选择题好难”“编程题第三题没做出来”那第二场大概率会在这些薄弱点上出更细的题目。这不是玄学而是大厂出题时的常用策略——他们要的不是筛出所有合格的人而是筛出所有不合格的人两套卷子里至少有一套要精准命中候选人的知识盲区。我当时就是提前问了第一场考完的同学得到三条关键信息选择题里C内存相关题偏多、编程题的第二题考了字符串处理、数据库索引题比预想中细。于是第二场开考前我重点把C内存管理、字符串匹配的常见套路、MySQL索引的底层实现刷了一遍。后来考场上发现这三块确实全是重头戏。2. 三家公司的卷子风格差异出题人到底在考什么BAT三家的笔试虽然都在讲数据结构、算法、操作系统和网络但放在同一年的实习招聘里横向对比你会发现每家的卷面风格差异非常明显基本可以看作三家公司技术文化的一面镜子。公司选择题侧重编程题侧重整体观感百度C/C、操作系统、网络、概率论数组、字符串、动态规划入门算法密度极高短小精悍阿里Java、数据库、智力题、综合分析工程实现、场景设计综合感强业务味道重腾讯C、Linux、网络、数据结构字符串、指针、海量数据实用主义贴近真实工作2.1 百度算法题的密度让人喘不过气百度的卷子拿在手里第一感觉就是“选择题怎么这么多”而且每一道选择题都不是送分题四五个选项里经常有两三个看起来都差不多需要在草稿纸上推演半天。选择题密集覆盖C/C指针、内存布局、操作系统进程调度、网络TCP/UDP和概率统计。印象很深的是有一道概率题考“两个人抛硬币先抛到正面的人获胜”这样的经典模型但加了条件“如果连续两次反面则重新开始”不少人在考场上当场算懵。编程题部分百度是典型的“算法优先”风格题目数量不多但每一道都需要你静下心推公式。第一题往往是数组操作或者字符串处理属于“基础中的基础”第二题就会上难度可能是动态规划、二分变形或者某种需要脑筋急转弯的贪心。第三题通常是一道综合性题目需要你结合多种技巧。应对百度风格的笔试核心策略是刷题量要足够大尤其要把“常见题型的边界条件”背得滚瓜烂熟。比如数组下标越界、字符串末尾的空字符、整数溢出这些细节在选择题和编程题里都会反复出现。当时我刷题时经常踩这种坑后来养成了写完代码先自己构造极端用例的习惯这份习惯在百度笔试里救了我好几次。2.2 阿里综合卷里藏着“业务感”阿里的笔试卷子选择题里Java和数据库的比例明显更高还会出现一些“你觉得下面哪个方案更合理”的综合分析题。这类题没有绝对的对错考的是你在真实工程场景里的判断力——比如“某个接口很慢你是先加缓存还是先做SQL优化”答案不是背出来的而是要靠实际的项目经验去判断。阿里的编程题比百度温和一些没有那么多“做不出来就完蛋”的硬核算法但会给你一个完整的小场景让你实现一个业务功能模块。比如写一个订单号生成器、实现一个带过期时间的缓存、或者处理一段含有脏数据的日志。这种题目考的不是你会不会某个算法而是你的代码是不是“能上线”的代码——变量命名是否清晰、有没有防御性判断、异常处理是否完整。更吓人的是阿里笔试卷里时不时会出现一道“智力题”表面上看是脑筋急转弯实际上考的是逻辑推理能力。比如“一根不均匀的绳子烧完要一小时如何用它测出45分钟”这类经典问题2015年那会儿依然活跃在卷子上。这种题没法突击准备靠的是平时积累和临场心态。2.3 腾讯数据结构与应用场景结合最紧密腾讯的卷子给我的感觉是“最像程序员日常工作的考试”。选择题大量涉及Linux操作、vim命令、编译链接过程还有TCP状态转移和滑动窗口相关的内容。你如果平时只在Windows上写代码、不碰Linux腾讯的选择题会让你非常难受。腾讯编程题的特色是海量数据与数据结构的结合。比如“10亿个整数中找出出现次数最多的前100个”“两个大文件里找到相同URL”这类题目本质上不是考你会不会一个算法而是考你有没有“大数据量下优化时间复杂度与空间复杂度”的思维习惯。这种题没有标准答案但你的解题思路必须能落地不能只答“用哈希”就完事要讲清楚内存装不下怎么办、数据分布不均怎么办、IO瓶颈在哪。腾讯还会特别喜欢考“手写代码的规范性”。面试官在批卷时不仅看你的代码能不能跑出正确答案还会看你有没有养成“变量名有意义”“函数边界处理完整”“注释恰到好处”的习惯。我之前写代码一直很随意变量名喜欢用a、b、tmp直到被腾讯笔试的代码风格打分狠狠教训了一次才开始认真对待这件事。3. 我在第二场里印象最深的三道题思路、坑与复盘下面说说第二场笔试里让我印象最深的几道题。因为题目涉及公司保密要求我不能原样复述但我会把题型、考点和正确思路完整分享出来当年一起备考的几个朋友看到这几道题应该都能会心一笑。3.1 数组里找出现次数超过一半的数字这道题是笔试里经典的“众数问题”。给你一个长度为n的数组有一个数字出现次数超过n/2要求O(n)时间、O(1)空间找到它。大部分人第一反应是排序取中间值时间复杂度O(n log n)也有人会用哈希表计数时间复杂度O(n)但空间O(n)。但这道题的要求是O(1)空间这就排除了哈希表方案。正确的解法是“摩尔投票法”。核心思想既然目标数字出现次数超过一半那么把它和其他数字一一抵消最后剩下的那个数一定是它。int majorityElement(vectorint nums) { int candidate 0, count 0; for (int num : nums) { if (count 0) { candidate num; count 1; } else if (num candidate) { count; } else { count--; } } return candidate; }这个解法我第一次看的时候很不理解总觉得“凭什么抵消完剩下的就是众数”后来想明白了因为目标数出现次数超过总数的50%无论你怎么抵消它一定会剩下至少一个。注意题目如果只告诉你“有一个数出现次数超过一半”那直接返回candidate就行但有些变种题不会提前告诉你是否存在这样的数那就需要再遍历一次数组统计candidate的真实出现次数做二次校验。这道题的价值不在代码有多长而在于它考察你是否理解“为什么这样写是对的”。我在笔试现场看到这道题时心里想的是“面试官就是想用一行代码区分背题的选手和真正理解的选手”。3.2 TCP三次握手背后的“反直觉”提问网络题在BAT笔试里从来不缺席但考法越来越细。第二场里有一道关于TCP三次握手的题表面上问的是“为什么需要三次握手而不是两次”但选项里埋了不少坑。首先要明白三次握手的核心目的保证双方都确认“自己的发送能力”和“对方的接收能力”是正常的。第一次握手客户端发送SYN服务端收到后确认了客户端的发送能力、服务端的接收能力正常。第二次握手服务端发送SYNACK客户端收到后确认了自己的发送和接收能力、服务端的发送和接收能力都正常。第三次握手客户端发送ACK服务端收到后确认了自己的发送能力、客户端的接收能力正常。为什么不是两次因为如果只有两次握手服务端无法确认“自己的发送能力”和“客户端的接收能力”是否正常。更严重的是如果网络中滞留了一个旧的连接请求服务端收到后会误以为客户端要建立新连接从而建立一条无效的连接浪费资源。第三次握手的存在让服务端能通过ACK的序号判断这是不是一条新的有效连接。这道题后来在面试环节被追问得更深——既然要保证可靠传输为什么断开连接要四次而不是三次因为TCP是全双工的A向B发送FIN表示“我的数据发完了”但B可能还有数据没发给A所以B先回ACK告诉A“收到你的关闭请求”等自己的数据都发完了再发FIN给A这就是四次挥手。A收到FIN后还会进入TIME_WAIT状态等待2倍最大报文段生存时间2MSL确保最后一个ACK能到达B防止这个ACK丢失导致B重发FIN。这种题靠死记硬背很容易被选项绕进去。我当时因为提前复习过TCP状态转移图才能在考场上迅速画出每个状态的流转路径稳住了心态。3.3 短链接系统设计一道“开放题”的踩分点阿里的卷子里出现了一道很典型的设计题用一句话描述需求实现一个长链接转短链接的系统。这种题没有标准答案但踩分点非常明确。我的解题思路分三步第一步明确核心流程。用户提交长链接系统生成一个短码存储映射关系用户访问短链接时根据短码查找到长链接并302跳转。第二步设计短码生成方案。常见的两种做法是哈希截断和发号器。哈希截断就用MD5或SHA-1对原链接取哈希再截取前6到8位作为短码优点是实现简单缺点是可能产生哈希冲突需要配合冲突检测和二次哈希。发号器则是利用数据库自增ID或Redis的INCR命令把自增ID转换成62进制字符串作为短码优点是绝对不冲突缺点是依赖一个中心化的发号服务。我当时选择的是发号器方案因为它在高并发下更容易预判和调优。第三步设计存储和跳转策略。核心表就三列id、short_code、original_url加一个created_at。查询时先查Redis缓存缓存未命中再查数据库。跳转时用302临时重定向还是301永久重定向需要根据业务场景决定如果是临时活动链接用302如果是长期固定链接并且需要统计点击量用301更省服务器压力。这道题很多同学栽在“只写方案、不写细节”上。面试官要看到的不是“用哈希就完了”而是你能不能把表结构、接口、缓存、冲突处理、跳转状态码这些细节串起来形成一个能落地的闭环。这也是阿里笔试最核心理念的体现他们招的不是只会解算法题的人而是能“把一个功能从想法做到上线”的人。4. 在线笔试的实操技术细节考场上踩过的真实坑如果把笔试比作打仗那么知识储备是武器在线笔试平台则是战场。很多人花大量时间刷题却忽略了在“线上OJ环境”里做题和在自己电脑上写代码完全是两回事。4.1 OJ环境与本地IDE的差异2015年前后的在线笔试平台普遍没有现代IDE那种完整的自动补全和实时报错能力。你面对的基本上是一个普通文本框代码写完了提交上去编译器在服务器端跑一遍然后告诉你“通过”还是“不通过”部分平台会给出错误用例但很多平台只会给你一个冰冷的“0分”。这个环境带来的直接影响是你在本地IDE里养成的“依赖自动补全”的习惯在笔试现场会让你效率暴跌。我遇到过不少同学平时刷题写vector、unordered_map全靠IDE提示敲出来一旦到了没有补全的文本框里连头文件都写不齐。应对方法只有一个平时刷题时刻意关掉IDE的自动补全用最原始的文本编辑器手写代码。一开始会很难受坚持一两周后你对标准库的熟悉程度会明显上一个台阶。4.2 时间分配策略先挑软柿子捏BAT的笔试时长一般在90到120分钟题量很大选择题和编程题混在一起。很多人一上来就死磕编程题结果选择题还没做就交卷了这是最亏的丢分方式。我当时的策略是“三步走”前5分钟快速浏览整张卷子标记出哪些编程题是我看一眼就有思路的哪些选择题是送分题。优先做“有把握的编程题”和“送分选择题”先把基本盘稳住。最后再啃难题啃不出来也要尽量写部分思路有些平台是按测试用例比例给分的不是“非对即错”。这个策略最核心的价值在于它帮你建立了“分数最大化”的意识。笔试不是考试竞赛不需要每道题都做出来只要你的总分能超过分数线就行。为了一个难题浪费30分钟导致后面三道简单题没时间做属于典型的本末倒置。4.3 编程语言选型保守还是激进笔试编程题通常支持C、Java、C部分平台支持Python但Python的库支持不完整有些平台甚至跑不了Python 3。我当年选的是C理由很简单编译稳定、标准库够用、几乎所有OJ平台都支持。如果你精通Java用Java也没问题但要注意类名和入口函数必须符合平台要求比如Java的主类名经常被规定为Main写错了直接编译失败。如果你只会Python一定要提前确认目标平台的Python版本和模块支持情况尤其是sys.stdin和input()的用法不同平台表现可能不一样。我的建议是备考期间至少准备两种语言的模板输入输出模板比如C里cin和scanf的选择、Java里BufferedReader和Scanner的选择。常用数据结构的手写模板比如链表的反转、二叉树的遍历、并查集这些代码要能默写出来。笔试现场最忌讳的就是“现场想语法”这是时间杀手。4.4 输入输出、调试输出与复制粘贴的坑在线OJ对输入输出格式要求极其严格多一个空格、少一个换行都可能导致判题错误。我记得有不少人在本地调试时输出了一堆debug: xxx提交时忘记删掉结果整道题得0分。这种错误非常可惜因为代码逻辑本身是完全正确的。我在笔试前给自己定了一个“提交前三查”的规定一查有没有遗留的调试输出二查有没有使用绝对路径读取文件比如freopen(/Users/xxx/test.txt, r, stdin)这种代码在OJ环境会直接报错三查输入输出的格式是否和题目描述完全一致尤其是字符串是否包含换行、数组输出之间用什么分隔符。还有一个很多人会忽略的细节在线笔试平台的复制粘贴功能不一定可靠。有些浏览器插件会干扰文本框的粘贴操作导致代码粘上去之后缩进全部丢失、出现乱码。如果遇到这种情况不要慌重新粘一次或者直接用平台自己的“插入代码”功能逐段粘入。4.5 网络与断电的应急预案线上笔试最怕的突发情况就是网络断了、电脑没电了。虽然平台一般都有“断线重连”机制但临场遇到这种事心态非常容易崩。我准备的应急预案很简单考试前把手机热点设置为可用状态一旦家里或宿舍的网络断开马上切热点。代码写到一半时每隔10分钟按一次“保存”按钮很多平台有自动保存功能但手动保存永远是最稳妥的。如果平台真的崩溃了不要犹豫立刻截图存证然后联系监考人员说明情况和时间点。大厂的HR和笔试平台基本都有应急处理机制一般会安排重考或延长考试时间前提是你必须保留证据。5. 笔试之后的连环关卡面试官会追着你的试卷问笔试结束不代表这一轮结束了。笔试成绩出来后的几天内如果通过了你会收到面试通知。而面试官在面你之前大概率已经翻过你的笔试卷子。5.1 面试官是怎么“用”你的笔试结果的有一次现场面试面试官上来第一句话就是“你笔试的第三题我当时看了你的代码发现你处理边界情况很仔细能讲讲你的思路吗”那一刻我才意识到笔试分数不是只有“过”和“不过”两个维度面试官能看到的东西远比你想象的多。一般来说面试官会关注三件事分数考了多少分是否过线。代码风格变量命名是否规范、有没有写注释、代码结构是否清晰。行为过程你在一道题上卡了多久、提交了多少次。提交次数过多说明你的思路不稳定容易在边界条件上翻车。所以笔试答卷不只是“做完交上去”那么简单它几乎是你的第一张“技术名片”。写代码时把变量名起好一点关键逻辑加一句注释能在面试官心里留下一个不错的印象。5.2 现场面最容易被追问的几种问法笔试里那道“摩尔投票法”的题到了面试环节几乎一定会被追问。常见套路有以下几种“如果这个数组不是存在内存里而是存在磁盘上文件非常大你怎么找众数”这题考的是外部排序和分治思想需要把大文件切分成多个小块分别统计再合并。“如果众数的定义不是超过一半而是出现最多你怎么做”常规做法是哈希表计数空间O(n)。“能不能优化”这时候就要回到堆或者桶排序的思路找到Top1。“为什么摩尔投票法是正确的”这就是考察你对自己的代码是否有底层的理解。设计题也一样短链接系统问完方案后面试官会继续追问“如果短码用完了怎么办”“如果同一个长链接被多次转换要不要返回同一个短码”“数据库如果挂了怎么办”这些问题本质上没有标准答案但能看出你有没有真正想过一个系统在真实运行中会遇到的故障。我的经验是准备笔试的时候不要把每道题当成“考完就忘”的任务。每做完一道有价值的题都要顺着它的边界条件多想几个“如果”这些“如果”很可能就是你下一轮面试里会遇到的真实问题。5.3 项目经验比笔试更重要的加分项实习招聘的面试环节里项目经验的分量往往比笔试成绩更重。面试官问项目不是想听你说“我做了什么功能”而是想通过项目判断你的技术深度和解决问题的思路。比较讨巧的项目讲述方式是STAR结构SSituation项目背景是什么为什么做这个项目。TTask你在这个项目里负责的核心任务是什么。AAction你具体怎么做的用了什么技术遇到了什么难点怎么解决的。RResult最终效果如何最好有量化数据比如“接口响应时间从500ms降到100ms”。如果没有拿得出手的项目也可以把自己刷过的某个复杂题目包装成“小项目”比如“我实现了一个支持LRU淘汰策略的缓存”然后把这个缓存设计的细节讲透。面试官要考察的其实是你对“做一件事”过程中决策与取舍的思考。5.4 转正机制实习offer的另一层价值BAT三家的实习offer很大程度上是为了提前锁定优秀校招生。实习期表现好的同学大概率能拿到转正offer不用再参与秋招的惨烈竞争。所以拿到实习offer后不要只把它当成“去大厂镀金”的机会而是当作一个“试用期”来认真对待。我见过最可惜的情况是有人笔试面试表现非常亮眼实习期却因为主动性不足、代码质量一般而没能转正最后不得不回到校招战场上重新厮杀。实习期间建议做到三件事多问、多写、多复盘。遇到不明白的业务逻辑和技术方案一定要追根究底写的每一段代码都要保证注释清晰、边界完整每周回顾一下自己本周解决了什么问题哪些处理方式下次可以做得更好。6. 考完多年回头看BAT笔试真正筛的是什么距离那场笔试已经过去很多年回头看我会觉得BAT笔试真正筛选的东西不是“那些知识点你背了多少”而是三件更深层的事。6.1 基础深度知识点背后的完整体系笔试里的每道题都是一根“知识的引线”。比如一道TCP三次握手的题表面上考的是状态转移实际上考的是你有没有真正理解网络协议设计的因果关系。如果你只是背了“三次四次”的结论而不理解为什么是三次、为什么关闭要四次、TIME_WAIT存在的意义是什么那只要题目换一个角度你就会瞬间卡壳。所谓基础深度就是能把一个知识点从“是什么”讲到“为什么”。我备考时养成了一个习惯每遇到一个考点就试着在纸上把这个知识点画成一张完整的图并标注它和前后知识的关联。这种做法不能让你在短时间内多刷几十道题但能让你在真正面对陌生题目时有足够底层的知识储备去推理。6.2 手写代码的熟练度不仅是会更是快笔试的规定时间内编程题往往不是“会不会”的问题而是“写不写得完”的问题。很多同学思维很清晰但手写代码的速度太慢一道简单链表反转都要磨10分钟这样的速度在BAT笔试里注定是要吃亏的。手写代码的熟练度没有捷径就是多练。我当时给自己定的目标是把所有常见数据结构的基本操作练到“闭着眼也能写出来”包括链表反转、二叉树遍历、排序算法、并查集、拓扑排序。这个训练过程很枯燥但收获是在考场上能省出大量时间留给真正需要思考的难题。6.3 工程思维从“做题人”到“做东西的人”BAT笔试的终极筛选目标不是找一个“刷题机器”而是一个“未来能上手做事情的人”。所以你会发现选择题里会有“哪个方案更合理”编程题里会有“设计一个系统”面试环节更是直接围绕项目追问。工程思维的核心是“权衡”。在资源有限的前提下你选择哪种技术方案就要承担哪种方案的缺点。比如短链接系统里选了发号器方案就要考虑发号器单点故障怎么解决选了哈希截断方案就要考虑哈希冲突怎么处理。能够清晰地描述“我为什么选A不选BA的代价是什么”恰恰是笔试和面试中最能拉开差距的能力。我还记得那年考完BAT第二场笔试的晚上我坐在宿舍里把当天没做出来的题重新看了一遍整理了一份错题集每道题下面都写了“当时为什么卡住”和“下次应该怎么思考”。后来这份错题集伴随了我整个求职季每次面试前翻一遍都能有新的收获。如果你想准备一场高质量的笔试不妨也试试这个方法重要的不是把答案抄下来而是把“错误的思考方式”纠正过来。