1. 一份B卷三门岗先弄清楚这场笔试到底考什么先说个背景。欢聚时代也就是后来大家更熟悉的欢聚集团YY2018年的时候正处在一个很有意思的时间节点YY直播的秀场和游戏直播业务正值巅峰虎牙直播还在体内孵化、准备独立上市整个公司对技术人才的需求横跨直播底层、海量并发、用户增长和内容推荐。那年的校招笔试把所有岗位拆成了A卷、B卷——同一场考试、不同的卷面主要目的是防止相邻座位的两个人互相“参考”。今天要聊的这份Java开发/运维研发/数据挖掘B卷就是当年三拨人共用的一套题。我当年也是那批考生之一。现在回头看这套题最大的价值不在于“背会了就能过”而在于它非常典型地反映了互联网公司校招笔试的出题逻辑客观题卡基础面编程题卡代码能力场景题卡工程思维。三个岗位共用一份卷子意味着卷子里必然有一批题目是所有人都要做的还有一批是分方向选做的。这种结构和现在很多大厂的笔试试卷几乎没有本质区别所以哪怕已经过去这么多年拿它当备考材料依然不过时。先说卷面结构。整套B卷考试时长三个小时总分通常100分或者120分具体分数分配记不太清但题型分布很稳定题型题量常见的出题范围建议用时单选题20道左右数据结构、操作系统、网络、语言基础30分钟多选题10道左右概念辨析、边界条件、易混淆知识点20分钟编程题2-3道算法、数据结构、场景编码60分钟方向选做题2-4道按Java/运维/数据挖掘分方向40分钟简答/场景题1-2道故障排查、系统设计、分析思路30分钟这份卷子的核心逻辑是所有人都要具备扎实的计算机基础然后再看你对自己方向的掌握深度。Java开发、运维研发、数据挖掘这三个岗位表面上是三条完全不同的职业路径但笔试都在考察“一个合格工程师的基本盘”。我当时做完这套卷子的感受是数据结构和操作系统的基础题占了将近一半的分值剩下的一半才是岗位差异化的内容。要特别说明的是下面要展开的题目内容是基于这套B卷的题型框架、考察方向和当时互联网校招的通行考法做的复盘式还原具体题面未必和原卷一字不差但考察点、答题思路、踩坑点都是当年同场笔试的真实经验。毕竟一份笔试真正的价值从来不是让你背下某道题的标准答案而是让你搞懂出题人想通过这道题看见你身上的什么能力。2. Java开发方向的题从基础语法考到JVM底层2.1 基础语法与集合类的考查角度Java岗的客观题覆盖面很广但高频考点始终是那几个String相关的不可变性、HashMap的底层结构、ArrayList和LinkedList的差异、异常处理机制、泛型擦除、反射。2018年那会儿Java 8已经是主流所以lambda表达式和Stream API也经常出现在多选题里。举例来说有一道多选题大概是这样的下面哪些操作会让HashMap出现线程安全问题选项里有多个线程同时put、多个线程同时扩容、多个线程同时读、一个线程遍历时另一个线程修改。很多人看到“读操作”觉得应该安全实际上HashMap的读操作在jl领域下如果另一个线程正在修改结构很可能读到不一致的数据甚至死循环这在JDK 7及以前是真实发生过的问题JDK 8改成尾插法后死循环问题基本解决了但数据丢失和覆盖仍然存在。这道题其实在考“HashMap不是线程安全的”这个结论背后的机制而不只是让你背结论。集合类的题我建议准备的时候多做一步把源码读一遍。不是说让你把整个HashMap源码逐行背下来而是至少搞清楚put和get的完整流程链表什么时候转红黑树TREEIFY_THRESHOLD8扩容时为什么要重新计算hash等。笔试里很多选项就是根据源码里的细节设计的死记结论很容易掉坑。2.2 并发与JVMJava岗笔试题的“分水岭”Java方向的简答题和编程题往往从并发和JVM两个方向拉开差距。我记得那年的卷子里有一道简答题是问volatile关键字的作用和局限性还追问了它在单例模式双重检查锁里的使用。这道题说难不难但想拿高分必须答出这几层volatile保证可见性禁止指令重排序不保证原子性所以i这类复合操作依然不安全底层通过内存屏障lock前缀指令实现在JMM层面涉及工作内存和主内存的交互在双重检查锁的单例中volatile是为了防止new Singleton()这一步的指令重排导致其他线程拿到半初始化的对象一道题就覆盖了Java内存模型、指令重排、并发编程三大块。这种题你只答“保证可见性”是不够的要把机制讲透最好还能画一画内存屏障的示意图当然笔试时候不用画说清楚就行。JVM的考点集中在内存区域划分、GC算法和常见参数、类加载机制。有一道选择题我印象很深以下哪些区域是线程私有的选项是堆、虚拟机栈、方法区、本地方法栈。很多人把方法区记成线程私有的——实际上方法区是堆的“逻辑一部分”属于线程共享线程私有的是虚拟机栈和本地方法栈。这类题目没有技巧就是背熟JVM运行时数据区的划分图。那道场景题则更进阶直接给了线上环境的内存和GC日志让考生定位OutOfMemoryError该从哪里下手下面单独展开。2.3 一道经典的“内存溢出排查”笔试题的解题链路这道场景题大概是这样线上服务报错java.lang.OutOfMemoryError: Java heap space且GC日志显示Full GC非常频繁给你几个现场信息——堆最大1GB、老年代占用持续高位、有大量对象在做G1之外的老年代GC后存活率很高让你给出排查思路。这道题的真实考点不是“怎么用jmap把堆dump下来”而是你有没有一套完整的排查链路意识。完整的答题思路应该是第一步先确认是“内存泄漏”还是“内存分配速率过高”。前者是老年代对象只增不减后者是创建对象的速度太快、GC回收不过来。区分手段是连续观测GC日志每次Full GC后老年代是否回到一个低水位。第二步用jstat -gcutil [pid] 查看各代的使用率变化关注Old区的百分比走势。用jmap -dump:live,formatb,fileheap.bin [pid] 导出堆快照注意这个命令会触发一次Full GC生产环境谨慎操作。第三步用MAT或者jvisualvm分析堆快照看支配树里哪些对象占了最大堆空间。比较典型的结果是线程池里的任务队列积压了未处理的消息对象、或者某个全局缓存Map只往里塞数据不淘汰。第四步如果堆快照看不懂还有一招是结合代码review看哪里用了静态集合、哪里new了大数组、哪里用了byte[]缓存没释放。我记得这道题很多人只写到“用jmap看堆、用MAT分析”就停了但2018年那会儿已经有的大厂考察风格是追问你拿到分析结果之后怎么办。所以答题时一定补上最后一步如果确认是线上业务造成的内存压力临时手段是调大堆内存、降低并发流量长期方案是修代码或者加缓存淘汰策略。笔试不只是考技术也在考你面对生产问题的整条处理链路。3. 运维研发方向的题不是考命令是考“用代码做运维”3.1 Linux与系统管理基础知识的覆盖面运维研发这个岗位在2018年校招里已经被明确地定义为“懂运营、也懂开发”。那年的B卷客观题里Linux相关的内容占了不少但和传统网管考试完全不同——它不考“某个命令的某个参数是什么”而是考“在什么场景下用什么工具、怎么排查”。比如有一道题线上服务CPU使用率飙到99%第一步应该做什么选项里有用top看进程、直接重启服务、看监控报警、登录服务器随便跑命令。正确答案是先用top确认是哪个进程占用了CPU再进一步用top -Hp [pid] 看是哪个线程。很多人第一步就想去重启但运维运维先复现、再恢复、后定位顺序不能乱。重启只能缓一时连根因都不知道下次照样挂。系统管理的题则集中在进程管理、文件系统、权限和日志。有一道题是问Linux下如何安全地清理一个正在被进程写入的日志文件选项有rm、 重定向清空、echo 清空、先停进程再删除。这题其实考的是“rm掉一个被打开的文件时空间不会立刻释放”的经典坑正确做法是先清空文件内容 或者 truncate这样进程还能继续写磁盘空间也释放了。很多人不知道这个细节直到线上日志文件越删越大才明白发生了什么。B卷里也简短考到了systemd。2018年那会儿systemd已经成为绝大多数发行版的默认init系统所以题目里多少会涉及systemctl常用命令、unit文件的基本结构以及和SysV init的区别。这类题属于基础知识但想拿分就得自己在机器上多敲几遍systemctl list-units、systemctl status xxx、journalctl -u xxx不能光看书。3.2 Shell和Python脚本笔试里的编程题运维研发方向的编程题不是让你写一个经典的算法题而是给你一个日常运维场景要你用代码解决。那年的B卷有一道写一个脚本统计Nginx访问日志里访问次数最多的前10个IP要按访问次数降序输出。这题最简单直接的写法是用awk加sort、uniqawk {print $1} access.log | sort | uniq -c | sort -rn | head -10但如果你只写这一行只能说明你会用命令还不足以体现“研发”能力。想拿高分题目里往往还有附加条件比如日志文件很大、几个G甚至几十个G机器内存有限这时候就要考虑能否用流式处理避免把全部数据加载进内存再比如要求把脚本写成可复用的形式支持传入日志路径和输出的IP数量。所以更完整的解法是写成脚本用管道流式处理#!/bin/bash log_file$1 top_n${2:-10} awk {print $1} $log_file | sort | uniq -c | sort -rn | head -n $top_n再进阶一步如果你考虑到日志格式是标准combined格式可以用Python的Counter来做顺便还能做一点容错处理#!/usr/bin/env python3 import sys from collections import Counter def main(log_path, top_n10): counter Counter() with open(log_path, r, errorsignore) as f: for line in f: parts line.split() if parts: counter[parts[0]] 1 for ip, count in counter.most_common(top_n): print(f{count}\t{ip}) if __name__ __main__: main(sys.argv[1], int(sys.argv[2]) if len(sys.argv) 2 else 10)这类题的核心得分点是结果正确、考虑效率、代码可维护。纯一行命令能跑但如果在脚本里加上对参数的处理、对异常日志格式的容错就会比其他人多拿几分。这也就是“运维研发”和“传统运维”的区别——不仅会处理问题还能把处理思路沉淀成自动化的工具。3.3 监控、部署与故障恢复场景题的思考顺序运维方向的简答题基本是给你一个线上故障场景让你写出从报警到恢复的全流程。B卷那道题我记得是某天凌晨监控报警某核心接口的99分位延迟从50ms飙升到2000ms你如何处理这个题看起来很开放但阅卷人心里其实有一套标准的排查顺序。首先要做的事是确认影响面是单机问题还是集群问题是少量请求还是全部请求这决定了你从哪个方向切入。如果是单机问题检查该机器的负载、CPU、内存、磁盘IO看是不是有进程在大量消耗资源如果是集群问题则要往上游排查数据库是不是慢查询变多了、缓存是否大面积失效、下游依赖服务是否超时。其次是恢复手段。如果服务还在响应但延迟很高可以考虑重启部分实例、摘除故障节点先把流量导到健康的机器上如果是数据库慢查询导致可以先杀掉慢SQL、或者临时扩容只读实例。恢复的顺序一定是“先止损、再定位根因、最后优化长期方案”。最后是怎么写进自动化体系。2018年那会儿容器化和Kubernetes虽然已经很热但很多公司的生产环境还是虚拟机部署为主所以笔试卷子里并没有太多K8s的操作题更多是考报警阈值设置、日志聚合、脚本化恢复这套传统思路。但出题人很看重“自动化”的意识——有同学在答案里提到“把排查步骤写成脚本下次自动执行”这点是明显能加分的。4. 数据挖掘方向的题统计、算法、SQL三件套4.1 统计概率题用贝叶斯与假设检验筛人数据挖掘方向的题目和Java、运维完全不同它更像是在考数学功底和逻辑思维。B卷的客观题里数据挖掘岗的选做部分出现了不少统计概率题。比如有一道某疾病在人群中的患病率为0.1%检测试剂的准确率即患病者检出阳性的概率是99%误报率即未患病者检出阳性的概率是1%问一个人检测结果为阳性时真正患病的概率是多少。这不是一个简单的条件概率题标准解法就是贝叶斯公式P(患病|阳性) P(阳性|患病) × P(患病) / P(阳性)其中P(阳性) P(阳性|患病)×P(患病) P(阳性|未患病)×P(未患病) 0.99×0.001 0.01×0.999 0.01098所以P(患病|阳性) 0.99×0.001 / 0.01098 ≈ 0.0901也就是说即便检测结果是阳性真正患病的概率也只有大约9%。这种题目考察的不是你会不会套公式而是有没有“先验概率对后验概率影响极大”的直觉。放到数据挖掘的实际场景里对应的是类别极度不平衡时比如欺诈样本占比万分之几模型预测的正样本里真正是正样本的比例可能低得惊人这就直接决定了你是否要用过采样、下采样或者调整分类阈值。统计题还考过假设检验的基本概念比如p值的含义、第一类错误和第二类错误。这并非为了让你去背定义而是为了筛掉那些把p值当成“H0为真的概率”的人。在推荐、A/B测试、风控这些场景里假设检验是基本功笔试从概念层面就开始了筛选。4.2 从LR到GBDT数据挖掘笔试中的模型题变化2018年校招数据挖掘岗模型相关的题基本围绕逻辑回归LR、决策树、随机森林、GBDT、SVM这几类经典模型展开。深度学习那会儿虽然已经在视觉和NLP领域爆发但校招笔试里主要集中在基础概念层面还不至于让你手推Transformer的结构。有一道题是问在LR模型中为什么要对特征做归一化这个题的标准答法有三个层面第一如果不归一化量纲大的特征会主导梯度下降的方向导致收敛速度变慢第二归一化后特征之间的可比性更强能帮助理解特征重要性第三对正则化L1/L2来说如果不归一化正则项对量纲小的特征惩罚更大这会让模型效果变差。这里最核心的是第一点——梯度下降的收敛性受特征尺度影响因为LR的梯度更新是沿着所有特征的梯度方向同时进行的尺度大的特征梯度也大更新步长被它带着走。还有一道题是关于GBDT和随机森林的区别。出题人希望你能答出随机森林是Bagging的思路训练时各棵树独立并行最后投票或取平均GBDT是Boosting的思路每一棵树拟合前面所有树的负梯度残差树之间是串行依赖的。随机森林更抗过拟合更适合高方差场景GBDT精度通常更高但在特征噪声大、标签噪声大的场景下容易过拟合。这些点虽然基础但也是很多后续面试题的引子。这些题目本身不难但拉开差距的地方在于你是否理解模型背后的计算原理而不只是会调用sklearn。比如问“GBDT里的负梯度为什么可以用损失函数的一阶导数来表达”这类更细的问题作为笔试简答题出现时就要能结合平方损失函数把推导过程写出来。4.3 SQL与特征工程数据挖掘岗的操作题核心数据挖掘的编程题大多是SQL题这很正常因为真正的业务里70%以上的时间都在写SQL取数、做特征。B卷有一道SQL题大概是这样给定一张用户观看记录表user_idroom_idwatch_secondswatch_date一张主播开播表anchor_idstart_timeend_time让你统计每个用户观看时长最长的前3个直播间。这道题用窗口函数 row_number() over (partition by user_id order by watch_seconds desc) 就能解决但关键在于2018年的MySQL主流版本是5.7还没有窗口函数所以很多人只能写复杂的自连接或者变量写法。放到今天窗口函数已经是标配但如果笔试题出得偏早你可能需要展示两种写法。做题之外这道题还延伸出一个特征工程的问题如果让你预测用户次日是否再次来直播平台基于这两张表你会怎么构造特征这个题的答法很多常见的特征方向包括用户维度近7天活跃天数、平均观看时长、观看时长标准差、最喜欢的内容类目直播维度观看时长占直播总时长的比例、是否多次进入同一直播间时间维度最近一次观看距离今天的小时数、是否在工作日晚上观看交互维度关注主播数、送礼次数、弹幕条数这类题的本质是考察“从业务理解到特征抽象”的能力。很多人能写出SQL但让他从SQL结果里想到怎么构造预测特征就卡住了。数据挖掘岗的笔试很大程度上就是在提前筛选“有业务直觉的人”。5. 同一道场景题三个岗位的不同解法5.1 一道经典的场景基础题直播平台开播卡顿B卷最后有一道综合场景题大概描述了一个很常见的问题晚上8点到11点的黄金时段直播平台部分用户反映开播卡顿、首屏加载慢、延迟变高需要你给出你的解决方案。所有方向都要做这道题但出题人期待的是“站在你自己岗位的角度”去回答。这类题从Java开发、运维研发、数据挖掘三个角度去分析答案完全不同这也是当年这套卷子最有意思的地方。接下来分别看。5.2 Java开发视角看的是代码链路与性能瓶颈Java开发同学拿到这道题第一反应应该是拆解开播链路的代码路径。开播到观看可以拆成客户端请求开播接口、服务端鉴权和房间信息获取、拉流地址签发、推流链路转发、CDN边缘节点处理、播放器拉流渲染每一环都有可能是瓶颈。所以回答这道题时要从代码层给出排查方向。比如鉴权接口做了哪些RPC调用是不是存在串行等待房间信息获取走的是缓存还是数据库缓存Key设计是否合理是否存在热点问题的风险比如大主播房间的并发请求集中在同一个缓存Key上拉流地址签发是否依赖外部接口超时时间设置了多少秒熔断降级策略是否生效。更具体的做法是先看这个链路的调用链路追踪Trace日志确认耗时到底花在哪个节点——是服务端处理慢还是CDN回源慢还是客户端自身的DNS解析慢。从Java开发的角度你可以把耗时占比最高的服务接口拿来做性能分析用jstack看线程栈、用JProfiler看热点方法、看是否存在大量的锁竞争、看GC是否在高并发下频繁触发。如果接口本身写得没问题再考虑池化、异步化改造。这道题的本质是考察你能不能把“卡顿”这样一个模糊的现象翻译成具体的技术假设再用数据去验证。5.3 运维研发视角看的是容量、链路与降级预案运维研发同学拿到这道题切入点完全不同。第一反应是看容量和压测数据黄金时段的带宽峰值是多少当前的负载能力是多少有没有过压测记录。如果带宽已经接近上限那就不是代码问题而是需要扩容或切流。从运维角度完整回答这个场景题应该包括以下步骤。第一步看监控确认机房带宽、服务器负载、CDN节点状态、核心服务存活率把“部分用户”定位到具体的地区和ISP。第二步确认是哪个环节的质量问题用拨测工具从多个地区发起拉流请求对比首帧时间、卡顿率、缓冲时长判断问题出在边缘节点还是源站。第三步根据定位结果做应急处理如果是源站出口带宽扛不住立刻扩容或者限流保护如果是某个CDN节点故障把流量切到其他节点如果是网络链路拥塞和运营商协调或调整调度策略。第四步事后复盘把开播推流链路的监控补全设置带宽和延迟的报警阈值。运维视角的加分项是“预案意识”。有同学在答案里写“根据历史直播大事件的峰值提前做带宽扩容和压测演练”这种带有前瞻性的容量规划思路明显比单纯说“故障时重启”高出很多。5.4 数据挖掘视角看的是指标异动与归因分析数据挖掘方向的同学拿到这道题几乎不会去聊服务器和代码而是会先问一个问题你说卡顿怎么定义卡顿这个看似较真的问题恰恰是数据挖掘岗位最核心的能力——把业务问题转换成可量化的指标。回答时可以先定义卡顿相关的指标体系首帧加载时间、播放卡顿率卡顿次数/播放总时长、平均码率、错误率等。然后基于这些指标对比不同维度下的表现房间维度大主播房是否更严重、用户维度不同运营商、不同地区、不同端从中找到“部分用户”对应的具体人群特征。进一步可以用归因分析来做定位把指标和时间、版本、地区和CDN节点关联起来用方差分析或树模型看哪些维度对指标波动影响最大。比如发现卡顿率在某个省份的某个运营商网络下特别高那大概率是网络链路的问题而不是服务端代码的问题。这类分析结论比一连串猜测更能让开发团队快速收敛排查方向。数据挖掘岗的B卷场景题其实是在考你的“数据敏感度”——面对业务问题时能不能快速定义指标、设计数据对比方案、得出结论从而指导业务决策。6. 从B卷反推欢聚时代校招的选拔逻辑与备战建议6.1 笔试考的是“下限”不是“上限”后来我自己参与过校招出题和阅卷回头再看这套B卷最大的感悟是笔试真的不是为了招“天才”而是为了筛掉连基本盘都不扎实的人。笔试题目里客观题占大头但主观题和编程题虽然分值不高反而是阅卷时最重视的部分。出题人的视角是这样的笔试环节不指望你答出多么惊艳的方案而是通过基础题和场景题快速判断你有没有工程师的基本素养——是否了解一个请求从发出到返回经过了哪些环节、线上出问题时是否能系统地排查、是否能把自己的思路用代码或文字清楚地表达出来。很多进入面试的同学笔试总分并不高但场景题答得很有条理说明阅卷人在乎的不是你死记了多少八股而是你有没有“做事的思路”。所以准备校招笔试时别只盯着刷题数量要反复练“输出逻辑”拿到一个模糊的问题场景你能不能分步骤、有优先级地说出处理方案。这套B卷里的Java并发题、运维故障题、数据挖掘归因题本质上都是同一个考察点——面对未知问题时的思考框架。6.2 三个方向的备考清单照着查缺补漏就行如果现在有人要准备互联网公司的校招笔试哪怕不是欢聚时代也可以拿这份B卷的考点当清单来用Java方向必背集合类的源码结构HashMap、ConcurrentHashMap、JVM内存模型和GC算法、并发包核心工具synchronized、ReentrantLock、ThreadPoolExecutor、volatile、JVM调优常用命令jstat、jmap、jstack。编程题方面LeetCode按“链表、二叉树、动态规划、字符串”这几个tag刷够100道基本能覆盖笔试题难度。运维研发方向必背Linux常用命令top、ps、netstat、lsof、grep、awk、sed、systemd的基本使用、shell脚本编写日志统计、进程监控、批量部署、Python处理文本的常见写法、监控体系的基本概念指标、告警、日志、故障排查的完整链路。如果有余力学一点容器和Kubernetes的基本操作2018年以后几乎每一场笔试都会带上一两道。数据挖掘方向必背概率论核心知识点条件概率、贝叶斯公式、期望、方差、常见分布正态分布、二项分布、泊松分布、假设检验基础、经典机器学习模型LR、决策树、随机森林、GBDT、SVM的推导和对比、SQL窗口函数和数据操作、特征工程的基本思路。如果笔试包含Python编程pandas和sklearn的两行API调用要特别熟练。6.3 几个当年很多人踩过的笔试现场坑最后聊点具体的考场经验。第一时间分配一定要提前定好。很多人一上来就死磕单选题结果三道编程题留了不到40分钟最后写完一道就开始慌。我的做法是先花60秒扫一遍整张卷子把编程题和场景题的难度做个判断然后先做有把握的编程题哪怕只写核心逻辑再做客观题最后回头补难题。笔试不是高考不要求按序号作答把能拿的分都拿住更重要。第二编程题不要只写代码一定要写注释和思路。阅卷人一天看几百份卷子一份满是代码没有一行说明的答案很难让他在几分钟内看懂你的思路。哪怕代码没有完全跑通只要核心思路写在注释里比如“这里用动态规划状态转移方程是dp[i]max(dp[i-1]nums[i], nums[i])”阅卷人都可能给你步骤分。第三场景题不要慌。遇到没听说过的技术栈、没见过的故障现象千万别空着。阅卷人想看到的是你“从现象到假设再到验证”的思考过程就算假设不对只要逻辑自洽、步骤严谨也能拿一半以上的分。我从自己阅卷的体验来说一份卷子上来就说“重启服务就好了”的答案给不了多少分但完整走完“确认影响面、查看监控、登录定位、隔离恢复、记录复盘”流程的考生哪怕结论偏了都愿意给高分。说到底校招笔试是一场“基础能力的大扫除”。这套2018年的B卷之所以到今天还有参考价值是因为它考察的那些东西——底层原理、代码功底、排查思路、业务理解——都是工程师长期吃饭的本事。把一套这样的真题吃透远比刷十套答案要值。如果你现在正在备笔试题建议把卷子里考察的每个考点都当成一个“知识入口”顺藤摸瓜把背后的原理和场景都过一遍笔试只是第一步面试还会往深了问。