每年校招和暑期实习的这个时间节点,数据分析笔试都是淘汰率最高的一环。很多同学刷了几百道SQL,背了一堆统计公式,结果打开某大厂的笔试链接,还是被一道不按套路出的业务Case题或者ACL配置题卡了半小时。我自己经历过多个大厂数分笔试轮次,也帮几位学弟学妹做过笔经梳理,发现题海战术其实不如“按题型布局、按考察点建知识树”来得高效。这篇把数分笔试的题型构成、每个考点背后的真实考察逻辑、刷题方向以及冲刺阶段的准备策略一次讲透,内容比较多,建议收藏后按章节查阅。
先说清楚这篇对哪些人有价值:正在准备数据分析校招/实习笔试的同学,复习了一个月但看到新题还是会懵的选手,以及想转行数分但不知道从哪开始准备的朋友。已经工作在岗但想重新回顾笔试技巧的人也能当查漏补缺用。下面的内容全部来自真实笔试现场的复盘和准备过程中的踩坑记录,不是那种“面试技巧一百条”的泛泛而谈。
1. 先画一张数分笔试的作战地图:题型、权重与复习优先级
数分笔试和开发岗笔试最大的区别在于,它不单考代码,而是考“代码 + 统计 + 业务 + 表达”的综合能力。很多时候你面试的那几十分钟里聊的问题,笔试环节就已经筛掉一多半人了。所以第一步要搞清楚考试长什么样,再决定把有限的时间砸在哪个题库上。
1.1 主流题型构成与分值分布
从近两年几家头部互联网公司的数分笔试来看,题量和时间普遍是:90分钟到120分钟,单选/多选 + SQL编程题 + Case分析文字题,部分岗位还会加Python代码题或纯概率统计题。大致分值权重可以参考业内均值,具体公司会有浮动:
| 题型 | 常见占比 | 单题耗时参考 | 备注 |
|---|---|---|---|
| SQL编程题 | 40%-50% | 10-20分钟/题 | 考察数据提取和聚合计算,是拉开差距的主战场 |
| 统计概率与业务概念 | 15%-25% | 2-5分钟/题 | 以选择题为主,偶尔有填空 |
| 业务Case分析题 | 15%-25% | 15-30分钟/题 | 指标异动排查、指标体系设计、AB实验解读 |
| Python/算法题 | 0%-15% | 10-20分钟/题 | 偏数据处理的岗位会考,通常用pandas即可解决 |
一道SQL可能会出两问,一问取数、一问做比率计算;Case题也经常嵌套数据表,让你先写SQL取数再回答业务判断。这个嵌套设计很重要,说明笔试想考察的不只是单一能力,而是你能不能把数据变成结论。
1.2 不同事业线和岗位方向的区别
同样是数分笔试,内容会有很大偏差。用户增长方向喜欢考留存、漏斗、LTV;电商方向喜欢考GMV拆解、复购率、转化率异动;广告商业化方向爱考CPM、CTR、ROI;强化学习或者数据挖掘岗位甚至会在笔试里出现简单的模型评估题目。建议在投递之前先调研目标岗位的JD描述和往年笔经,确定重点题型。
我的实操体会是:与其把所有题型都刷到八九十分,不如把目标岗位最常考的两类题型刷到接近满分。比如你想去电商部门,SQL里多练聚合、多表关联和GMV相关指标拆解;想去增长部门,就多练漏斗、留存、事件路径分析。笔试时间有限,全题型平均发力只会让每个板块都不够突出。
1.3 开考后的时间分配策略
笔试里最常出现的反面教材就是:前面的统计概念题花太多时间纠结,结果后面30分的SQL编程题只剩15分钟。我给自己定的策略是“先抓主得分区”,开考前如果能看到题型分布,先跳过不确定的选择题,直接做SQL和Case题,最后再回来磨选择。因为选择题数量多、分值小,错两三道对总分影响不大,而一道SQL做不出来可能就是直接凉凉。
大家可以用“分值/时间”这个性价比公式来做决策:一道20分的SQL题花15分钟是合理的,但一道1分的概念题花5分钟就是亏本买卖。笔试不是考试院考试,不需要每道都答对,保证总体得分最大化才是目标。
2. 核心考点逐个击破:SQL、统计、AB实验和Python
题型地图画完之后,最关键的就是把各个考点的知识树补起来。这里说的不是背一堆定义,而是知道考试时它会怎么出、用什么方式快速得出正确答案。我按照刷题过程中的真实总结来逐个讲。
2.1 SQL:窗口函数、留存漏斗与多表关联
笔试里的SQL题很少让你做简单的select+where,基本都是有点嵌套的统计逻辑题。三个高频方向:
第一类是窗口函数。几乎每家都会考,常见的有按部门分组排名、累计求和、同环比计算等等。窗口函数之所以高频,是因为它能把“分组内计算”这个业务里特别常见的需求用标准语法表达。笔试时容易踩的坑是忘记了窗口函数的执行顺序:是先有了where的筛选结果,再做窗口计算,所以如果你先过滤再排名,结果会和期望不一样。
第二类是留存/漏斗计算。这类题型非常喜欢出,比如用user_id、login_date两个字段算出每日新用户的次日留存率。核心逻辑是找出每个用户首次登录日期,然后看这个用户次日有没有再次登录。SQL里通常用min(login_date) over(partition by user_id)来标记首日,再和登录日期做datediff。实际写的时候要注意两点:一是表里可能包含重复登录记录,必须先distinct再join;二是计算分母时要用注册用户数而不是活跃用户数,否则留存率会虚高。
我一般会在草稿纸上先写一遍伪代码逻辑,再落到SQL里。不少同学一上来就写select,写到一半才发现忘了去重,又回头改,白白浪费五分钟。笔试环境里草稿纸随便用,时刻准备着。
第三类是多表关联综合题。涉及订单表、商品表、用户表,考察inner join和left join的区分。笔试里的进阶坑是:left join之后因为一对多关联会把主表记录放大,如果直接求均值会算错。应对思路是先聚合再关联,比如先把订单表按用户聚合出总金额,再关联用户表,这样能避免数据膨胀。
还有一个细节,多数笔试平台支持SQL在线运行,但不能调试太久。比较稳妥的做法是在本地的Scratchpad里先跑通小数据集,再贴到平台。如果平台没提供小数据集,就先用select limit看几行了解数据结构,再写完整逻辑。
2.2 统计与概率:概念题不只是背公式
统计概率这块的选择题最爱考的是假设检验里的p值含义、置信区间解释、中心极限定理、贝叶斯公式、均匀分布和二项分布等基础概念。很多同学背了公式却不知道概念在问什么,翻车率极高。
举个例子,题目可能会问“当p值小于0.05时,下列说法正确的是”。正确答案是“在原假设为真的前提下,观察到当前样本或更极端样本的概率小于5%”,而不是“原假设为假的概率大于95%”。这是统计推断里最常见的误解,笔试就喜欢用这种选项来筛人。
再一个是置信区间。题目如果给出95%置信区间为[a,b],正确的解释是“重复抽样多次,95%的置信区间会包含总体真实参数”,而不是“总体均值有95%概率落在[a,b]”。前者描述的是方法覆盖率,后者描述的是参数概率,笔试里这两个说法换个文字就能决定对错。
贝叶斯公式也是必背,但别停留在公式上,要会做具体运算题。比如产品A次品率是0.01,产品B次品率是0.03,生产比例为4:6,问抽到次品来自A的概率。这道题其实只是套一遍贝叶斯,但需要先算全概率分母,再算后验概率分子。平时把这类题目手工算三遍,笔试里看到就不会慌。
概率题有时还会和编程结合,用Python做蒙特卡洛模拟来估计期望。比如掷骰子直到出现6为止的期望次数,这类题既考概率理解又考代码能力,准备时可以多写几个随机模拟脚本,理解背后的概率定律而不是死记答案。
2.3 AB实验:不只会算显著性,还要懂常见陷阱
AB实验在笔试里通常以Case题形式出现,或者夹杂在选择题中。最基本的是判断实验是否显著:给出实验组和对照组的转化率、样本量,让你用z检验算显著性。这需要记住z值公式和临界值,掌握标准正态分布表的使用方法。建议背下最常见的临界值:95%置信水平对应1.96,90%对应1.645,99%对应2.58。
别只会算显著性,更常考的是实验设计陷阱。比如:
- 样本量不均时不能直接用简单p值判断,要先检查方差齐性
- 一个用户被重复分到两组会造成独立样本假设被破坏
- 实验过程中新增的流量来源不符合原始分流规则,导致样本偏置
- 观察多个指标时,不做多重检验校正,出现假显著性
准备这块的思路不是背一堆文字,而是找两道完整的AB实验判断题去做。题目会给出一个实验报告,问你结论是否可信,你需要主动指出“样本量不足”“分组不均匀”“提前停止实验”等问题,这就是答题区分度所在。平时看到实验相关的文章,可以刻意训练自己找漏洞,笔试时遇到同样的场景就不会没话说。
2.4 Python与算法:pandas三板斧就够用
如果岗位对Python有要求,题目一般用pandas就可以解决,很少考手写算法。高频操作包括数据读取、去重、缺失值处理、分组聚合、数据透视表和排序。掌握这些基础操作之后,再用一行代码解决“求每个类别的平均值”“找出某个用户的最后一条记录”这类问题就够了。
我总结出一个pandas速查视角,笔试前三天过一遍:
- df.groupby(['col']).agg({'num':['sum','mean']})
- df[df['date']==df.groupby('user')['date'].transform('max')]
- pd.merge(df1,df2,on='key',how='left')
- df.sort_values(['col'],ascending=False).drop_duplicates(subset=['user'],keep='first')
这些代码背后的逻辑其实就是SQL里窗口函数的pandas版本。准备时建议把SQL题型和pandas题型对照着刷,这样两条腿一起走,一笔笔试里两边都能拿分。如果笔试明确不考算法题,就不要花时间在排序算法、动态规划这类上面,数分笔试里的代码题只看数据处理能力。
3. 业务Case题:筛选区分度的关键战场
每次笔试结束和周围同学交流,大家反馈最多的就是Case题。Case题没有标准答案,但考官打分是有固定维度的,通常会看你的结构、业务常识和表达能力。很多同学在SQL题上能拿满,却在Case题上丢掉十几分,原因不是不会,而是没建立起答题框架。
3.1 常见Case题型:指标异动、指标体系和估算题
最常遇到的是三类。指标异动题:比如“某产品次日留存率突然下降了5个百分点,如何分析”。指标体系题:比如“请为核心电商业务设计一套指标体系”。估算题:比如“估算该城市一天喝掉多少杯咖啡”。
指标异动题考察的是逻辑链条和业务场景,不建议上来就讲“要查数据”。要先定义问题:是整体下降还是部分渠道下降?是真实的下降还是统计口径变动?然后才开始拆维度。拆维度的方向可以包括时间维度、地域维度、用户分层维度、版本/渠道/设备维度、来源/动作渠道等。拆完维度之后,再提出可能的原因假设:是外部环境变化,还是产品功能调整导致;是竞品抢占,还是内容供给出问题。
指标体系题则需要你具备“北极星指标 + 过程指标 + 结果指标”的三层思维。以一个内容产品为例:北极星指标是日活跃用户数,过程指标是曝光量、点击率、观看时长,结果指标是留存率和付费率。答这类题时不要堆指标,而是要解释为什么这个指标能反映业务健康度,像讲故事一样串联起来。
估算题考察的是逻辑拆分能力而不是准确性。建议先明确估算口径,再拆关键链条,比如咖啡销量 = 人口基数 × 喝咖啡人群比例 × 每天购买咖啡杯数。解释清楚每一步的假设依据就能及格,不需要精确。笔试时往往紧张,很容易在估算题里卡太久,建议给自己定个上限时间,超了就先写假设和算式,不追求完整结果。
3.2 Case题的得分点:不是答案对,而是结构全
我批过几次模拟笔试卷,发现一个很有趣的规律:Case题得高分的人,不一定是业务最懂的人,而是答题逻辑最清楚的人。一篇好的Case答案会让阅卷人不用猜就能找到“问题诊断、原因假设、验证计划、建议动作”四个层次。
这里的操作性建议是:写Case答案时主动用“第一、第二、第三”或者“先看整体再看分层”这类结构词。内容本身不一定有标准答案,但有了结构,阅卷人至少能看出你有分析能力。另一个加分点是主动把“验证”写清楚,比如提出“通过AB实验验证新版本对留存的负向影响”,这样能体现出你不仅会拆问题,还会用数据手段证明。
3.3 怎么让Case答案有区分度
区分度来自两点:一是对业务细节的敏感,二是对数据口径的敏感。业务细节方面,如果题目问留存下降,你能主动提到“要看新增用户和存量用户是否分开统计”,就会比答“拉取数据看哪个维度下降”更高级。数据口径方面,如果题目给出两个差异很大的数字,你能主动说“需要确认是否包含测试订单、是否去重”,就会显得专业度很高。
建议平时多看业务复盘文章或者自己拆解主流App的功能,不是让你变成产品经理,而是让你在笔试时有常识可以做假设。笔试现场能想到的假设,都来自于你平时对产品、技术和用户行为的基本理解。沉淀渠道就是多问自己“为什么这个指标会变化”,这才是Case题真正的准备方式。
4. 考前的实用冲刺准备策略
笔试准备不是无限刷题,而是有节奏地建立知识体系。这一节是我自己两次笔试之间复盘出来的有效方式,也帮过朋友按这个套路拿到面试通知。如果你离笔试还剩一到两周,基本上按照下面的节奏来安排是性价比最高的。
4.1 前期:先建知识树再做题
第一个阶段只做一件事:根据目标岗位JD整理一张知识清单。JD里提到“掌握SQL、熟悉统计、了解指标体系”,对应的知识树就是SQL基础到窗口函数、统计基础到假设检验、业务指标到埋点理解。把每个知识点列出来,对着往年笔盖在脑内过一遍,知道的打钩,不知道的先补。
很多同学一开始就钻进题目里,做了一道又一道,最后只是提升了手速,没有提升知识结构。正确的做法是每天先花30分钟梳理当天要复习的整个知识模块,再拿题目验证,这样错题才能反过来修正知识树,而不是知识盲区一再出现在不同题目里。
4.2 中期:分模块集中刷题
第二个阶段按模块刷题,每个模块至少要集中练两天。SQL模块常用的方法是:每天做三到五道题,难度从窗口函数到多表关联递增,做完后把自己写卡的题整理进错题本。统计模块每天做20道概念选择题,重点看错题里的概念解释。Case模块隔天写一道完整的指标异动题或估算题,和标准答案对照,把遗漏的角度补进自己的答题模板。
关于刷题资源:题库范围很广,优先看往年笔经原题和通用的SQL题库,不需要买一堆高价资料。真正值得花时间的是自己整理错题和答题模板,这比囤十份纸质机经有用得多。准备时可以用来敲代码的在线工具很多,重点是练习在无自动补全的环境下写代码,毕竟笔试平台基本都是白板环境。
4.3 后期:模拟真实笔试环境
考前一天到两天,用模拟题连做一套完整的笔试。模拟时做三件事情:限时、不切出去查资料、像真实考试一样先写关键题。时间分配可以提前预设好,建议套用“前5分钟浏览全卷,中间60分钟做高性价比题,最后15分钟补漏和检查”的节奏。
检查环节特别重要,很多失分不是不会,而是漏了条件。提交前重点检查:SQL题里有没有把left join写成join、有没有对空值做处理、留存计算是不是用了distinct;统计题里有没有漏掉备择假设的条件;Case题里有没有只写原因不写“如何验证”。这些细节只要检查一遍就能捞回不少基本分。
4.4 笔试时的工具与操作细节
笔试平台的操作习惯很多人会忽略,但非常关键。开考前先确认摄像头和麦克风是否正常,关闭无关软件或弹窗通知,避免切窗口时被记录。部分平台会自动锁浏览器,不能切出去搜索,所以在进入答题前提前把需要用到的口诀或公式写在草稿纸上,以免临时手忙脚乱。
另一个容易翻车的是编译环境差异。如果平台自带的SQL环境和本地环境不一样,可能不支持某些函数写法。比如本地MySQL支持的某些聚合窗口函数,在平台的SQL版本里不一定兼容。所以模拟练习时尽量使用笔试同一平台做题,提前熟悉它支持的语法范围和调试方式。概率题如果需要查正态分布表,可以在草稿纸上标记好临界值,节省翻阅时间。
5. 数分笔试的常见问题与避坑实录
最后一部分是实战中常见的问题清单。这些坑多数人都会遇到,提前看完至少能少丢十分。我按照“现象、原因、应对”三个角度整理成速查表。
| 常见问题 | 主要原因 | 应对方法 |
|---|---|---|
| SQL题做一半发现结果数量不对 | 忽略了空值和重复值 | 每组关联后先select count观察再继续写 |
| 留存率计算结果超过100% | 分母用活跃用户,没用注册用户 | 严格按定义区分“新用户数”和“活跃用户数” |
| Case题写了很多但得分不高 | 只有原因假设,没有验证方案 | 每题强迫自己写“可通过AB实验验证”这类句子 |
| 统计概念题二选一总是选错 | 混淆了p值和置信区间的解释 | 把常见误解和正确解释做成对照表反复背 |
| 时间不够用 | 前面低分题耗时太久 | 先做SQL和Case,最后回填选择题 |
再说几个不易察觉的坑。第一,部分笔试平台有“切屏记录”,开考后切换窗口超过三次就会被标记,可能会影响最终分数。所以考前关掉弹窗、聊天软件和浏览器的消息提醒,物理上避免打扰。第二,文字题不要留白太多,即便没有思路也要按框架写几条,结构化答法很可能蒙对要点,留白则一定是零分。第三,如果题目里给了很多冗余字段,不要慌,大概率是干扰信息,直接聚焦题目的核心问题,不需要每列都解释一遍。
还有一个我反复提醒朋友的细节:写Case题时尽量使用业务语言,少用“因为A所以B”这种单链条表达。你是在给业务分析报告,不是在写学术论文。一个“先用漏斗拆解、再用多维对比验证”的表述,比长篇大论直接给出结论要有说服力得多。
我自己的切身体会是:笔试前的知识框架远比想象中重要,考场上90%的题目都能落到“SQL数据提取、统计推断、业务假设”这三个盒子中的一个。与其焦虑自己背得不全,不如每天睡前花十分钟在脑内过一遍今天复习的知识点,这种主动回忆比机械刷题印象深得多。另外,笔试只是整个招聘流程的第一步,它的核心不是筛“最懂业务的人”,而是筛“有基本功底且能结构化输出的人”,所以只要准备到位,通过并没那么玄学。如果你正在准备数分笔试,希望这篇能帮你少走弯路。