2023年秋招那阵子我在投递大数据开发岗位的过程中专门挑了掌阅科技来试水。一方面是因为掌阅作为老牌数字阅读平台技术栈在互联网公司里属于比较主流和规范的Java 大数据生态这套组合在秋招里复用性很高另一方面也是想通过一场真实的笔试检验一下自己刷了三个月的准备到底能拿多少分。整个笔试走下来我的第一感受是题目不算偏门但覆盖面积非常大从数据结构到Java并发从SQL窗口函数到Spark调优全都有涉及如果不提前做些准备很容易在某道题上卡住然后整场节奏全乱。这篇文章我按“题型拆解 → 考点复盘 → 真题还原 → 避坑指南 → 备战建议”的顺序来写尽量还原当时笔试的真实状态也把我在准备过程中踩过的坑和总结出来的经验一起放出来。不管你是准备投掌阅还是准备投其他互联网公司的大数据岗这份复盘应该都能帮你解决“到底该复习什么”这个问题。1. 笔试整体情况与题型分布先说这场笔试的形式。掌阅秋招大数据岗的笔试一般是线上进行整套题放在牛客网平台上完成时长大概90分钟到120分钟具体时间根据批次不同会有些差异我当时经历的是90分钟的场次。整体题型分三块单选题、多选题、编程题其中多选是倒扣分制的少选和错选都会扣分这个在开考前一定要看清楚规则我当时因为没细读规则在多选题上就吃了亏。从分值占比来看选择题大概占了60%左右编程题占40%。选择题里又分成几个固定的模块Java基础、数据结构与算法、大数据组件原理、数据库SQL。Java基础在这套题里占比最高大概有30%左右可以看得出来掌阅的技术栈确实是偏Java的这也和很多互联网公司大数据开发岗的现状一致大数据组件部分主要集中在Hadoop、Spark、Flink、Kafka这四个组件上Hive和HBase的题目也出现了但比例相对少一些。有一点值得提的是掌阅这套笔试题没有出现我当时最担心的Linux命令题也没有让我直接在线上写MapReduce代码整体更偏向“原理理解 场景应用”的考察思路。这意味着它考察的不是你会背多少命令而是你是否真正理解这些组件在真实业务链路中是怎么配合的。比如有一道题就给出了一个阅读平台的埋点日志统计场景让你判断整套链路中哪个环节会造成数据重复或丢失这种题如果只懂概念没有做过实际项目是很难答好的。我记得考题的顺序是单选、多选、编程题但并不是从易到难排列的。选择题里面Java集合相关的题偏简单大数据组件的多选题偏难编程题有两道一道是纯数据结构算法题另一道是场景型SQL题。时间分配上我个人的建议是选择题控制在50分钟以内给编程题留40分钟以上因为编程题不仅要写对还需要跑通测试用例留足时间才能从容调试。2. 核心考点深度拆解2.1 算法与数据结构高频题目一定要做到“闭眼能写”掌阅这场笔试的算法题难度处于中等水平不涉及特别复杂的动态规划或图论但高频数据结构的考察非常集中。我在开考前刷了近两个月的LeetCode热门题其中“LRU缓存”“最大子数组和”“二叉树层序遍历”“反转链表”这几个题目在笔试中直接或间接地出现了所以算法的准备方向不算偏。笔试中有一道编程题是“LRU缓存机制”要求实现一个基于最近最少使用策略的缓存类支持get和put操作并且要求在O(1)时间复杂度内完成。这道题的解题思路非常明确用HashMap存储键和对应链表节点的映射再用双向链表维护数据的使用顺序。每次get时如果命中就把该节点移动到链表头部每次put时如果缓存满了就淘汰链表尾部节点。关键是细节处理比如节点在移动时要处理好prev和next指针这一段如果平时没有手写过很容易出bug。还有一道算法题是“最大子数组和”这是一道经典的动态规划入门题思路是在遍历数组时维护两个变量当前子数组和cur以及全局最大和max。cur的递推公式是Math.max(cur nums[i], nums[i])意思是要么把当前元素加入之前的子数组要么以当前元素作为新的子数组起点。这道题虽然简单但笔试里我还是看到有人在边界条件上翻车比如数组长度为0或全部元素为负数的情况所以在准备的时候一定要把边界测试覆盖全面。对于算法题的准备我的建议是不要盲目追求刷题数量。每天精选10道高频题把解题思路总结成自己的模板比一天刷100道但什么也没记住要有效得多。特别是像“滑动窗口”“快慢指针”“二分边界”“链表翻转”这一类套路明显的题目只要理解了套路换个包装也能一眼看穿。2.2 Java基础与并发大数据开发不能只会调API掌阅笔试的Java基础部分考察得非常细集合源码、JVM内存模型、并发关键字、线程池都有涉及。从这些题目能看出来出题人希望招进来的大数据开发不仅会用Spark和Flink还得有扎实的Java功底因为很多组件的底层原理和应用调优都离不开Java知识。其中“volatile关键字的作用”“synchronized和ReentrantLock的区别”“线程池的核心参数和执行流程”这几个概念几乎每次笔试都会出现。我当时遇到的一道多选就是关于线程池的一个线程池的corePoolSize为2、maximumPoolSize为5、阻塞队列为有界队列且容量为3当提交第9个任务时会触发什么逻辑。这类题的关键是理解线程池的工作流程先判断核心线程数是否满未满则创建线程执行已满则放入阻塞队列队列也满了再判断是否达到最大线程数未达到则创建临时线程都满了就执行拒绝策略。这个问题如果再深挖一层还会涉及到饱和策略的选择比如AbortPolicy是直接抛异常CallerRunsPolicy是由调用线程执行任务在实际生产环境中这两者的选择会影响系统的容错表现。HashMap的并发问题也是Java基础里的重头戏。笔试中问到了“JDK 1.7中HashMap在多线程环境下put可能导致的问题”这其实是一个臭名昭著的面试题答案是在扩容时可能形成环形链表导致get操作出现死循环。JDK 1.8改成了尾插法解决了环形链表的死循环问题但多线程下put导致的覆盖丢失依然存在所以并发场景下该用ConcurrentHashMap还是得用。想要深入理解这个问题建议自己去读一下源码中resize()方法把转移节点的过程画一遍印象会深很多。在JVM这块笔试里出现了“类加载过程的顺序”“堆内存中对象的分配流程”“GC Roots有哪些”这几个点。最典型的一道题是给出一个类让你判断类加载的五个阶段顺序加载、验证、准备、解析、初始化。这一题很多人会漏主要是把“准备”和“初始化”搞混准备工作是给静态变量分配内存并设置默认零值而初始化阶段才执行静态代码块和给静态变量赋真正的初值。这个区分在笔试里是高频考点在面试里也经常被追问。2.3 SQL与数据分析题窗口函数是必考点大数据岗的笔试里SQL题基本是必有的掌阅这套题也不例外。而且它的SQL题不是单纯考你写select而是结合了业务场景比如统计某本书的阅读人数、计算用户的连续阅读天数、分析书籍的留存率等等这些都和掌阅自身的数字阅读业务紧密相关。我印象最深的一道题是“给定一张用户阅读记录表user_read_log字段包括user_id、book_id、read_date去重计算每本书近7天的阅读人数”。这道题乍一看很简单直接用SELECT book_id, COUNT(DISTINCT user_id) GROUP BY book_id就行了但加上“近7天”这个条件后很多人在日期的筛选上就写错了。正确的写法是用DATEDIFF(CURDATE(), read_date) 7或者用WHERE read_date DATE_SUB(CURDATE(), INTERVAL 7 DAY)但关键是如果你要按每本书分别算“近7天”就要结合窗口函数或者子查询来动态处理。还有一道题也很有代表性统计2023年每个月的新增阅读用户数也就是说在当月第一次产生阅读行为的用户。这道题的思路是先找出每个用户最早产生阅读记录的月份然后按月汇总。SQL可以写成SELECT first_month, COUNT(*) AS new_user_cnt FROM ( SELECT user_id, DATE_FORMAT(MIN(read_date), %Y-%m) AS first_month FROM user_read_log GROUP BY user_id ) t GROUP BY first_month ORDER BY first_month;这个过程本质上就是“每个用户取最早行为时间再聚合成月度新增”掌握了这个思路类似的新增用户、留存用户、活跃用户统计都可以举一反三。SQL题的准备我最推荐把窗口函数的常用场景都过一遍比如ROW_NUMBER()、RANK()、DENSE_RANK()的区别SUM() OVER()、LAG()、LEAD()的使用场景以及用窗口函数实现分组TopN。因为在实际大数据开发的工作中你会经常用Hive或Spark SQL去写这些逻辑笔试考的是同样的思维。如果只是会用MySQL的基础聚合函数遇到窗口函数的题就会很吃亏。2.4 大数据组件原理背完原理还不够还要能画链路大数据组件这部分掌阅笔试涉及了Hadoop、Spark、Flink、Kafka四个生态组件的核心机制。题型以单选和多选为主难度层级大概是知道组件是什么得一半分能讲清楚原理流程才能拿全分能结合业务场景判断问题才能拿满分。先说说Hadoop常见的考点。HDFS的读写流程是必考题写流程大概是客户端向NameNode发起请求NameNode返回可用的DataNode列表客户端将文件分块并依次写入这些DataNode同时DataNode之间进行副本复制。这里有三个值得注意的细节一是块的大小默认是128MB为什么不是1MB或1GB因为块太小会导致NameNode元数据过多、寻址开销变大块太大又会降低Map任务并行度二是副本放置策略默认是第一个副本放在客户端所在节点第二个副本放在不同机架的节点第三个副本放在与第二个相同机架的不同节点这样兼顾了可靠性和写入性能三是在读数据时客户端会优先读取本地机架的副本减少网络传输。这几个细节笔试里都可能挖成多选题只记大流程不带细节容易中招。MapReduce的Shuffle机制也是高频考点尤其是“环形缓冲区的默认大小是100MB达到80%时开始溢写”这个参数笔试里直接考过。Shuffle整个过程可以拆成Map端和Reduce端Map端包括分区、排序、溢写、合并Reduce端包括拉取、合并归并、分组。很多人忽略的是Map端溢写之前会先进行一次快速排序而Combine操作是在排序之后执行的这两者的顺序搞反的话一些优化逻辑就解释不通了。Spark部分的核心考点是宽依赖和窄依赖的区别以及Spark运行架构。窄依赖是指父RDD的每个分区最多被子RDD的一个分区使用比如map、filter、union这类操作宽依赖是指父RDD的每个分区可能被子RDD的多个分区使用典型的就是groupByKey、reduceByKey、join这类会产生Shuffle的操作。判断宽窄依赖的意义在于窄依赖可以直接在同一个Executor上完成pipeline计算失败恢复代价低宽依赖会产生Shuffle要考虑数据倾斜和网络开销。还有一道关于Spark任务提交流程的题也很有代表性从提交jar包开始依次经过Driver构建SparkContext、注册Application、DAG调度器将RDD依赖图切割成Stage、TaskScheduler将任务分发到Executor执行。这里的核心是Stage的切割规则它是根据宽依赖来划分的遇到宽依赖就切分成新的Stage这个规则我建议一定要熟练掌握。Flink的考点主要是checkpoint机制和一致性语义。checkpoint的原理可以理解为JobManager定期向Source算子注入BarrierBarrier像水坝一样在算子链上流动当每个算子接收到所有输入Channel的Barrier后就将当前状态进行快照最后统计快照完成情况完成一次checkpoint。这个机制保证了在故障恢复时可以从最近一次完成的checkpoint恢复状态做到精确一次或至少一次处理。笔试里常见的陷阱是问你“checkpoint和savepoint的区别”这两者的核心区别在于checkpoint偏向于自动化的故障恢复而savepoint是手动触发的更偏向于运维升级或扩容时的状态迁移。Kafka这边ISR机制和消费者组的Rebalance是最容易出多选题的地方。ISR是“同步副本”的集合选举新的Leader时会优先从ISR中选只有ISR中所有副本都同步了某条消息该消息才能被消费者可见这保证了消息不丢失但也会带来一定延迟。消费者组的Rebalance则是在消费者数量、分区数量、订阅关系发生变化时触发常见的分配策略有Range和RoundRobin。2023年新出的说明里消费者组的Rebalance机制也在不断优化比如静态成员可以避免频繁Rebalance。2.5 场景设计与系统链路题拉开差距的关键掌阅这套笔试题里真正拉开差距的其实是大数据组件和大数据架构的选择题组合它们往往作为综合场景题出现。其中一个我必须细说的题目就是关于“基于大语言模型的云盘非结构化数据理解与内容生成方法”的应用场景热搜词里其实也出现过这个概念可见掌阅的笔试题目设计是紧跟技术潮流的。它讲的是在一个云盘系统中存在大量非结构化的文档、音视频、图片传统的关键词检索无法理解这些文件的内容因此引入大语言模型对文件内容进行语义理解提取关键信息并生成结构化标签再将这些标签送入检索引擎。这个场景正是大数据开发岗未来几年非常重要的工作方向之一。在这道场景题里出题人给出的链路是非结构化文件存储于云盘 → 通过消息队列触发一份大模型推理任务 → 推理结果写入结构化存储 → 再由检索系统根据这些结构化标签实现语义检索。问题是当瞬时并发提升时哪个环节最容易成为瓶颈。这个场景其实考察的就是你对整个链路数据处理能力的判断。我当时分析的结果是大模型推理环节是最容易出问题的。因为基于大语言模型的内容理解是计算密集型操作推理时延远高于普通的文本处理而且它要读取云盘中的原始文件也面临IO和带宽问题。如果你想优化这个链路常用的方案是在消息队列到大模型推理之间加上异步任务队列和限流熔断机制避免高并发时将推理服务打垮。同时推理结果写入结构化存储这个环节也需要考虑幂等性设计因为消息队列天然是at least once语义重复消费会导致重复写入。为了避免脏数据可以给每条推理任务生成一个全局唯一ID在写入时按这个ID去重。这个场景题很典型地反映出了当前大数据行业的一个发展趋势大数据开发不能只停留在“统计计数”的层面要开始和AI、大模型做结合。如果你在笔试中能够展现出对这条链路的理解和优化思路会比死记硬背组件概念更容易得到高分。3. 实操过程与真题复盘3.1 笔试现场时间分配与答题节奏按照笔试流程我进入考试系统后有几分钟的时间阅读考试须知。提醒一下这段“考试须知”一定要认真看它会明确告诉你每个题型的判分规则。我记得掌阅这套题的多选题是“少选得部分分、错选不得分”这就意味着你不确定的选项宁可不选也不要乱选。这是一个非常关键的策略当时我有个朋友就是因为多选题全选了结果错两道直接倒扣了很多分。我大致的时间分配是这样的单选20分钟多选20分钟编程题50分钟。前面选择题里有一部分Java集合和SQL的题比较简单我基本是一扫而过到了大数据的多选题我会在草稿纸上把每个选项的流程画一遍再选比如Shuffle流程、Flink的Barrier传播流程画完逻辑图再判断可以避免很多因记忆模糊导致的错误。编程题第一道是“最大子数组和”我用了大概5分钟就写完了并且跑通了示例。第二道是“根据给定表结构计算每个用户的连续登录天数”这道题我花了30多分钟。解题思路是先给每个用户的登录日期按时间排序然后用DATE_SUB(login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date))这种方式构造一个分组标识同一个分组内的日期就是连续的最后再按这个分组标识做聚合。这道题其实并不复杂但当你在限时环境下很容易在窗口函数这里卡住。建议准备阶段一定要把这种用到窗口函数加日期运算的题型练熟。3.2 从笔试真题到工作场景的映射掌阅这套笔试题目最大的价值在于它几乎把大数据开发岗位日常工作里的高频场景都映射到了题目上。比如那道“用户阅读时长统计”的SQL题本质上对应的是埋点日志清洗和聚合那道“Kafka消息重复消费如何解决”的多选题对应的是实时数仓中at least once语义下的数据一致性保障那道“Spark宽窄依赖判断”的选择题对应的是Spark作业性能调优和Stage划分的基本功。我后来在准备面试复盘时把笔试时遇到的那些“拿不准”的题目整理到了一个文档里分成了“基础概念类”“源码原理类”“场景设计类”三个分类然后针对每一类去回忆对应的项目经验。这个做法帮助很大建议每一位准备秋招的同学都试一下。笔试不只是考完就结束了它其实是面试前最好的一次模拟实战。3.3 场景化SQL真题复盘月度新增阅读用户数这里把一道我认为含金量最高的SQL题完整复盘一下。题目背景是掌阅的用户阅读行为表user_read_log包含user_id、book_id、read_date三个字段要求统计2023年每个月的“新增阅读用户数”即该用户最早阅读行为发生在当月。完整的解题SQL如下SELECT DATE_FORMAT(min_date, %Y-%m) AS month, COUNT(*) AS new_user_cnt FROM ( SELECT user_id, MIN(read_date) AS min_date FROM user_read_log WHERE YEAR(read_date) 2023 GROUP BY user_id ) t GROUP BY DATE_FORMAT(min_date, %Y-%m) ORDER BY month;这道题的核心在于先用子查询找到每个用户的最早阅读日期在外层查询中按最早日期所属月份聚合。很多人的错误在于直接对user_read_log表按user_id和月份分组然后COUNT(DISTINCT user_id)这样得到的是每个月的活跃用户数而不是新增用户数。能区分“活跃用户数”和“新增用户数”这两个指标的计算逻辑是数据分析能力的重要体现也是大数据开发岗笔试中常见的考察点。3.4 链表类编程题手写复盘LRU缓存实现再复盘一道编程题“LRU缓存”。刚看到题目时我感觉挺亲切的因为这是LeetCode第146题的原题但平时只是刷过不代表能当场写出来尤其是在浏览器里边思考边输入代码比在IDE里写要紧张得多。我当时的实现思路是import java.util.HashMap; import java.util.Map; class LRUCache { private class Node { int key; int value; Node prev; Node next; Node(int key, int value) { this.key key; this.value value; } } private final int capacity; private final MapInteger, Node map; private final Node head; private final Node tail; public LRUCache(int capacity) { this.capacity capacity; this.map new HashMap(); this.head new Node(-1, -1); this.tail new Node(-1, -1); head.next tail; tail.prev head; } public int get(int key) { if (!map.containsKey(key)) { return -1; } Node node map.get(key); moveToHead(node); return node.value; } public void put(int key, int value) { if (map.containsKey(key)) { Node node map.get(key); node.value value; moveToHead(node); return; } if (map.size() capacity) { Node last tail.prev; removeNode(last); map.remove(last.key); } Node newNode new Node(key, value); map.put(key, newNode); addToHead(newNode); } private void moveToHead(Node node) { removeNode(node); addToHead(node); } private void addToHead(Node node) { node.next head.next; node.prev head; head.next.prev node; head.next node; } private void removeNode(Node node) { node.prev.next node.next; node.next.prev node.prev; } }这段代码的要点有几个一是addToHead和removeNode两个辅助方法一定要先写好主方法里才能保持清晰的逻辑二是在put时如果键已存在更新值并移到头部三是容量满了时淘汰tail.prev节点同时要从map中移除对应的key避免出现链表节点和map不一致的情况。笔试的判题系统里LRU这种题还挺容易因为“内存泄漏”或“节点移除不全”被判错的所以写完后一定要自己模拟两三组用例特别是不存在的key和重复put相同key的场景。4. 常见问题与避坑指南4.1 多选漏选与错选掌阅这套笔试题的多选题判分规则是少选得部分分错选该题全扣。这意味着遇到不确定的选项宁愿不选也不要乱选。我当时的策略是先把有绝对把握的正确选项选上如果某个选项我不确定它是否正确先不选等把所有题目做完再回来看。有个技巧是对于大数据组件类的多选题很多选项其实是互相矛盾的。比如一道关于“Flink如何保证精确一次”的多选选项里有“checkpoint机制”和“至少一次语义的默认配置”这两个选项之间是有逻辑冲突的。如果你能识别出选项间的矛盾关系就可以快速排除错误选项。4.2 编程题边界条件遗漏编程题在判题时的数据范围往往会超出你的预期。我复盘时发现很多人写的代码示例用例能跑通但一旦测试用例中有空数组、元素全为负数、数组长度特别大等情况就会报错。比如“最大子数组和”这道题有人初始化的max为0这样当数组全为负数时答案就会错误。正确的做法是初始化max为数组第一个元素或者初始化为Integer.MIN_VALUE。还有一个要注意的是数组长度为0时应返回0还是抛出异常要看清题目的要求有时题目明确说了数组非空有时没说那就要自己做好防御性判断。4.3 SQL题业务口径混淆SQL题最大的坑不在于语法而在于业务口径。比如“近7天”到底是指“最近完整7天”还是“包含今日在内的7天”“新增用户”是指“当月第一次阅读”还是“注册日期在当月”这些在题干里可能会有明确说明可能没有说明。如果题目没说明就按最自然的业务口径来理解如果题目有举例说明严格按照例子来。我们在答题时不要想当然看到题目后先花十几秒把题目中的“用户”“书籍”“日期”等关键字段圈出来再写SQL。这个习惯在面试手撕SQL时也很重要。4.4 时间不够用的应对策略90分钟看起来不长但题目数量多且覆盖面广很容易做着做着发现时间只剩15分钟编程题还没写。我的建议是动笔前一定要快速把整张卷子扫一遍把所有题目的分值做一个预判。如果遇到某道选择题超过3分钟还没思路就先标记起来跳过先把能拿的分拿到手。还有一点经验是编程题可以先在草稿纸上写伪代码确保思路清晰后再开始写正式代码因为一旦思路混乱写出来的代码很容易有逻辑漏洞调试起来反而更耗时。4.5 平台操作细节笔试平台虽然在正式开考前会有环境检测但有些细节如果不注意也会影响发挥。比如编辑器里的代码提示和格式化功能通常没有IDE那么智能如果你的代码缩进习惯不好在牛客网编辑器里会显得非常混乱影响你自己的阅读和调试。建议平时刷题时就习惯用牛客网或者LeetCode的网页编辑器来答题不要总是依赖本地IDE。另外考试期间要确保网络稳定我当时为了保险还专门插了有线网络以避免无线网络波动导致页面卡死这个细节虽然很小但一旦出问题会非常影响心态。5. 秋招大数据岗位备战建议5.1 分模块建立知识体系不要只刷题不总结笔试能覆盖的知识点非常多如果只是零散地刷题很容易忘。我建议把复习分成四个模块Java基础、数据结构和算法、大数据组件、SQL与数据分析。每个模块建立一份自己的知识清单按“高频考点 → 原理流程 → 典型例题 → 易错点”的结构来整理。以大数据组件为例HDFS、MapReduce、Spark、Flink、Kafka、Hive、HBase这七个组件每一个都要能画出核心流程图并能说明每个流程节点的作用。不要只在笔记里抄一遍最好的检验方式是在白板上给同学或自己讲一遍能讲明白才说明是真的掌握了。5.2 手写能力的训练笔试和面试越来越重视手写能力。Spark的算子你会在IDE里调用不代表你能默写出代码Flink的Window原理你能理解不代表你能手绘出数据流图。针对手写能力建议每天花30分钟在白纸上或编辑器里默写一个重要组件的核心流程、一段经典SQL、一个数据结构的Java实现。我当时把“HashMap的put流程”“HDFS写文件流程”“Flink的checkpoint执行流程”“Spark的Stage划分代码逻辑”这几块都默写了很多遍后来在笔试时遇到相应的选择题几乎不用思考就能选出交互的节点和顺序。5.3 业务场景题怎么准备掌阅笔试里的场景综合题提示我们大数据开发的考察正在从“会不会用组件”转向“会不会在业务链路中用组件”。所以准备笔试时不能只刷知识点也要多看看真实的数仓架构和实时计算架构案例。比如典型的用户行为分析链路前端埋点 → Flume收集日志 → Kafka缓存消息 → Flink/Spark Streaming消费并清洗 → 结果写入ClickHouse/HBase → 上层可视化。对于这条链路你要能说出每一步用了什么技术、为什么要用这个技术、可能出现什么问题、怎么解决。把这些场景反复练习之后你会发现很多看似复杂的场景题其实是在考同一套底层逻辑。5.4 结合目标公司业务来做针对性准备如果目标公司是掌阅这种数字阅读企业建议提前了解它的产品形态和数据特征。阅读平台每天产生海量的用户行为日志包括浏览、搜索、翻页、阅读时长、评论、分享等这些数据在产品层面可以用来做用户画像、内容推荐、阅读偏好分析、书籍热度预测。理解了这个业务笔试时的SQL题和场景题你就知道它想问什么。比如“统计每本书近7日的阅读人数”本质上就是内容热度监控而“统计月度新增阅读用户”本质上就是用户增长分析。把这些业务背景代入题目中你的答案会比单纯写SQL的人更有深度。5.5 笔试后的复盘比分数更重要不管笔试最后是否通过过了这道关卡之后都要做两件事第一是回忆题目把所有记得的题目整理成文档哪怕只有题干和选项关键词也尽量记录下来第二是做题目的复盘把每道题对应的知识点找出来回答自己三个问题这题考察的知识点是什么我当时选错了错在哪里如果再遇到同类的题目我的解题思路是什么。我当时整理的笔试题笔记有接近4000字后来在面试中被问到的很多八股文题目居然都能从这份笔记里找到影子。如果你正准备投递大数据开发岗建议现在就把知识清单建起来把高频题型练熟尤其是窗口函数、SQL聚合、LRU、线程池、Shuffle、checkpoint这些必考点尽量做到闭眼能写、张口能讲。备考的过程本身就是一次系统的技术梳理认真走完这一段不管最后收到的是哪家公司的offer你都会发现自己对大数据生态的理解比之前上了一个大台阶。