触宝科技2017秋季校招笔试后端大数据第三批看到这个题目我愣了一下一是因为这确实是一份有年头的题了二是因为“第三批”这三个字本身就带了不少故事。我当年参加的是第一批后来帮部门做过几次校招笔试题的评审也陆陆续续听学弟学妹们聊过后面的批次。说实话触宝这套后端大数据方向笔试题在当年的移动互联网校招里算是很有代表性的不炫技、不偏门但覆盖面很扎实能把“真会”和“背过”区分得很清楚。即使放到现在这套题背后的考察逻辑依然没有过时。这篇东西我打算换个角度来写不单纯做一份“答案解析”而是把这套题拆开揉碎讲清楚每一类题目到底在考什么、出题人想看到什么样的答案、以及你该怎么准备才能不翻车。不管你是正在准备校招的应届生还是想转后端/大数据方向但心里没底的同学都可以把这篇当成一份来自“经历过的人”的笔试复盘笔记来看。1. 这套笔试题为什么值得复盘1.1 触宝的背景与考察逻辑先说触宝这家公司。2017年的触宝靠触宝输入法和触宝电话两款产品在海外市场站稳了脚跟用户量早就过亿了。这就决定了它的技术团队在做的事情不可能是“玩具级”的——输入法要做词库、要做用户输入习惯分析工具类产品要做用户增长、要做推送和内容分发。这些东西落到后端和大数据方向上就是海量日志处理、实时数据管道、用户画像、A/B实验平台这一类活。所以你看它校招笔试的出题思路基本是照着“来了就能干活”的标准来的不考脑筋急转弯考的是你日常开发和大数据组件使用中最核心的那层东西。为什么说“第三批”也有讲究秋招笔试分批次节奏越往后情况越微妙。第一批通常题量正常、范围稳定到第三批的时候出题人往往会根据前两批的答题情况做微调——比如某些题正确率出奇地低后面批次可能会换个角度再考一次某些题大家都背过答案就会换个场景让你现场推演。所以复盘这份题你要关注的不光是题目本身还有这种“动态调整”背后的信号基础不牢靠靠临时背题是撑不过去的。1.2 后端大数据方向的能力模型我当时给团队写校招笔试题的时候内部有个不成文的共识后端方向考“三件套”——语言基础、算法数据结构、系统设计思维大数据方向再多加“两件”——分布式计算框架的理解、海量数据场景下的解题嗅觉。触宝这份题基本就是按这个模型来的。语言基础以Java为主毕竟后端主力栈就是Java算法题看你能不能写出健壮且高效的代码大数据专项题直接上Hadoop/Spark那一套考你对MapReduce和RDD的理解是“用过”还是“真懂”最后再来一道开放设计题看你面对一个海量数据的业务问题时能不能把思路理清楚。这套组合拳打下来一个人是背题选手还是实战选手基本藏不住。2. 笔试核心题型拆解与作答思路2.1 基础与原理题别在送分题上翻车这类题通常以选择题和简答题的形式出现覆盖Java集合、并发、JVM、网络协议、数据库这几个板块。真题里有一道很典型的HashMap在JDK 7和JDK 8之间有哪些变化为什么这题看着基础实际上能拉开差距。只说“JDK 8引入了红黑树”只能拿一半分。你要能说清楚JDK 7是数组链表头插法扩容时多线程可能产生环JDK 8改成尾插法链表长度超过8且数组长度大于64时转红黑树为什么阈值取8——因为泊松分布下链表长度达到8的概率极低是时间和空间的平衡点。再往深处说你还可以提为什么红黑树而不是AVL树因为红黑树的插入删除旋转次数更少更适合写多读少的Hash表场景。另一类高频考点是并发。比如线程池的核心参数corePoolSize、maximumPoolSize、workQueue、keepAliveTime、handler这五个参数之间的关系必须张口就来。再往深一点submit和execute有什么区别前者返回Future可以拿到执行结果和异常后者丢进去就不管了异常会被线程池吞掉。这些细节笔试不一定会考但面试一定会追问。我建议准备这类题目的时候别只背结论多问自己一个“为什么”。比如HashMap为什么加载因子默认0.75因为这是空间利用率和查询时间的一个经验最优值太高容易增加碰撞太低浪费空间。你把这一层想明白了考场上面对任何变形题都能接住。2.2 算法与数据结构题白板代码的得分点触宝这套笔试题的算法题不刁钻但很考基本功。我印象比较深的有几类第一类是Top K问题。给你一个10亿条日志的文件每行是一个URL统计出现次数最多的前100个URL。这题几乎是大数据方向必考但它考的不是你说“用MapReduce”就完事了而是你知不知道单机内存放不下时该怎么拆先用哈希分片比如hash(URL) % 1000把大文件拆成1000个小文件保证同一个URL一定落在同一个文件里然后每个文件内用HashMap统计次数、用小顶堆取Top100最后归并1000个文件的Top100。这里小顶堆是关键——求最大的K个元素用容量为K的小顶堆堆顶是当前第K大的数新元素比堆顶大就替换并调整堆。第二类是手写数据结构的变体。比如实现一个LRU缓存要求get和put都是O(1)复杂度。正确的姿势是HashMap双向链表HashMap负责O(1)查找双向链表负责维护访问顺序。很多同学一上来就写LinkedHashMap也能过但如果你能解释清楚LinkedHashMap底层就是HashMap双向链表并把accessOrder这个参数讲明白分数会更高。第三类是经典的链表和字符串题。链表环检测快慢指针、反转链表迭代和递归两种写法都要会、最长回文子串中心扩展或者Manacher至少会一种。这里有个血泪教训笔试环境里的代码编辑器和LeetCode不一样没有自动补全没有语法高亮甚至连缩进都要靠手动。所以平时练习的时候建议直接在文本编辑器里白板写代码训练“一次写对”的能力。这类题的得分点不只是“写出来”还包括边界条件是否处理到位。比如链表反转你要考虑空链表和单节点快排你要考虑数组已经有序的情况递归深度会退化成O(n)。这些在代码里有没有体现阅卷人一眼就能看出来。2.3 大数据专项从Hadoop到Spark的考察层次大数据方向的专业题是这套笔试的重头戏。2017年那会儿Spark已经火起来了但Hadoop的地位依然稳固所以两份都会考。真题里有一道很经典的描述一下HDFS写文件的全流程。标准回答分四步客户端向NameNode发起写请求NameNode检查权限和目录并返回可用的DataNode列表客户端把文件切分成block默认128MB2017年触宝这批题的时候还是64MB/128MB并行按顺序写入第一个DataNode第一个DataNode通过管道方式把数据复制给第二个、第三个DataNode每写一个块就返回确认全部写完客户端关闭输出流NameNode提交元数据。这题光背流程不够你得知道每一步背后的设计意图。比如为什么副本是3个默认2个存本机架1个存其他机架这是机架感知策略——兼顾容错和写入带宽。为什么用管道复制而不是主节点分发因为数据是流式的管道传递可以边接收边转发避免NameNode成为瓶颈。你把这几层“为什么”答出来阅卷人就知道你是真跑过集群、真看过源码的。Shuffle过程也是必考。MapReduce的Shuffle包括Map端分区、排序、溢写、合并以及Reduce端拉取、合并、归并排序。Spark里的Shuffle在1.6之后引入了Sort-based Shuffle把同一个Maper输出的多个分区文件合并成一个文件加索引文件大大减少了文件数量。这个演进过程要能讲清楚因为后面有一个高频追问Spark为什么比MapReduce快标准答案就是那三点内存计算中间结果不落盘、DAG调度减少Stage数量和落盘次数、基于Executor的多线程模型进程内多个线程跑task。但我要提醒你这三个点每个都能深挖。比如内存计算Spark真的所有中间结果都在内存吗不是shuffle的中间文件还是要落盘的但Spark可以尽量复用内存里的RDD。你把这层想清楚才不会在面试官追问的时候卡壳。数据倾斜也是大数据方向的“老朋友”。笔试里最常见的问法是做Join的时候发现某个Key的数据量特别大导致Reducer卡了很久你怎么解决回答分三步先定位是哪些Key倾斜——可以从日志里看最后一个Stage的task处理数据量再分情况处理——如果是空值或脏数据导致可以在Key上拼接随机数打散如果是热门Key可以拆分成“大Key单独处理其余正常Join”两步最后治本——从业务上分析为什么会有这个热点Key比如某个商家的订单量特别大那就要考虑用广播变量或者更合理的业务设计从根本上解决。2.4 开放设计与场景题不追求标准答案追求思路这套卷子最后通常有一道大设计题。真题大概意思是假设你是触宝输入法的大数据工程师需要统计全球用户的输入热词Top排行榜要求延迟不超过10分钟数据量你自己估计你会怎么设计这种题没有标准答案但得分点是明摆着的你愿不愿意自己把数据量估出来你知不知道Lambda架构和Kappa架构的区别你会不会用消息队列Kafka Streams/Spark Streaming这套组合拳。先说数据量估算。触宝输入法月活几亿假设每天有20%的用户产生输入行为每人每天输入100个词那就是几亿 × 20% × 100 每天十几亿条词频记录。每秒大约一万多到几万条写入这个量级对Kafka来说毫无压力。但你得说这步因为阅卷人想看你有没有“数量级感”。再说架构。2007年那会儿主流设计是并发两条链路一条实时链路走Kafka → Spark Streaming → Redis算近实时的分钟级Top榜一条离线链路走Kafka/HDFS → Hive/MapReduce → MySQL/HBase算精确的日级Top榜。两条链路结果合并实时榜先展示离线榜后修正。这就是典型的Lambda架构虽然现在看起来过时但它的思想——批量层、速度层、服务层三层分离——依然是很多公司数据架构的雏形。最后说细节。Redis里Top榜用什么数据结构ZSET成员是热词分数是热度值用ZREVRANGE取前N个复杂度O(logNM)完全能抗住这个量级的读请求。Kafka的Topic分区数怎么设建议和下游消费者的并行度保持一致通常是分区数等于消费者线程数这样能最大程度发挥并行消费能力。这些细节堆上去答案的含金量立刻就不一样了。3. 从复习到答题的完整实操流程3.1 考前准备资料、环境、时间分配我的个人经验是校招笔试复习不能拉长战线三到四周是黄金窗口再长容易疲惫再短基础不牢。前两周主攻基础题和算法题第三周主攻大数据专项和设计题最后一周专门做整套模拟卷找感觉。复习资料别贪多。Java基础看《Java编程思想》重点章节和《Java并发编程的艺术》算法刷《剑指Offer》加LeetCode热题100大数据看《Hadoop权威指南》的核心章节和Spark官方文档里的编程指南就够了。触宝这套题当年的难度和这些资料是匹配的——不会超出这个范围考偏门。环境准备也是个大坑。很多同学笔试前不看通知考试当天才发现公司用的在线笔试系统对浏览器有要求或者需要提前装插件。我的建议是提前一天把笔试邀请邮件里所有链接都点一遍测试摄像头、麦克风、编译器环境甚至提前十分钟进考场试一下网络。触宝当年用的在线笔试系统支持在线编译但不支持IDE级别的调试你要习惯在浏览器里写代码的感觉。时间分配上我的原则是选择题和简答题控制在总时长的30%算法题控制在40%大数据和设计题控制在30%。为什么这么分选择题虽然分值小但性价比高要保证拿到手算法题是区分度最大的宁可多花时间调通一个边界条件也不要为了赶时间交半成品设计题写到要点上就拿分不需要长篇大论但一定要把架构图画清楚、把关键组件标出来。3.2 答题策略三轮答题法与时间控制我管自己的答题节奏叫“三轮答题法”。第一轮把所有会做的题快速过一遍不纠结先把分拿住第二轮集中攻克第一轮卡壳的题目这时候心态比较稳思维也热起来了第三轮专门检查边界条件和代码细节这是最容易白捡分的地方。时间控制上缺一个原则每道题卡一个心理时间上限。比如一道算法题如果15分钟没思路先跳过去做后面的最后再回来啃。笔试环境里最忌讳的是在一道题上死磕——你花40分钟好不容易写出来了结果发现后面两道大题每道只剩10分钟那才是真的崩盘。代码题还有一个容易被忽略的点先在草稿纸上写伪代码理清思路再往答题框里敲。在线笔试系统不允许反复复制粘贴调试你如果直接上手写代码很容易写着写着发现逻辑乱了然后整段删掉重来时间就这么浪费了。伪代码不一定规范但能帮你把“主流程 → 分支 → 边界”三步想清楚再翻译成代码就快多了。3.3 代码提交与细节纪律笔试代码题最容易丢分的不是不会写而是写了但没写对。我列几个容易被扣分的细节变量命名要见名知意。笔试系统的阅卷不一定靠机器跑测试用例很多是人工看代码。一个叫map1的变量和一个叫urlCountMap的变量给人的感觉完全是两个档次。这个细节不用花时间但特别加印象分。不要忽略异常分支。比如Top K的代码第二参数k大于数组长度时怎么处理要不要抛出异常还是返回整个数组你写清楚阅卷人就知道你对边界有认知而不是只会“背模板”。注释写一到两行就够。写清这段代码的思路即可不要逐行注释那样会显得你不自信也让代码页显得很乱。我见过有同学把“// 遍历数组”这种废话注释写满一屏的反而影响阅读。提交前必须检查的几件事头文件/import是否齐全main函数入口是否写对循环有没有死循环风险集合是不是初始化了这些低级错误在笔试里出现的频率远比你想的高每次检查都可能白捞一个测试用例的分数。4. 现场高频问题与避坑技巧4.1 原理题中的“想当然”这类题的主要失分点在于“背了概念但没理解概念背后的限定条件”。举个例子ConcurrentHashMap是线程安全的吗大多数同学能答“是”但深问一句“它的size()方法是线程安全的吗”就会卡住。在JDK 8中size()是CAS加锁、失败后遍历各segment累加所以不是严格意义上的强一致——它返回的是一个近似值。这种细节恰恰是笔试题喜欢埋坑的地方。再比如JVM的老年代和新生代。很多人只知道比例是2:1:1但不清楚这个比例是动态的新生代每次GC后存活对象大小会触发阈值动态调整-XX:TargetSurvivorRatio。笔试如果考到“Java对象一定在新生代分配吗”答案是“不一定”——如果一个对象特别大超过新生代空间可以直接在老年代分配。这种想当然的陷阱你在复习的时候就要有意识地去积累。我的建议是每复习一个知识点都强制自己回答三个问题——“它解决了什么问题”“它的关键流程是什么”“它的局限性是什么”把这三点写在笔记上考前过一遍这个清单比盲目刷题管用得多。4.2 算法题中的边界与性能算法题的坑集中在两个层面一个是功能正确性一个是复杂度。功能正确性最常见的坑是数组越界和空指针。比如二分查找里high mid - 1和low mid 1的细节写快了很容易把mid加减搞错导致死循环。我的建议是写完代码后自己手动模拟一遍“空输入、单元素、目标在开头、目标在结尾、目标不存在”这五种情况基本能覆盖90%的边界bug。另一个是性能陷阱。Top K用排序解当然是正确的但你如果写Arrays.sort(nums); return nums[n-k]在n很大的时候性能就差很多了而且面试官能一眼看出你没理解“海量数据”这个场景。考场上看到“海量”“亿级”“日志”这些关键词思路默认往堆、哈希分片、位图这些方向走而不是无脑排序。我还有一个独门习惯写算法题的时候顺便算一下时间和空间复杂度然后写在注释里。这一方面能帮你自查是否满足题目要求另一方面也是素质展示——阅卷人看到你写了复杂度分析好感度直接上一个台阶。4.3 大数据题的常见失分点大数据题最大的失分点不是技术不懂而是“名词党”——把概念背得滚瓜烂熟但回答没有任何细节支撑。比如让你讲Spark任务提交过程只回答“提交到YARN上运行”就得不了几分。你要能说清楚SparkSubmit把ApplicationMaster提交给ResourceManagerResourceManager在某个NodeManager上启动AMAM向RM申请Container然后启动Executor最后AM把Task分发给Executor执行。每一步都说到组件名字这就不是“名词党”了而是“干活的人”。第二个失分点是不估数据量。很多设计题你不先估算数据规模就直接画架构会被阅卷人认为“实际经验不足”。哪怕你的估算不准确也没关系重要的是“我做过数量级分析我的方案是匹配这个量级的”。笔试阅卷人也是这么想的——他不指望你方案完美但希望你心里有数。第三个失分点是方案极端化。要么光谈实时不管准确性要么只做离线完全忽略实时性。正确的姿势是承认实时和离线各有优劣然后给出一个混合方案明确每个场景走哪条链路。这种分层思维恰恰是后端大数据工程师日常最需要的素质。4.4 环境与网络突发情况这几年在线笔试越来越普及环境问题出现的概率比技术问题还高。我遇到过的真实案例有键盘切到中文输入法导致代码里出现全角符号编译不过浏览器弹窗插件把答题框遮了一半考试到一半家里断电。这些问题看着戏谑但每年都有人栽在上面。我的建议是提前做好应急预案。笔试前检查输入法切换快捷键最好直接用英文输入法关闭所有弹窗拦截插件和消息通知提前跟室友或家人打好招呼考试期间别打扰。如果真遇到突发情况不要慌第一时间联系技术支持和HR说明情况。大部分公司对笔试异常都有补考机制但这需要你在考场当场反馈而不是事后发邮件。还有一个容易被忽略的点多设备准备。有条件的话备一台手机开热点万一家庭宽带断了秒切热点续上。笔试系统通常不会因为你断网几十秒就判定作弊但如果你直接断线退出就很麻烦了。5. 回看这份题对今天准备校招的几点建议说实话2017年到现在技术栈已经变了不少。那会儿Spark Streaming是主流现在Flink已经是实时计算的事实标准那会儿Hive还是离线数仓的主角现在很多新团队直接上Iceberg、Paimon甚至数据湖。但这套题背后的考察逻辑在我看来反而越来越重要基础扎不扎实、原理通不通透、面对海量数据有没有直觉这些能力不会因为框架的迭代而过时。如果你正在准备后端大数据的校招我给一个具体建议别急着追新框架先把“一条数据从客户端产生到最终报表展示”的完整链路走一遍。这条链路上每一步涉及什么组件、什么数据结构、什么网络协议、什么一致性保证你把它讲清楚了任何一场笔试面试你都稳得住。触宝这套题当年能让我记到现在就是因为它踩中的正是这条链路上的关键节点。最后说点题外的。校招笔试只是第一关它能筛掉“不会的”但不能证明你“一定行”。真正决定你拿不拿得到offer的是面试里那几轮实打实的交流——问你项目难点追问你技术选型的理由看你面对一个模糊问题时的思考方式。所以准备笔试的时候带着一种“我在为面试打基础”的心态去学别只盯着分数。这样等你进入面试环节你会发现很多问题其实早就在笔试复盘时想通过一遍了。祝所有正在准备的你笔试题题会写offer拿到手软。