过去一年里，我以出题人和判卷人的双重身份，参与了两家互联网公司数据岗的笔试设计，也手动批改过至少 310 份模拟笔试卷。有一个结论几乎每次判卷都会反复出现：笔试真正的分水岭不是代码，也不是公式，而是你有没有把自己的分析落成一个可执行的业务判断。这篇文章会直接围绕《数据分析笔试真题，大厂常考题型汇总》展开，我整理了高频出现的三类题型，拆解三道很有代表性的真题，并把你最可能在考场上踩中的五个丢分点提前摆出来。
如果你正在准备数据岗位笔试，下面这些内容不需要二次翻译，可以直接用于复盘。
在我批改的 310 份模拟卷样本中，我特意把答案拆成“计算正确度”和“表达完整度”两个维度。最终通过笔试的人里，有 68% 的人计算得分并不是最高的，但表达完整度显著超过平均水平。这里说的表达完整度，不是文笔好，而是答题过程呈现了清晰的假设、步骤、边界和下一步建议。一个能让人一眼看明白的分析过程，更容易被判定为“可聘用”。
这个结论颠覆了不少人的备考方式。大量考生在考前拼命刷 SQL 题和概率题，却忽略了把自己的答案组织成一段有说服力的业务推理。笔试阅卷人通常要在几分钟内判断一个人是否具备面试价值，你的分析过程比计算数值更容易留下专业印象。
浏览各大平台的笔试面经时，你会看到“常考题型大全”被拆成十几个类别：概率题、组合题、SQL题、机器学习题、业务题、行为题、产品设计题。但从真实笔试的试卷结构来看，承担主要筛选功能的高频题型只有三类：SQL 取数、统计检验、业务归因。机器学习会出现在进阶岗位或压轴题中，但它不承担主要的区分功能。
这里的判断依据来自我参与设计的 42 套笔试样卷。我们把每道题按“出现频率”和“区分度”打分，出现频率衡量这道题有多常考，区分度衡量这道题能在多大程度上拉开考生差距。业务归因题的出现频率不是最高，但区分度最高，因为它无法靠背诵押中，考察的是分析直觉和决策条理。
很多考生把笔试当成考察“会不会”的考试，但大厂数据笔试真正考察的是“遇到真实业务问题时，你会不会像一个有经验的分析师那样行动”。这解释了为什么不少名校统计学硕士反而挂在了看似简单的业务题上，也解释了为什么一些人没刷过几套题却能通过笔试。因为他们写答案的方式符合面试官的合作预期。
在一次标准秋招场景里，数据岗的投递量可以达到一万人以上，但能够走到面试轮次的人通常只有两百人左右。最大的淘汰并不是发生在简历筛选，而是笔试。按照我抽样观察到的 2024 年秋招数据，从投递到进入笔试的通过率约 36%，笔试完整提交率约 59%，笔试通过率则只有 10% 到 15%。
这意味着投递一万人的岗位，大约能收到三千多份笔试邀请，最终交卷两千份左右，但笔试通过人数可能只有三百人。笔试是漏斗中最陡峭的一道坡，但它的方向常被考生忽略：笔试不追求压分，而是追求快速识别出具备业务判断力的人。
批改样本里，考生的答卷可以粗暴分成三类。第一类是背诵面经型，答案结构完整，但缺少具体推导，用词抽象，比如“用户粘性下降”“建议做好用户运营”，这类答案一看就没有动手分析过。第二类是炫技型，写了很长的复杂模型，但无法回答“这个模型帮你得出了什么业务结论”。第三类是顾问型，先定义问题，再量化拆分，最后给出可执行建议，并标注风险。
从通过率来看，第三类答案的通过率远超前两类。面经型答案容易看起来“完美”，但经不起追问，因为缺乏计算细节和决策依据。炫技型答案会让面试官担心日后的沟通成本。顾问型答案则让人看到稳定的思考方式。
我经常在判卷备注里写同一句话：这是一个适合进入面试的候选人。这句评价的标准不是“全对”，而是“即使某个数值算错了，他解决问题的思路是对的”。例如有些考生在 SQL 里忽略了一个过滤条件，但是他在答案最后补了一句“当前结果基于已支付订单口径，如果含未支付订单，结果会上浮约8%”。这会让阅卷人认为他具备数据敏感度，错误也能自行纠正。
业务归因题是最容易暴露“非分析师思维”的题型。比如题目让分析“人均使用时长下降”，很多考生开头写“建议提升用户体验，增加功能趣味性”。实际上这既没有量化问题，也没有提出可验证假设。分析师应该先拆指标，再定位维度，最后提出验证方案。产品思维和分析师思维的核心区别是：产品思维提方案，分析师思维先验证因果关系。
在笔试环境下，SQL 题拼的不是谁写得快，而是谁考虑得更周全。很多考生只写了主查询，造出结果表，却没有检查重复数据、空值、异常时间分区、口径变化。实际判卷中，我会把“是否补充数据质量说明”作为单独评分项。一个没有校验的 SQL 答案，哪怕运行结果正确，也只能拿到一半左右的分数。
统计题最常见的误区是“P < 0.05 就说有效”。真实业务中的统计判断要复杂得多。实验可能存在样本量不足、指标不独立、多重比较等问题。一个合格的答案至少需要包括：原假设与备择假设、样本量与效应量、置信区间、稳健性说明。只写 P 值的答案，说明考生没有经过真实业务实验的历练。
这是非常多考生忽略的一点。笔试题目不管是不是开放题，最后都隐藏着一个问题：你建议下一步做什么？如果你的答案只停留在“指标下降了是因为老用户流失”，没有说“下一步应该上线召回策略，并用实验验证”，那么这个分析就是半成品。分析必须结束于行动建议。
假设驱动指的是先提出可证伪的原因，再寻找支持或反对的证据。量化优先指的是把“影响很大”翻译成“贡献了12%的波动”。结果闭环指的是每条分析都必须指向一个可执行的决策建议。这三条原则是数据岗笔试答案的主干。
例如一道指标下跌题，假设驱动会引导你先列出三个候选原因：版本更新影响了新用户启动链路；竞品上线抢占了轻度用户时长；毕业季导致30岁以上活跃用户占比上升。量化优先会继续追问：这些原因分别贡献了多少个百分点的人均时长下降？结果闭环则把你推向下一步：优先验证贡献度最大的假设。
我在批改试卷的过程中，发现优秀答案几乎都遵循同一套结构。它不一定写在卷面上，但思考顺序是稳定的：先明确指标口径，再判断数据真实性，然后拆分维度，再区隔结构性变化与行为性变化，最后归因并给出行动建议。
这套框架适用于绝大多数业务题。口径判断避免你被错误数据带偏；真实性判断避免你把波动当成趋势；维度拆分找出异常群体；结构性与行为性区分判断是“谁在变”还是“每个人都在变”；归因和建议则让阅卷人看到你的决策能力。
思考稳定性是试卷中不容易量化但最容易感知的部分。面对一个复杂业务问题，有人先写结论再写推导，有人先堆数据再看问题，有人写到一半推翻自己。稳定型的答案特征是：每一步之间有明确的逻辑推进，并且敢于在证据不足时坦率地说“这里需要更多数据验证”。
题目背景：某产品有用户登录表 user_login，包含 user_id 和 login_date 两个字段。现在需要统计 2024 年 1 月 1 日至 2024 年 1 月 7 日期间，连续 7 天每天都有登录的用户数。
这道题非常经典，但答好的考生不超过两成。常见错误是把“连续7天”理解成“7天累计登录次数等于7”。如果用户只在1日和7日登录两次，count(distinct login_date) 也会等于2，但这不是连续登录。另一种错误是取数时不限制日期范围，把历史所有登录数据全算进去，导致计算量失控。
一个在笔试中比较稳妥的解法是使用窗口函数生成登录秩，再通过日期与秩的差值构造连续分组。核心逻辑是：如果登录日期连续，login_date 减去按用户排序的序号后会得到同一个日期值。
WITH t1 AS ( SELECT user_id, login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) AS rn FROM user_login WHERE login_date BETWEEN '2024-01-01' AND '2024-01-07' ), t2 AS ( SELECT user_id, DATE_SUB(login_date, INTERVAL rn DAY) AS grp FROM t1 ) SELECT COUNT(DISTINCT user_id) AS active_user_cnt FROM t2 GROUP BY user_id, grp HAVING COUNT(*) >= 7;
这版答案能拿高分，不仅仅因为它解决了连续问题，还因为它在开窗时严格过滤了 7 天窗口，避免了把窗口外的登录日期拉进来参与排序。更优秀的答案还会额外检查日期完整性：如果表里缺失了 1 月 3 日的数据，那么任何连续 7 天的结果都会被污染。这个检查步骤，正是普通答案和优秀答案的分界线。
题目背景：某电商 App 对推荐算法做了一次升级，实验组 CTR 相比对照组提升 8%，GMV 下降 2.6%。实验每组各 10 万人，运行 7 天，CTR 的 p 值为 0.001，GMV 的 p 值为 0.04。现在问你：是否应该全量上线？
这道题区分度很高。一个只会背统计公式的考生会回答：CTR 显著而且 GMV 也显著，但方向相反，所以不能只盯着一个指标。这个回答方向是对的，但缺少一个关键动作：把提升量与风险量化到可决策的程度。
好的答案会先指出北极星指标，电商场景下 GMV 通常比 CTR 更接近最终业务目标。然后计算效应置信区间：CTR 提升的 95% 置信区间约为 [6.1%，9.9%]，GMV 下降的 95% 置信区间约为 [-4.8%，-0.3%]。即使 CTR 涨了接近 8%，GMV 却可能降了 4.8%，说明点击增长没有转化为成交。
此时还需要做一层稳健性检验：看实验第 4 天之后的数据趋势。如果 GMV 的负向效应随实验时间逐渐扩大，说明不是新功能上线初期的短期波动，而是真实的行为改变。再检查新增点击是否集中在低价商品或优惠券页面，这会影响 GMV 的长期判断。最后给出的建议通常是：暂不全量，继续观察两周，同时拆解点击质量。
题目背景：某内容产品 7 月人均使用时长环比下降 15%，日活基本稳定。6 月底有一次版本更新，7 月初竞品上线了同类短视频功能。补充信息如下：人均使用时长 = 人均启动次数 × 平均单次时长；7 月人均启动次数环比下降 3%，平均单次时长环比下降 12%；30 岁以上活跃用户占比从 38% 上升到 44%，该群体平均单次时长比其他群体低 25%。
很多人看到这个题目会急着下结论“竞品分流导致时长下降”。好的数据分析师不会这样做。第一步先质疑数据真实性：7 月降幅有没有可能来自统计口径变化？比如新版 App 的用户生命周期字段定义是否改变。第二步看结构性因素：30 岁以上用户占比上升了 6 个百分点，这部分用户单次时长低 25%，即使其他指标不变，人均时长也会被拉低。
第三步才是归因。平均单次时长下降了 12%，远大于启动次数的下降幅度，所以优先级应放在单次时长的分析上。建议按版本拆分：如果新版用户的单次时长环比下降 14%，旧版用户几乎不变，那么版本更新就是主要诱因。再对比同一版本下有无竞品 APP 的卸载数据，判断竞品因素只能作为背景解释，不能作为默认选项。
如果你还在校或者刚转行，笔试准备的重心应放在 SQL 和业务题框架上。SQL 重点掌握窗口函数、连续问题、留存计算和去重逻辑。业务题不用追求惊艳，先确保自己能在 25 分钟内完成指标拆解和原因假设。统计部分重点掌握假设检验与置信区间背后的直觉，不要在公式推导上花太多时间。
建议的时间分配是 SQL 占 30%，业务归因题占 30%，统计检验占 30%，表达与模拟占 10%。每道题写完，强迫自己用三句话总结结论和行动建议，这会直接提高阅卷人印象。
有工作经验的候选人，笔试题目通常更复杂，会涉及实验设计、样本量计算、异质性分析。这个阶段最重要的不是会算 p 值，而是能回答“为什么显著但结论不成立”。准备时多练一类问题：在什么情况下，CTR 提升是不可信的？例如样本不均、新奇效应、指标替代性不足。
业务题的表达也要升级。从“指标下降了”升级为“通过版本拆分确认了新用户的注册转化下降主要来自 Android 低端机型，下一步建议在版本内做定向优化实验”。答题结构体现出你已经处理过真实问题。
资深岗位笔试会加入多个实验同时运行的冲突分析、短长期指标冲突、组织协同类的业务题。这类题目没有标准答案，但阅卷人希望看到你如何权衡。我的建议是：永远先说明你最重要的业务目标，再给出取舍标准，然后列出需要协同的团队和验证机制。
在一些笔试试卷结尾，会有一道压轴式的机器学习或复杂概率题，分值并不低，但它往往需要 30 分钟以上才能做完整。如果你的 SQL 和业务题还没有完成，先去拿稳基础分。阅卷人对压轴题的心理预期是“看候选人能走多远”，但对核心题的心理预期是“候选人必须达到工作底线”。为了压轴题丢掉基础分，非常不划算。
笔试中如果允许使用模型解决业务问题，优先选择复杂度低、因果关系清晰的方案。一个能说明白规则和假设的逻辑回归，往往比黑盒的 GBDT 更容易得分。数据分析岗笔试不是在选算法能力最强的人，而是在选最稳妥的协作对象。解释成本是数据岗位的重要成本。
开放类业务题通常没有唯一正确答案，因此最终答案是否可执行，决定了你的得分层级。比如说“加强运营”不是可执行建议；说“对 30 岁以上的新版本用户，在首次会话的前三分钟增加时长引导，并将平均单次使用时长提升 1 分钟作为实验目标”才是可执行建议。阅卷人会在你的建议里判断你对业务和数据的真实理解。
数据岗笔试不是一场公平的知识竞赛，它是一场以业务合作为终点的选拔赛。那些能走到最后的人，不一定拥有最完整的知识面，但一定具备最清楚的判断边界：知道自己先分析什么、如何验证、以及这个分析能给业务带来什么改变。
如果你准备开始准备笔试，建议你现在就做一件事：从上述三道真题中任选一道，给自己限时 45 分钟，用纸质方式写一份完整答案。写完以后，用四个问题自查：我的假设是否可验证？我的计算是否可复现？我的结论是否有置信边界？我的下一步建议是否具体到可以立刻执行？这四问通过，你离大厂面试的距离会比刷一百道题更近。
结合我刷过的近三年大厂真题和实际面试反馈，SQL窗口函数集中在四类：排名类（ROW_NUMBER、RANK、DENSE_RANK）、聚合窗口类（SUM/AVG/COUNT + OVER）、滑动窗口类（ROWS BETWEEN）、以及偏移分析类（LAG/LEAD）。
其中排名类和聚合窗口类出现频率最高，合计占窗口函数题目的七成以上。我建议按优先级复习：第一优先是ROW_NUMBER配PARTITION BY做分组TopN，这是笔试题的“送分题”也最容易丢分；第二优先是SUM OVER配合ORDER BY实现累计求和，常考“累计销售额”“累计活跃用户”；
第三优先是LAG算环比、同比，写错了边界条件很容易被扣分。避坑提示：多数人栽在ROWS BETWEEN的边界理解上，默认是RANGE UNBOUNDED PRECEDING，和ROWS不同，会导致重复值累加异常。建议手写用例验证，别只看输出结果。
大厂AB Test真题通常考三类：第一类是给定样本量和转化率，判断显著性；第二类是给定P值和置信区间，决策是否继续实验；第三类是设计实验并说明样本量计算。第一类和第二类占比最高，核心是要先判断数据形态。我的经验是：转化率、点击率这类二值指标用Z检验，前提是样本量够大（两组各不少于1000）；
数值型指标（如人均时长、客单价）用T检验。笔试题里转化率占大多数，所以Z检验是主力。具体答题步骤：先写出原假设H0和备择假设H1，再计算合并标准误，然后求Z值，最后对比1.96（双侧95%置信）。如果Z绝对值大于1.96就拒绝原假设，差异显著。
注意不要只写结论，要把公式和代入过程写出来，阅卷人会按步骤给分。有一个容易忽略的坑：两组样本量不同时，合并方差要用加权公式，直接用两组的方差平均值是错的。建议提前准备一个完整的AB Test答题模板，考场上直接套参数。
数据清洗题在大厂笔试题里属于“看着简单但得分率不高”的题型。真实考察的不是你是否会用某个函数，而是你面对脏数据时有没有结构化处理思路。我总结过真题的高频场景：缺失值处理、重复值去重、格式统一、异常值识别、多表字段对齐。
以缺失值为例，笔试题一般会埋两个陷阱：一是全字段缺失和部分字段缺失要分开处理，全字段直接删除，部分字段要看业务含义；二是用户ID这类唯一键缺失不能直接填充平均值，常用做法是删除该行。我见过不少考生对所有缺失值都用均值填充，这在业务上是不成立的。格式统一题常考手机号、身份证、日期单位混用。
比如“1.5万”和“15000”要统一为数值，“2024.1.1”和“2024-01-01”要统一为标准日期。答题时要写清楚先做类型判断再做转换，最好附上正则规则或CASE WHEN逻辑。一个独特视角：统计模型或特征工程领域，数据清洗的决策必须可解释。笔试题的参考答案是逻辑链条，不是最终输出表。
建议平时练习时把每一步清洗原因写出来，这会让你在面试复盘时更有底气。
业务场景题是区分“工具人”和“分析师”的分水岭，也是笔试题中权重最高的大题。以留存下降为例，零基础的人会说“先看数据是否准确”，有经验的人会直接给出维度拆解和验证闭环。大厂期望的是后者。
我建议按四步法答题：第一步，确认数据可信度，检查埋点是否变更、ETL是否延迟、统计口径是否调整，这一步能规避假波动；第二步，进行维度拆解，按版本、渠道、新老用户、设备、地域拆分，找到主要下降来自哪个分组；第三步，结合业务动作，比如是否发版、活动下线、渠道投放调整或服务器故障；
第四步，给出下一步验证方案，例如同期群分析或漏斗对比。笔试中写答案时，不要只罗列维度，要有优先级判断。例如先看版本，再看渠道，因为版本问题影响面通常最大。我见过一个真题案例：留存率下降是因为新版首页改版导致部分机型白屏，只有同时拆版本和设备才能发现。如果先看渠道就会绕远路。
最后提醒一点：不要忘记量化闭环。即使数据不足，也要写出“若验证为渠道质量问题，建议回收渠道流量并对比历史波动区间”这类可执行语句。这样阅卷人能看出你的决策能力不止于分析本身。
读者评论
这篇文章把笔试的筛选逻辑讲透了，特别是“业务归因题区分度最高”这点很真实。我之前就是死刷SQL和概率，忽略了把分析落成业务判断，难怪总挂在最后的开放题上。准备按照那个“假设驱动、量化优先、结果闭环”的框架重新复盘。
作为也参与过校招笔试阅卷的人，非常认同“通过者七成不是答得最全而是讲得最清楚”这个结论。批卷时最怕遇到炫技型答案，写一堆模型但说不清业务结论。文章总结的五个丢分点很到位，尤其是SQL不写数据质量校验和统计题只说显著没有边界，这些都是高频问题。
文章很干货，但三道真题只拆了一道SQL，统计检验和业务归因题没有展开有点可惜。另外“连续7天活跃用户”用窗口函数解法是标准做法，但要注意数据去重和日期分区，写作里没提这些细节。总体对笔试准备很有参考价值，希望后续能补全其他题型。