2024年秋招那会儿，我投了OPPO的数据开发岗，笔试做完最大的感受就是：这岗位考的东西和“数据开发”这四个字的字面含义几乎完全一致，但和很多同学以为的“我会写SQL、我了解Hadoop”完全是两码事。整张卷子下来，SQL占了将近一半的权重，剩下的全是数据仓库理论、大数据组件原理、场景设计题。如果你正在准备数据开发岗位的秋招或者实习笔试，这篇文章建议认真看完，我把自己踩过的坑、总结的考点、复习思路全部整理出来了。
先说一个最直观的结论：OPPO的数据开发岗笔试，整体难度属于中大厂数据开发岗的中等偏上水平，题型固定但不死板，重点考察的是你对“数据开发”这个岗位核心能力的理解深度，而不是你背了多少个组件的API。它更像是在问：给你一堆数据，你能不能把它变成可靠、高效、可维护的数据资产？把这个问题想明白了，笔试很多题目不用临时抱佛脚也能答出来。
1. 考前准备：简历、知识点和刷题方向的取舍
1.1 先弄清楚数据开发岗笔试到底考什么
我在投递之前查了不少面经，发现很多人的笔试复盘写得模糊，要么说“考了SQL和Java”，要么说“题目不难”，看了等于没看。真正到了自己上考场才发现，数据开发岗笔试的考察范围其实是有一个相对清晰的边界的。
从OPPO这次秋招的实际情况来看，笔试内容基本可以分为四大块：SQL编写与调优、大数据组件原理、数据仓库与建模理论、代码与场景设计题。四块占比大约为：SQL 40%左右，数据仓库与建模25%左右，大数据组件原理20%左右，代码题和场景设计题15%左右。
这个比例很能说明问题。很多科班出身、算法刷得很溜的同学，看到SQL题和数仓建模题反而会慌，因为平时在学校里很少系统接触。而真正有实习经验或者做过完整数据项目的同学，会觉得这套卷子很“对味”，因为考的就是平时干活的那些事。所以，复习重心放在哪、时间怎么分配，直接决定笔试的成败。
此外，我还要提醒一句：OPPO笔试用的在线编程平台，支持的语言种类比较全，但SQL题只支持标准的Hive SQL或者MySQL语法，不同题目的环境有差异。考前最好先去平台熟悉一下界面，看看代码编辑器支不支持语法提示、能不能本地调试。我在做SQL题的时候就遇到过平台自带的SQL编辑器没有任何提示功能，大小写切换、括号匹配全靠手打，稍微一紧张就容易出低级错误。
1.2 我把复习重点压在哪些模块上
我的复习策略是“SQL优先、建模跟上、组件原理查漏补缺、代码题保底”，这个策略经过这次秋招多场笔试验证，效果不错。
SQL部分，我重点刷了力扣上的数据库题目，尤其是中等难度以上的题，同时把牛客网上大厂SQL真题也过了一遍。每天保持3-5道SQL题的练习量，不是为了碰原题，而是为了保持窗口函数、多表关联、连续性问题这些考点的敏感度。数据开发岗的SQL题和后台开发岗的SQL题有一个显著区别——它更贴近数仓实际场景，经常要求你写出“计算某段时间内每个用户的首次/末次行为”“统计连续登录N天的用户”这类业务指标计算，而不是简单的CRUD。
数据仓库与建模部分，我把维度建模理论、数仓分层架构、缓慢变化维这三大块复习得比较透。这一块笔试虽然不要求你画图，但会在简答题和场景设计题里让你描述分层思路、解释为什么用某个粒度、如何处理维度表的变化。
大数据组件原理部分，我的方法是把Hadoop生态里最核心的几个组件——HDFS、MapReduce、Hive、Spark、Flink、Kafka，按照“是什么、解决什么问题、核心架构、优缺点、与同类组件的区别”这个模板逐个过了一遍。笔试不会让你写出某段复杂的Spark代码，但会考察你对“宽依赖与窄依赖的区别”“Spark与MapReduce的区别”“Flink的精确一次语义如何实现”这类原理性问题的掌握程度。
代码题部分，我准备的是Java和Python双语言。数据开发岗笔试的编程题通常不会出特别难的数据结构与算法题，更多是和数据处理逻辑相关的题目，比如字符串处理、数组统计、简单的动态规划。因为时间有限，我在代码题上只保持了每天1-2道热身的节奏，没有投入太多精力。
1.3 刷题工具与资料怎么选
刷题资料这件事，我不想说太多废话，直接给结论。SQL题以力扣的数据库题库为主、牛客网的大厂SQL真题为辅。力扣的题目分类清晰，难度梯度合理，评论区也有很多高质量的解题思路；牛客的真题更贴国内大厂的考察风格，会出现“连续登录”“留存计算”这类经典场景题。两个平台搭配使用，SQL这一块基本就够用了。
大数据组件原理和数仓建模，我没有报任何培训班，也没买大几百块的资料包，用的就是三样东西：官方文档的入门章节、经典技术博客的总结文章、还有一本《大数据技术原理与应用》作为体系参考。说实话，笔试考察的都是核心概念和原理，并不深，官方文档和高质量博客足以覆盖。
还有一个容易被忽略的点：复习时要把SQL、建模、组件原理的知识串起来学习，而不是让它们孤立存在。比如你在复习Hive的时候，可以想想Hive的分区表和数仓分层有什么关系；在复习Spark的时候，可以思考为什么Spark比MapReduce更适合做复杂的数据清洗。笔试的场景设计题，往往就是考察你能不能把这几块知识连成一个完整的数据处理链路。
2. 笔试题型全拆解：从SQL到技术方案设计
2.1 SQL题是绝对的重头戏，怎么拿高分
SQL题的分值占比最高，也是最容易拉开差距的部分。OPPO数据开发岗笔试的SQL题一共五道左右，前两道是基础题，考察简单的单表查询、聚合函数、日期函数；中间两题开始上难度，会考察窗口函数、多表关联、子查询嵌套；最后一题则是比较完整的“业务指标核算”题，题干会给你一张用户表、一张订单表、一张支付流水表，让你计算多个指标，还要考虑去重、空值处理这类细节。
先说基础题。很多人觉得基础题简单，反而容易轻敌失分。比如一道题让你统计“每月新注册用户数”，如果你只写了group by month(create_time)，却忘了考虑同一个用户在一个月内可能有多个注册记录（虽然正常情况下不会），或者没有使用count(distinct user_id)，就可能因为严谨性不够被扣分。数据开发对数据准确性的要求极高，笔试评分时也会渗透这个标准。
再说窗口函数题，这是数据开发笔试的核心考点，也是区分“会写SQL”和“真正懂SQL”的分水岭。OPPO的题目里出现了类似“计算每个用户在当前月份之前累计消费金额”“找出每个商品分类下销售额排名前3的商品”这类需求。这类题的答案几乎离不开row_number() / rank() / sum() over(partition by ... order by ...)这几个窗口函数的组合运用。
我当时做最后一题时，先用窗口函数算出了每个用户的累计消费，又用lag()算出相邻两次消费的时间差，最后结合case when做了行为分层标签。这种把多个函数组合使用的写法，光靠背函数语法是不够的，你得真正理解窗口函数在“分组内排序计算”这个场景下的执行逻辑。建议复习时把sum() over(order by ... rows between unbounded preceding and current row)这类累计窗口的物理意义吃透，因为它是很多复杂SQL的积木。
SQL调优类的题目也需要重视。我在笔试里碰到一道题，给了一段写了子查询的SQL，让你分析性能问题并优化。这就是数据开发日常SQL优化的核心场景。常见的几个优化方向是：尽量用join替代相关子查询；能用where过滤的不要放在having里；避免select *，只查需要的字段；大表关联时，先过滤再关联。这些都是很朴素但很实用的点，笔试考的不是花哨技巧，而是你有没有建立正确的SQL性能意识。
2.2 编程题：不只是算法，还有代码规范
OPPO数据开发岗笔试的编程题有两个，一般用Java、Python、C++中的任意一种都可以提交。题目难度不大，大概在LeetCode中等难度偏下，但有一点和后台开发岗很不一样：数据开发的代码题会带一点数据处理色彩，不会出纯粹的图论、动态规划难题。
我遇到的编程题，一道是“统计一个字符串中出现次数最多的字符，并输出字符及其出现次数”，另一道是“给定一个整数数组，返回所有和为target的两个数的下标组合”。第一道题思路很简单，用哈希表统计频次即可；第二道题也是经典的哈希表题目。但这里我提醒一句：代码题除了正确性，还考察代码规范和健壮性。你需要处理好空指针、空数组、字符串为空的边界条件，变量命名要见名知意，不能为了图省事用a、b、c这种毫无意义的命名。
另外，多语言选择上，建议你选自己最熟练的语言，不要因为“Java是后端主流语言”就临时切Java。数据开发岗位代码题的语言要求并不严格，Python在这种场景下反而有优势——内置函数多、写起来快，尤其适合处理字符串和数组类题目。我在答题时用了Python，题解代码二十几行就完成了，如果换成Java，至少要多写一倍。
代码题的提交和本地调试环境也有讲究。平台支持在网页端的代码编辑器里直接运行测试用例，但默认只有一个“测试用例”按钮，不会自动帮你跑所有预设用例。我遇到的情况是，自己写完代码后点测试，通过了样例，但最终评分里有一组隐藏用例没过，原因是数组长度为0时返回了空列表，但题目要求返回特定格式。这类边界问题只有多写几个测试用例自测才能发现，别嫌麻烦，代码题这种送分题要稳稳拿下。
2.3 大数据组件理论题：考的是原理还是使用？
大数据组件理论题是数据开发笔试中专业性最强的一块，也是最容易暴露“只背过名词、没理解原理”的部分。OPPO的题目形式是选择、判断和简答混合，覆盖面挺广，从HDFS写数据流程到Spark宽窄依赖，从Kafka消息不丢失到Flink状态管理，都有涉及。
我的建议是：不要死记硬背概念，要能用自己的话把原理讲清楚。比如题目问“Spark中宽依赖和窄依赖的区别以及各自的应用场景”，如果你只会背定义“宽依赖指父RDD的一个分区被多个子RDD分区依赖”，但无法解释“窄依赖适合管道化计算、可以避免shuffle，宽依赖需要对数据进行重新分区、往往伴随shuffle操作”，分数肯定拿不全。笔试的简答题需要你展现出“理解”而非“记忆”。
这里我顺便分享一下HDFS写数据流程的复习思路，因为这个知识点容易考，而且很多人的理解不准确。完整流程是：客户端向NameNode发起写请求，NameNode返回可用的DataNode列表，客户端将数据分块（默认128MB）依次传输到第一个DataNode，再由第一个DataNode将块复制到第二个、第三个DataNode，同时每写一个块要向NameNode上报元数据，最后数据写完关闭输出流，NameNode确认写入成功。很多人知道“三副本”和“机架感知”，但对流水线复制的过程和“客户端只写第一个节点，由节点间复制”这个设计原因理解不深。这个设计的本质是减轻客户端压力，避免客户端为每个副本都传一遍数据，理解这一点，相关简答题就能答出层次。
大数据组件的对比题也很常见，比如Spark与MapReduce的区别、Flink与Spark Streaming的区别。这类题不需要长篇大论，但要点要踩准。Spark与MapReduce的区别可以从“基于内存计算 vs 磁盘迭代”“DAG优化 vs 每步落盘”“启动开销低 vs 启动开销高”三个角度展开；Flink与Spark Streaming的区别则要聚焦“实时流处理 vs 微批处理”“每条数据一次处理 vs 每批数据一次处理”“精确一次状态一致性 vs 需要额外配置”。
2.4 技术方案设计题：最容易被低估的送分题
OPPO数据开发岗笔试的最后一道题往往是技术方案设计题。给一个场景，让你设计数据链路或数据仓库方案，说白了就是考察你有没有做过真实的数据开发项目。
我碰到的题目大意是：一个APP需要统计用户行为，包括曝光、点击、时长等指标，数据量每天在亿级左右，要求设计一套从数据采集到最终报表输出的方案。那类题目看起来信息量很大，但实际上考察的是你能不能给出一个结构清晰、环节完整的数据链路设计。我在答题时从四个层面做了拆解：数据采集层用埋点SDK接收行为数据，通过Kafka接入实时数据流；数据存储层用HDFS存储原始日志数据，Hive建外部表做离线数据仓库；数据计算层分实时和离线两条链路，实时用Flink做清洗和指标聚合，离线用Spark或Hive做T+1报表计算；数据服务层将计算结果写入MySQL或ClickHouse，供报表平台查询。
这种题的答题逻辑是“分层+链路完整+可落地”，不需要你写得像架构文档那么细，但必须把关键环节和组件选择理由写清楚。比如我在Kafka部分写“使用Kafka是因为其高吞吐和分区机制可以支撑亿级日活数据量的实时接入”，这就是一个理由充分的选择。
技术方案设计题相对其他题型来说，有很强的“套路性”。你只要把经典的“数据采集-数据存储-数据计算-数据服务”四层架构背熟，结合具体场景往里填内容，就能拿到不错的分数。但要想拿高分、拉开差距，你需要的是在方案里展示一些“加分项”，比如“在ODS层保留原始日志以便回溯”“对埋点数据做ETL清洗保证数据质量”“通过设置分区键和数据压缩降低存储成本”等。这些点都来自真实的数据开发项目经验，光背架构是写不出来的。
3. 核心技术细节解析：SQL调优与数据建模
3.1 窗口函数：数据开发笔试的第一道分水岭
窗口函数在数据开发笔试里的地位，怎么强调都不为过。很多SQL题看似复杂，如果用常规的group by去解，要么写不出，要么写出来特别绕；一旦转换思路用窗口函数，解题过程会很清爽。但问题在于：很多教程只教语法，不教“什么时候该用窗口函数”，导致很多人学完还是一头雾水。
我的理解是，当你需要计算“在分组内基于某个顺序的指标”时，就要优先考虑窗口函数。比如“每个用户按时间排序的订单号”“每组数据里按金额排序的排名”“截至每天的累计销售额”，这些都是典型场景。
笔试里经常出现一类题：求每个商品分类下销售额排名前3的商品。如果不用窗口函数，你得先手动算出每个分类下每个商品的销售额，然后自关联比较计数，SQL写得又长又难读；用row_number() over(partition by category order by sales desc)排名后在外面套一层where rn <= 3，十几行搞定。这个对比非常直观地说明了窗口函数的价值。
窗口函数的执行顺序也很重要，很多人因为没搞清楚执行顺序而在复杂SQL里出错。标准的执行顺序是：from->where->group by->having-> 窗口函数（在分组后执行） ->select。也就是说，窗口函数是在分组和过滤之后、投影之前执行的，所以你在where里无法直接使用窗口函数的别名进行过滤，必须再套一层子查询。我笔试时也踩了这个坑，写完where rn = 1才发现rn是窗口函数的结果，不能在where里直接引用，赶紧改成子查询才纠正过来。
3.2 数据倾斜的排查思路：笔试和面试都会问
数据倾斜是大数据计算场景里最容易遇到的问题，也是数据开发笔试和面试的高频考点。所谓数据倾斜，简单理解就是计算任务里的数据分配不均，绝大多数数据都集中在少数几个Task上，导致部分节点计算量过大、拖慢整体进度，甚至出现内存溢出。
笔试里关于数据倾斜的题目通常不会让你写代码，而是给你一个场景，比如“Spark任务在某个reduce阶段非常慢，可能是什么原因，怎么解决”。你需要建立起一套排查思路。
最常见的原因包括：key本身分布不均（比如某个热门商品ID的订单量极高）、空值或者无效值堆积（比如大量用户ID为空被分到同一个Task）、Join操作中关联键的基数差异大（比如小表的关联键大量重复）。对应的解决思路也有几板斧：对倾斜的key加随机前缀打散，再做二次聚合；空值单独处理，不要让它参与正常分组；大表和小表Join时，把其中较小的表做广播，避免大表的reduce端数据倾斜。
我建议你把数据倾斜的排查和解决方案整理成一个“记忆模板”，从“现象表现、原因分析、解决方案、注意事项”四个方面去梳理。这个模板不仅能应对笔试，后面的面试环节也大概率用得上。
3.3 数仓分层设计：从ODS到ADS我这么答
数仓分层设计是数据开发岗位的“战略级”知识，笔试里会以简答题或设计题形式出现，面试更是必问。一套标准的数仓分层结构是：ODS（原始数据层）、DWD（明细数据层）、DWS（汇总数据层）、ADS（应用数据层）。
在笔试中，如果题目让你设计数仓分层，你需要把每一层的作用和设计原则写清楚。ODS层是与源系统同构的原始数据存储，原则上只做原样保留和简单清洗；DWD层做数据的规范化、维度退化、清洗去重，是明细数据的主体；DWS层按主题进行轻度汇总，比如按用户维度和商品维度生成汇总指标；ADS层面向具体应用生成高定制化的指标表，直接支撑报表和数据分析。
这里有一个很多同学会忽略的点：你的分层设计不能只说“有这几层”，还要说出“为什么分这么多层”的设计动机。分层的核心目的是“空间换时间，效率换成本”——把复杂的数据加工过程拆解到各层，避免重复计算、提升数据复用性、屏蔽底层数据变更对上层的影响。我在笔试里写方案时，特意加了一句“通过统一在DWD层进行数据清洗，避免每个下游任务重复开发清洗逻辑，既节省了计算资源，也保证了指标口径一致”，这句话很加分，说明你真的理解分层背后的成本和收益考量。
另外，关于缓慢变化维（SCD），OPPO笔试里也考了一道选择题。SCD的基本概念是维度属性随时间缓慢变化，常见处理策略有四类：直接覆盖（SCD1）、新增一行（SCD2）、新增一列（SCD3）、历史全保留（SCD4）。数据开发最常用的是SCD2，因为它既能反映当前状态，又能保留历史轨迹，特别适合用户信息、商品信息这类维度的管理。我建议你把SCD四种策略的优缺点、适用场景整理成表格，笔试和面试都用得上。
4. 实操复盘：模拟笔试与时间分配的实战经验
4.1 我自己做的一次全真模拟
数据开发岗笔试的核心风险点不是“不会做”，而是“做不完”。150分钟听起来不长不短，但当你面对6道SQL、2道编程题、十几道理论题和1道方案设计题时，时间分配不好很容易翻车。我在正式笔试前做过一次全真模拟，给自己掐了表，模拟结束后做了一次完整的复盘，发现了很多问题。
最大的问题是：我在前两道SQL基础题上花了太长时间。原因是我反复纠结“题目到底需要哪些字段”，对着样例输出看了一遍又一遍，完全没进入状态。模拟卷做下来，光前两道题就用了30分钟，导致后面编程题和方案设计题时间不足。后来我调整了策略：每道SQL题最多给自己15分钟，前5分钟读题和理解思路，如果5分钟后仍然没有清晰的思路，就果断放弃或者先写一个粗糙版本提交，不能在一道题上死磕。
模拟考试的第二个收获是：要把最擅长的部分放在最前面做。正式笔试时，我调整了答题顺序——先做SQL基础题，再做编程题，然后转头做大数据组件理论题，最后留出30分钟以上给方案设计题和SQL难题。这个顺序能保证凡是会做的题都拿到分，不会因为时间耗尽丢掉必得的分。
我强烈建议你在秋招开始前就做一次这样的全真模拟，最好用和正式笔试一样的平台和题型难度。模拟的目标不是“考多少分”，而是让你对每个模块的真实耗时有一个体感认知，正式笔试时才能做到心里有数。模拟之后，把耗时的题目按“时间占比”列一个表，你就能很清楚地知道，自己的时间到底花在了哪里、应该在哪里提速。
4.2 时间分配：我把60%的时间留给SQL
根据我复盘模拟考的经验，正式笔试时我将时间分配按照“6:2:1:1”的比例来安排——60%的时间给SQL和场景设计题，20%给编程题，10%给大数据组件理论题，10%作为机动缓冲。为什么这么分？因为SQL题的分值占比最高、场景设计题的“性价比”也高，这两个模块是我最有把握拿分的点。
严格来说，这个比例不是固定的，要根据你的优势动态调整。如果你大数据组件原理特别熟，可以压缩理论题的答题时间；如果你代码能力很强，可以多花一点时间把编程题写得更加完善。但有一条原则是不变的：千万不要在理论题的选择、判断题上花太多时间，因为这类题往往考得相对基础，仔细审题后第一感觉通常是对的，反复纠结反而浪费时间。
我做理论题有一个习惯：先扫一遍题目，会的直接选，不确定的做个标记，等到最后有时间再回头检查。这样做最大的好处是，不会因为一两道不确定的题目卡住，打乱对整个考试的节奏感。20道理论题，最多花15分钟就应该全部过完，剩下的时间留给SQL和代码题。
4.3 答题顺序和草稿习惯，细节决定成败
笔试中很多人容易忽略答题顺序的影响。我个人的习惯是“先易后难、先稳后冲”：先把最有把握的SQL基础题和编程题做完，然后是数据建模和理论题，再回到有难度的SQL题和方案设计题。这样做的心理暗示也很重要——前面顺风顺水，后面遇到难题时心态会更稳。
平台自带在线编辑器支持多标签页切换，我建议你打开一个空白标签页当草稿纸，把SQL题的思路、字段关系、计算逻辑先写在草稿里。看到一道有难度的SQL题，不要直接上手写，先用文字或伪代码在草稿纸上拆解：先算什么、再关联什么、最后怎么过滤。比如统计连续登录用户那道题，我先把“用row_number给每个用户的登录日期编号、用日期减去编号得到分组标识、按分组标识计数”这三步写在草稿上，然后照着草稿写SQL，逻辑清晰很多，出错的概率也低很多。
4.4 考场上遇到完全没见过的题怎么办
不管准备得多充分，考场里一定会遇到几道没见过的题。这种题通常是开放性的简答题或者场景题，没有标准答案，考察的是你“遇到新问题时的分析框架”。比如我遇到的方案设计题，虽然没有做过完全一样的项目，但“埋点数据从采集到报表”这个链路我在实习时做过类似的，所以我直接套用了“四层架构 + 实时离线双链路”的分析框架。
即使你完全没有相关经验，也不要空着不写。把你知道的相关概念先写出来，用“定义-流程-方案-注意事项”的结构组织你的答案，即使不完整，也比白卷强。数据开发的笔试评分并不是“全对才得分”，老师会看你每个步骤的逻辑和知识点覆盖，写一部分往往就能拿到一部分的分。
5. 常见问题与避坑指南
5.1 挂在SQL细节上的三个典型错误
我在准备笔试的过程中，复盘总结了自己和身边同学在SQL题上反复踩坑的三个典型错误，这里直接分享给你，帮你避开。
第一个错误是没有考虑去重。统计类题目如果不加distinct，出现重复记录时结果就会偏差。尤其是用户、订单这类容易产生多条记录的明细表，统计人数时经常需要count(distinct user_id)，这个细节极其简单但失分率很高。
第二个错误是日期函数使用不规范。数据开发的SQL题几乎必考日期处理，比如按月统计、按天统计、计算日期间隔。如果你对date_format、datediff、date_add这些函数不熟悉，做题速度会大打折扣。我建议你在复习时专门整理一页“日期函数速查表”，把常用的日期格式化和日期计算函数都列出来，考前扫一眼，考场上能省不少时间。
第三个错误是窗口函数与group by混用时的逻辑混乱。有些题目既需要分组统计，又需要在分组基础上做排名，很多人会在同一层SQL里同时写group by和窗口函数，导致执行报错或结果错误。正确做法是先用group by生成汇总结果，再在外层SQL中对汇总结果使用窗口函数。笔试时看到“先聚合、再加工”的题目，养成“套两层”的习惯。
5.2 理论题背了不会用的表现
理论题看似最简单，因为答案可以从复习资料里背出来。但OPPO笔试有个特点——理论题往往会包装在一个具体场景里。比如选项里给了四个关于HDFS的描述，但其中两个描述是正确的、两个是错误的；又比如给了四个关于Flink状态一致性的描述，让你选出错误的一项。这种情况下，你光背结论不够，还得理解每个描述背后的原理，才能选出正确答案。
我建议你在复习时不要只背“一句话结论”，比如“HDFS适合大文件存储”，而是准备一个“为什么”的推导过程。例如：HDFS默认块大小是128MB，是因为大块可以减少NameNode的元数据压力，减少客户端与DataNode的通信次数。这样你在考场上即使遇到题目换个角度考你，也能从原理层面推导出答案。
5.3 笔试前的最后一周，我做了什么
最后一周我不再追求刷难题，而是做了三件事：第一，把SQL题的错题重新做一遍，把那些“差一点就想到”的窗口函数技巧过一遍；第二，把大数据组件的经典原理问题、数仓分层、缓慢变化维的答题框架整理成思维导图，每天早中晚各看一遍；第三，找两套模拟题做限时训练，完全按照正式笔试的时长和环境要求作答，训练在压力下的反应速度。
说实话，最后一周没必要再肝新的知识点。你复习得再充分，也不可能把所有知识都覆盖到位，这个时候重要的是把已经掌握的内容练成肌肉记忆，确保考场上不会因为紧张而把会做的题做错。数据开发岗位的笔试，考察的不仅是知识深度，还有你把知识落地成答案的能力——这个能力只能靠反复练习获得，临时抱佛脚是这个环节最没用的操作。
5.4 笔试结束后的复盘动作，别考完就扔
笔试结束后，趁记忆还热乎，赶紧做一次复盘。哪怕平台没有立即公布分数，你也应该把刚才做过的题按“确定做对”、“半对”、“完全不会”三类记录下来，然后去查正确解法。这一步对后续的面试准备非常关键——OPPO这类大厂，笔试和面试往往是同一个招聘流程，笔试中暴露的知识薄弱点，很可能在面试里被再次追问。
我自己在笔试后复盘时，发现自己对“Kafka如何保证消息不丢失”这题答得不完整，只知道生产者端和消费者端的配置方式，但没答到Broker端的副本机制。回去后我专门补了这个知识点，后来在面试中果然被问到了类似问题，因为有了前期的复盘，回答得很顺畅。笔试复盘实际上是提前做了一轮面试准备，这个动作一定要重视起来。
个人观点不一定适合所有人，但就我自身的经验来说，数据开发岗笔试准备的核心逻辑是：把SQL练到“条件反射”的熟练度，把数仓理论和组件原理理解到“能讲给别人听”的程度，把场景设计题的套路内化成自己的分析框架。做到这三点，面对OPPO或者其他中大厂的数据开发笔试，你至少能拿到及格分以上的水平，再往上走就看你对业务和技术的融会贯通程度了。
