2023年春招那阵子数据分析岗的笔试卷子真是五花八门。有的公司上来让你做行测有的直接扔过来一份脱敏数据让你现场写SQL还有的干脆整一套“业务场景AB实验设计”的综合题。我陆续参加了几场其中“小满”的第一批笔试给我留下的印象最深——它不考死记硬背全部题目都围绕真实业务场景展开SQL、Python、业务思维、统计常识都有涉及。这套题做下来我从“刷题选手”被迫切换成“业务分析师”视角收获挺大。这篇就把我复盘整理的笔试全流程、核心考点、踩坑点和复习建议完整写下来给准备校招数据分析岗的朋友做个参考。这套题网上没有完整原题但结合当时参加的同学反馈和春招市面上的主流题型基本能还原个八九成。我会把“小满”这批笔试涉及的知识模块、典型题目、解题思路、标准答案要点全部拆开讲同时补充一批我在刷题和实战中总结的通用技巧。无论你接下来面哪家公司的数据分析岗这套思路都能直接复用。1. 整体设计思路与考察逻辑拆解1.1 一份合格的数据分析岗笔试到底想筛什么人先说个容易被忽略的点笔试不是只看你会不会写代码更重要的是考察你有没有“业务感”。很多同学在准备阶段狂刷LeetCode和SQL题但到了真实笔试会发现题目本身的代码难度往往不高卡住你的反而是“不知道该算什么、为什么要这么算”。小满这批笔试的整体结构大概是这样的SQL题占30%Python数据处理占20%业务案例分析占30%统计与AB实验占20%。和市面上大厂数据分析岗的笔试题型分布基本一致。这也符合行业里对数据分析师的定位——你不是纯技术岗也不是纯业务岗而是连接数据和决策的中间层。理解了这个定位你就能读懂笔试的考察逻辑SQL考察的是取数能力和数据理解力——能不能快速从表里整理出业务方要的指标。Python考察的是数据清洗和特征构造能力——拿到脏数据能不能处理好。业务案例分析考察的是问题拆解能力——面对一个模糊问题能不能把它拆成可执行的分析步骤。统计与AB实验考察的是科学决策能力——能不能用严谨的方法验证业务假设。这四个模块正好对应数据分析师日常工作的完整闭环取数、清洗、分析、验证。1.2 为什么“小满”这类平台型公司特别重视业务结合度“小满”本身是金融科技领域的公司业务数据涉及信贷、风控、用户增长等场景。金融类数据分析岗和电商、内容社区的数据岗有个明显区别对业务结果的要求更谨慎必须对数字背后的事实负责。比如同样是做一个用户流失分析电商公司可能只要定位流失人群做召回金融公司却要结合逾期风险、监管合规、资金成本等因素做综合判断。这决定了笔试题目不会让你单纯算一个数而是给你一组相互关联的表、一段业务背景说明、几个待回答的业务问题让你在有限时间内完成一套“小闭环”分析。这和实际工作场景几乎是复刻的——真实工作中没有人会告诉你“这单分析要用什么方法”所有方法选择都需要你自己基于业务背景判断。所以复习数据分析岗笔试不能只“刷题”必须有意识地训练“拿到一个问题先判断业务类型再决定分析路径”的思维模式。2. SQL笔试核心考点与真题思路还原2.1 高频考点清单窗口函数、多表关联、连续问题小满这批笔试SQL部分一共有4道题覆盖了数据分析面试最高频的几类考点。我先把高频考点列个清单再逐一展开窗口函数ROW_NUMBER、RANK、SUM OVER、LAG/LEAD多表JOIN对业务口径的影响LEFT JOIN vs INNER JOIN连续N天问题经典中的经典分组TopN问题留存率计算次日/7日/30日先看第一道题典型的“分组TopN”给定一张用户还款记录表字段包括user_id、repay_date、repay_amount要求计算每个用户还款金额最高的前3天。这题的常规解法是窗口函数SELECT user_id, repay_date, repay_amount FROM ( SELECT user_id, repay_date, repay_amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY repay_amount DESC) AS rn FROM repay_records ) t WHERE rn 3;这题有进阶版本如果要求“每个用户每个季度还款金额最高的前3天”需要在窗口函数里加一个季度分组条件。很多同学栽就栽在PARTITION BY子句上——只按用户分组忘了加季度维度。2.2 连续问题怎么破连续登录/连续还款天数连续类问题几乎是数据分析笔试的必考题。小满这批笔试的版本是给定用户登录日志表login_loguser_id, login_date求2023年2月每个用户的最大连续登录天数。这类题标准解法是“日期减行号”——用登录日期减去按用户分组的行号或排名如果日期是连续的差值就是恒定值然后按差值分组计数即可SELECT user_id, MAX(continue_days) AS max_continue_days FROM ( SELECT user_id, date_sub(login_date, rn) AS diff_group, COUNT(*) AS continue_days FROM ( SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM login_log WHERE login_date BETWEEN 2023-02-01 AND 2023-02-28 ) t1 GROUP BY user_id, date_sub(login_date, rn) ) t2 GROUP BY user_id;这里有个小细节值得注意如果同一天有多次登录记录需要先去重DISTINCT否则行号会错位连续天数的计算结果全是错的。这个坑我当年在真实面试中踩过——当时登录日志表有重复数据我没去重直接跑结果连续登录天数被虚增了。从那以后我只要看到“明细表”第一反应就是先检查重复值。2.3 留存率计算SQL题的压轴大戏留存率这类题在小满笔试里换了个业务外衣给定用户激活表user_id, activate_date和用户活跃表user_id, active_date求2023年1月激活用户的次日留存率、7日留存率。我知道很多人看到这道题会先懵一下不知道“次日留存”到底怎么定义。这里给新手朋友解释一下次日留存指的是“某天激活的用户中有多少人在第二天还活跃”7日留存就是第7天还活跃的用户占比。计算公式是SELECT t1.activate_date, COUNT(DISTINCT t1.user_id) AS activate_cnt, COUNT(DISTINCT t2.user_id) AS retention_cnt, COUNT(DISTINCT t2.user_id) / COUNT(DISTINCT t1.user_id) AS retention_rate FROM activation_table t1 LEFT JOIN active_table t2 ON t1.user_id t2.user_id AND DATEDIFF(t2.active_date, t1.activate_date) 1 WHERE t1.activate_date BETWEEN 2023-01-01 AND 2023-01-31 GROUP BY t1.activate_date;注意这里用的是LEFT JOIN而不是INNER JOIN因为我们要保留没有活跃记录的用户分母不能丢。这是留存率计算最经典的易错点——用INNER JOIN会把没有次日活跃的用户丢掉导致留存率虚高。7日留存把DATEDIFF改成7即可。3. Python数据分析与清洗实操题拆解3.1 数据清洗题pandas处理脏数据的标准动作小满笔试Python部分很少让你写复杂算法重点在pandas数据处理。题目大概长这样给出一份含缺失值、重复值、异常值的用户订单表包含字段order_id, user_id, order_date, order_amount, city要求在20分钟内完成清洗并输出每个城市的订单总量和订单金额总量。做这类题一定要形成肌肉记忆按照固定顺序处理数据先看数据规模和字段类型data.info()了解有没有明显异常。处理重复值drop_duplicates()按order_id去重。处理缺失值先看缺失比例如果order_amount缺失就填充或删除如果city缺失就按user_id关联其他表补齐。处理异常值order_amount明显为负或超过合理阈值的标记出来人工判断。统一时间格式pd.to_datetime()方便后续按时间聚合。我当时写的核心代码大概是这样的import pandas as pd df pd.read_csv(order_table.csv) df[order_date] pd.to_datetime(df[order_date]) # 去重 df df.drop_duplicates(subsetorder_id) # 缺失值处理金额缺失用中位数填充 df[order_amount] df[order_amount].fillna(df[order_amount].median()) # 异常值处理金额小于0的置为0 df.loc[df[order_amount] 0, order_amount] 0 # 按城市聚合 result df.groupby(city).agg( order_cnt(order_id, count), order_amount_sum(order_amount, sum) ).reset_index()这类题目本身不难真正的分水岭在于你对pandas API的熟练度。如果你写代码时还要翻文档那时间肯定不够。建议大家在笔试前把pandas的核心方法过一遍groupby、merge、apply、pivot_table、fillna、drop_duplicates这几个高频操作做到闭着眼睛能写。3.2 一份真实的SQLPython结合题用pandas做RFM用户分层和小满同期出现的一道好题我把原题分享给大家给定一份用户订单数据user_id, order_date, order_amount要求用Python实现RFM分层Recency最近购买间隔、Frequency购买频率、Monetary购买金额输出每个用户的RFM分数和分层结果。这是个经典的“SQL能算但Python更好写逻辑”的题目。解题思路分三步第一步计算每个用户的R、F、M值import pandas as pd import numpy as np # 假设df是原始订单表参考日期为2023-02-28 ref_date pd.to_datetime(2023-02-28) rfm df.groupby(user_id).agg( recency(order_date, lambda x: (ref_date - x.max()).days), frequency(order_id, count), monetary(order_amount, sum) ).reset_index()第二步给每个字段打分。常用方法是四分位数打分——比如R值越小越好F和M越大越好按顺序分成1到4分rfm[R_score] pd.qcut(rfm[recency], 4, labels[4, 3, 2, 1]) rfm[F_score] pd.qcut(rfm[frequency], 4, labels[1, 2, 3, 4]) rfm[M_score] pd.qcut(rfm[monetary], 4, labels[1, 2, 3, 4])注意R分数和F、M分数的方向是反的——间隔越短分数越高。这个方向搞反了整个RFM分层就全错了。第三步按业务规则分层。常见的规则是R和F都高的是重要价值用户M高但R低的是重要挽回用户等。这道题考查的不只是pandas用法更是对“数据分析方法论”的掌握程度。如果你连RFM是什么都不知道代码写得再漂亮也拿不到分。这就引出了笔试准备的核心思路——分析方法论和代码能力是一体两面缺一不可。3.3 可视化题matplotlib和seaborn出图的速度与规范Python部分的最后一道题通常涉及可视化。小满的版本是基于清洗后的订单数据画一张各城市订单金额的对比图并指出哪个城市业务贡献最高。这类题不只是画图还要考察你是否能“看图说话”。我当时画了个seaborn柱状图import matplotlib.pyplot as plt import seaborn as sns plt.figure(figsize(10, 6)) sns.barplot(dataresult, xcity, yorder_amount_sum) plt.title(各城市订单金额对比) plt.xticks(rotation45) plt.tight_layout() plt.savefig(city_order_amount.png)做题时的经验教训是可视化一定要先明确“图给谁看”。如果是给管理层看的图要简洁、省色、突出结论如果是给分析团队做探索用的可以信息密度高一点。笔试中建议直接标注出数值、加上标题让阅卷人一眼看到你要表达的结论。还有一个小技巧出图前先用groupby确认聚合结果再画图避免画出来的图和数据不一致。4. 业务案例分析题从模糊问题到可执行分析方案4.1 案例分析题的标准解题框架拆解量化落地业务案例分析题是数据分析笔试题里最让人头疼的部分因为它没有标准答案又最能拉开考生差距。小满这批笔试的案例分析题大概是这样的背景小满APP近一个月的用户活跃度出现明显下降尤其是新用户的次日留存率从35%下降到28%。请设计一套分析方案找出活跃度下降的原因并提出可落地的改进建议。这种问题一看就很“真实”但也很“模糊”。和代码题不同这类题没有唯一正确解阅卷人看的是你的分析思路是否合理、是否结构化、是否可落地。我的解题框架固定分四步第一步明确问题定义。这里要区分“是什么下降了”——是整体活跃下降还是某个功能模块活跃下降是新用户留存下降还是老用户活跃下降题目里已经给出了一个线索新用户次日留存从35%降到28%但还要进一步定义清楚。我会先把问题拆成几个子问题哪些用户群下降最明显下降是从什么时候开始的是新增用户变差还是存量用户变差第二步提出假设并量化。这一步是案例分析题的核心。基于业务常识列出可能的下降原因每个原因都要有可验证的指标和应对的数据表渠道质量变差新用户的来源渠道结构是否变化各渠道的次日留存率同期对比如何产品功能改版近期是否上线了新版本、改了首页或核心流程竞品或外部环境影响同期是否有竞品拉新活动市场投放策略调整投放量级、投放渠道、投放人群是否有变化技术bug或体验问题关键页面是否出现加载失败、支付异常等故障每个假设都必须落到“用什么数据、看什么表、对比什么指标”上。比如“渠道质量变差”就对应渠道明细表和渠道留存表对比每个渠道在下降前后的留存变化找Delta最大的渠道。第三步确定分析优先级。假设列了一大堆不可能全做。用“影响程度×发生概率”来排序优先验证影响最大、最可能发生的原因。在实际工作中这叫“用最小成本找到最大根因”。第四步输出可落地的建议。写完原因之后一定要有改进建议且建议要具体到“做什么、预期效果如何、怎么验证”。比如针对渠道质量变差可以建议“暂停低质渠道投放、将预算挪向高留存渠道并建立渠道质量日报监控”。这样阅卷人才能判断你是真正理解了问题而不是在背书上看到的分析框架。4.2 指标拆解的实战示例案例分析题还会考一类具体的“指标拆解”题小满笔试的版本是某天支付成功率下降了2个百分点请定位原因。这种题本质上考的是“漏斗分析”能力。支付成功率的定义是支付成功人数/发起支付人数所以拆解公式支付成功率 支付成功人数 / 发起支付人数分子和分母都可以继续往下拆。分母发起支付人数的下降本身就会导致成功率下降——如果更多人发起支付但没成功那可能是支付渠道出了问题如果发起支付人数少了可能是入口曝光少了、用户点击意愿低了。分子和分母再分别按用户类型、设备类型、支付渠道、地域维度拆分对比前一天、前一周同一天就能定位到“哪个维度、哪个环节”出了问题。一个关键技巧遇到率值类指标异动永远先拆分子分母看绝对值变化再看是哪个细分维度贡献了主要Delta。很多人遇到率值下降就慌了急着猜原因其实是基础的分母变了导致率值被稀释。4.3 指标体系设计题的作答套路小满这批笔试还有一个更进阶的题目给出一段业务描述小满APP计划推出一款“智能理财助手”功能请为该功能设计一套指标体系用于评估功能上线后的效果。这套题的答题思路不要堆砌指标而是按“漏斗分层”的逻辑组织指标。分为三个层级一级指标功能北极星指标比如“智能理财助手周使用用户数”这是衡量功能是否成功的最核心指标。二级指标用户体验类指标包括开通率、使用频次、功能停留时长、次日再次使用率。三级指标业务效果类指标包括用户资产提升金额、理财买入转化率、付费用户占比等。这样分层设计的逻辑是一级指标看整体二级指标看体验三级指标看商业价值三层指标形成“用户用→用户觉得好用→用户产生业务价值”的完整闭环。这正好是数据分析师在工作中设计报表/看板的标准思路——先定北极星指标再逐层拆解子指标。5. 统计与AB实验题数据科学决策的地基5.1 假设检验和AB实验的综合题怎么答统计专业知识是区分“只会取数的数据分析师”和“能科学决策的数据分析师”的关键。小满笔试统计部分有一道综合题产品经理提出一个新版首页方案认为可以提升用户点击率。现有数据对照组点击率10%样本量5000实验组点击率10.6%样本量5000问是否应该全量上线新方案请给出你的统计分析和决策建议。这道题考的是AB实验最基本的完整流程计算显著性、判断是否有统计意义、结合业务实际做决策。答案分三部分第一先算p值或者置信区间。用双样本比例检验Z检验在Python里可以直接用statsmodelsfrom statsmodels.stats.proportion import proportions_ztest count [530, 500] # 实验组点击成功数, 对照组点击成功数 nobs [5000, 5000] # 两个组的样本量 z_stat, p_value proportions_ztest(count, nobs) print(fZ统计量: {z_stat:.4f}, P值: {p_value:.4f})经计算p值大概在0.31左右远大于0.05说明实验组和对照组的点击率差异在统计上不显著。也就是说这0.6个百分点的提升很可能是抽样误差造成的。第二结合业务实际给出决策建议。虽然统计不显著但不一定直接否定方案——需要考虑这个改动是否有长期价值比如用户体验、品牌感知等非量化指标。如果这些方面没有明显的负面反馈可以考虑扩大样本量再做一轮实验如果改动成本很低也可以灰度放量继续观察。这道题的完整作答体现了数据分析师的核心能力之一——“不完只看结果还要看结果是否可信、代价是否值得”。这类题没有标准答案但一定要把“统计显著性”和“业务显著性”分开讲再给出一个有逻辑的决策。统计显著性回答“差异是不是偶然”业务显著性回答“差异值不值得做”两者缺一不可。5.2 无监督学习和其他机器学习常识除了AB实验统计模块还会考一些机器学习基础尤其是聚类相关的无监督学习。小满笔试有一道题问如何对用户进行分群以便制定差异化运营策略请简述至少两种分群方法。这道题最稳妥的答法是先讲K-means聚类的标准流程——确定特征如消费金额、消费频次、活跃天数、标准化、选K值手肘法或轮廓系数、聚类、解读簇特征。再讲PCA降维和聚类结合——如果特征太多可以用PCA降到二维或三维再聚类方便可视化。还可以提到RFM分层作为一种基于业务规则的分群方法分群结果更易解释适合业务方快速使用。另一类高频考点是特征构造和特征选择。比如遇到回归类题目特征中既有数值型又有分类变量你要能说清楚数值特征要不要做标准化分类特征用label encoding还是one-hot encoding缺失值用什么策略填充这些都直接在真实工作中用得到也是面试官区分“刷题型选手”和“实战型选手”的地方。5.3 离线数据分析常用工具的加分项如果笔试或面试中问到你做过哪些离线数据分析可以主动提工具链用SQL和Python做离线数据清洗、加工和聚合用spark处理海量数据场景用DBeaver这类数据库客户端连接各种数据源做可视化查询。这些工具不一定每道笔试都会考但在“项目经验介绍”和“开放性题目”中主动提到能显著提升专业感。我个人的笔试答题习惯是SQL题目尽量用窗口函数精简写法Python题目先写import、再写主体逻辑、最后补充异常处理工具类题目就结合“我实际在XX项目中用过”来展开哪怕那个项目很小也能让答案显得具体可信。6. 完整复盘与冲刺建议笔试前一周我做了什么6.1 笔试前7天的复习计划安排我知道很多人是临时抱佛脚型的选手但数据分析岗笔试这东西突击3天和系统准备7天差距非常大。我复盘了自己准备小满笔试那一周的计划直接分享出来供参考第1-2天刷SQL。重点练窗口函数、连续问题、留存率、分组TopN每天10道题做题时强制用窗口函数而不用子查询训练写复杂SQL的肌肉记忆。第3天刷pandas。把groupby、merge、apply、pivot_table这几个高频操作各练10遍先跑一遍官方文档示例再合上文档默写核心代码。第4天过一遍统计知识。重点是假设检验流程、p值含义、AB实验样本量计算、K-means聚类原理。不用背公式要能讲清“为什么需要它”“什么场景用”。第5天业务案例分析专项。找5道公开的案例分析真题练习“拆解问题→提出假设→量化验证→给出建议”这一整套框架。第6天模拟一套完整笔试。按真实笔试时间计时中间不查资料完完整整做一套题体验考场节奏。第7天复盘错题重点看之前反复错的类型准备一下自我介绍和项目复盘因为很多公司笔试完很快就是一面前脚接后脚。这个计划的核心逻辑是先保基础分SQL和Python再拉高上限业务分析和统计。如果你的SQL基础已经很扎实可以直接把第1-2天压缩成1天把省出来的时间投到业务案例题上。6.2 应试技巧与时间分配先拿分后抠细节笔试现场的时间分配也是决定成败的关键。小满这批笔试一共约90分钟我的策略是前10分钟通读所有题目标记出“会做且分高”“会做但耗时”“完全没思路”三类题。先做SQL的前两题简单题先拿分建立信心控制在15分钟内。再做Python数据清洗题控制在20分钟内这类题只要按流程走基本能拿满分。留35分钟给业务案例分析题这是最拉分的模块不能因为前面的代码题耗时而被压缩。最后5分钟检查主要扫一眼SQL的JOIN条件、Python的字段名是否有拼写错误、案例分析有没有漏掉步骤。这个时间分配的精髓是永远不要在一道题上死磕超过15分钟。如果一道SQL题10分钟写不出来先跳过做完全部再回头补。大多数笔试不指望你答满分而是看你在有限时间内能拿到多少分。注意案例分析题的时间一定不能省。哪怕代码题空一道案例分析题也至少要写完“问题定义→假设列表→验证方案→落地建议”这个完整框架因为这类题写一半和写完整得分差距极大。6.3 复盘时发现的高频丢分点希望你别踩我批改过不少同学模拟卷也复盘过自己的答题过程发现有四个丢分点真的是“高频又冤大头”第一SQL不明确定义业务口径。比如“成交量”是订单量还是支付成功量“用户数”是UV还是去重设备数这些口径必须在SQL里明确体现否则计算结果无意义。第二Python代码能跑但逻辑粗糙。比如不做重复值处理就直接聚合结果被重复数据污染最后分析结论完全跑偏。第三业务案例分析缺少量化。很多人只写“拉取用户分群数据看看”不写具体看什么表、算什么指标、怎么判断。这种回答在阅卷人眼里等于没答。第四AB实验只看p值不论业务。甚至有人把“p值小于0.05”简单等同于“一定有效”忽略置信区间、效应量、业务成本这些关键维度。这几个问题本质上都是同一个症结——把数据分析当成了“做题”而不是把它当成“解决业务问题的手段”。笔试前一定要提醒自己分析不是终点决策才是。6.4 笔试后如何顺势准备面试笔试结束后建议趁热打铁把笔试题里自己不太熟练的模块整理成错题本。小满这类公司笔试和面试通常间隔比较短题面和面试问题经常高度相关——笔试里考过RFM分层面试里很可能追问“RFM分层结果怎么和运营活动配合”笔试里考过留存率面试里可能会让你现场设计一个提升次日留存的实验方案。我笔试后必做的一件事是把每道题重新用文字写一遍完整的解题思路然后对着自己讲一遍。这个过程看起来笨但能帮你把“会做题”变成“会讲题”而“会讲题”正是面试环节最需要的核心能力。面试官问“你当时为什么这么分析”的时候你能清晰说出思考过程就赢过一多半候选人了。另外面试前一定把自己的项目经历里“数据清洗”“SQL取数”“AB实验”“业务洞察”这几个环节的细节补充完整。数据分析岗面试问项目几乎必问“你在这个项目里具体负责哪部分”“用了什么方法”“遇到什么困难怎么解决的”——这本质上还是在考察你处理数据的完整思路和表达清晰度。最后再分享一个小技巧笔试答题中凡是涉及率值留存率、转化率、成功率的计算一定顺手写下口径定义比如“次日留存次日活跃用户/当日激活用户”。这一行字不费时间但能让阅卷人确认你真的理解业务含义而不是死套公式。我在多次笔试中验证过这个细节虽然不起眼但确实能降低被扣“逻辑不清”分数的概率。
数据分析笔试全攻略：SQL、Python、业务思维与AB实验备考指南
2023年春招那阵子数据分析岗的笔试卷子真是五花八门。有的公司上来让你做行测有的直接扔过来一份脱敏数据让你现场写SQL还有的干脆整一套“业务场景AB实验设计”的综合题。我陆续参加了几场其中“小满”的第一批笔试给我留下的印象最深——它不考死记硬背全部题目都围绕真实业务场景展开SQL、Python、业务思维、统计常识都有涉及。这套题做下来我从“刷题选手”被迫切换成“业务分析师”视角收获挺大。这篇就把我复盘整理的笔试全流程、核心考点、踩坑点和复习建议完整写下来给准备校招数据分析岗的朋友做个参考。这套题网上没有完整原题但结合当时参加的同学反馈和春招市面上的主流题型基本能还原个八九成。我会把“小满”这批笔试涉及的知识模块、典型题目、解题思路、标准答案要点全部拆开讲同时补充一批我在刷题和实战中总结的通用技巧。无论你接下来面哪家公司的数据分析岗这套思路都能直接复用。1. 整体设计思路与考察逻辑拆解1.1 一份合格的数据分析岗笔试到底想筛什么人先说个容易被忽略的点笔试不是只看你会不会写代码更重要的是考察你有没有“业务感”。很多同学在准备阶段狂刷LeetCode和SQL题但到了真实笔试会发现题目本身的代码难度往往不高卡住你的反而是“不知道该算什么、为什么要这么算”。小满这批笔试的整体结构大概是这样的SQL题占30%Python数据处理占20%业务案例分析占30%统计与AB实验占20%。和市面上大厂数据分析岗的笔试题型分布基本一致。这也符合行业里对数据分析师的定位——你不是纯技术岗也不是纯业务岗而是连接数据和决策的中间层。理解了这个定位你就能读懂笔试的考察逻辑SQL考察的是取数能力和数据理解力——能不能快速从表里整理出业务方要的指标。Python考察的是数据清洗和特征构造能力——拿到脏数据能不能处理好。业务案例分析考察的是问题拆解能力——面对一个模糊问题能不能把它拆成可执行的分析步骤。统计与AB实验考察的是科学决策能力——能不能用严谨的方法验证业务假设。这四个模块正好对应数据分析师日常工作的完整闭环取数、清洗、分析、验证。1.2 为什么“小满”这类平台型公司特别重视业务结合度“小满”本身是金融科技领域的公司业务数据涉及信贷、风控、用户增长等场景。金融类数据分析岗和电商、内容社区的数据岗有个明显区别对业务结果的要求更谨慎必须对数字背后的事实负责。比如同样是做一个用户流失分析电商公司可能只要定位流失人群做召回金融公司却要结合逾期风险、监管合规、资金成本等因素做综合判断。这决定了笔试题目不会让你单纯算一个数而是给你一组相互关联的表、一段业务背景说明、几个待回答的业务问题让你在有限时间内完成一套“小闭环”分析。这和实际工作场景几乎是复刻的——真实工作中没有人会告诉你“这单分析要用什么方法”所有方法选择都需要你自己基于业务背景判断。所以复习数据分析岗笔试不能只“刷题”必须有意识地训练“拿到一个问题先判断业务类型再决定分析路径”的思维模式。2. SQL笔试核心考点与真题思路还原2.1 高频考点清单窗口函数、多表关联、连续问题小满这批笔试SQL部分一共有4道题覆盖了数据分析面试最高频的几类考点。我先把高频考点列个清单再逐一展开窗口函数ROW_NUMBER、RANK、SUM OVER、LAG/LEAD多表JOIN对业务口径的影响LEFT JOIN vs INNER JOIN连续N天问题经典中的经典分组TopN问题留存率计算次日/7日/30日先看第一道题典型的“分组TopN”给定一张用户还款记录表字段包括user_id、repay_date、repay_amount要求计算每个用户还款金额最高的前3天。这题的常规解法是窗口函数SELECT user_id, repay_date, repay_amount FROM ( SELECT user_id, repay_date, repay_amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY repay_amount DESC) AS rn FROM repay_records ) t WHERE rn 3;这题有进阶版本如果要求“每个用户每个季度还款金额最高的前3天”需要在窗口函数里加一个季度分组条件。很多同学栽就栽在PARTITION BY子句上——只按用户分组忘了加季度维度。2.2 连续问题怎么破连续登录/连续还款天数连续类问题几乎是数据分析笔试的必考题。小满这批笔试的版本是给定用户登录日志表login_loguser_id, login_date求2023年2月每个用户的最大连续登录天数。这类题标准解法是“日期减行号”——用登录日期减去按用户分组的行号或排名如果日期是连续的差值就是恒定值然后按差值分组计数即可SELECT user_id, MAX(continue_days) AS max_continue_days FROM ( SELECT user_id, date_sub(login_date, rn) AS diff_group, COUNT(*) AS continue_days FROM ( SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM login_log WHERE login_date BETWEEN 2023-02-01 AND 2023-02-28 ) t1 GROUP BY user_id, date_sub(login_date, rn) ) t2 GROUP BY user_id;这里有个小细节值得注意如果同一天有多次登录记录需要先去重DISTINCT否则行号会错位连续天数的计算结果全是错的。这个坑我当年在真实面试中踩过——当时登录日志表有重复数据我没去重直接跑结果连续登录天数被虚增了。从那以后我只要看到“明细表”第一反应就是先检查重复值。2.3 留存率计算SQL题的压轴大戏留存率这类题在小满笔试里换了个业务外衣给定用户激活表user_id, activate_date和用户活跃表user_id, active_date求2023年1月激活用户的次日留存率、7日留存率。我知道很多人看到这道题会先懵一下不知道“次日留存”到底怎么定义。这里给新手朋友解释一下次日留存指的是“某天激活的用户中有多少人在第二天还活跃”7日留存就是第7天还活跃的用户占比。计算公式是SELECT t1.activate_date, COUNT(DISTINCT t1.user_id) AS activate_cnt, COUNT(DISTINCT t2.user_id) AS retention_cnt, COUNT(DISTINCT t2.user_id) / COUNT(DISTINCT t1.user_id) AS retention_rate FROM activation_table t1 LEFT JOIN active_table t2 ON t1.user_id t2.user_id AND DATEDIFF(t2.active_date, t1.activate_date) 1 WHERE t1.activate_date BETWEEN 2023-01-01 AND 2023-01-31 GROUP BY t1.activate_date;注意这里用的是LEFT JOIN而不是INNER JOIN因为我们要保留没有活跃记录的用户分母不能丢。这是留存率计算最经典的易错点——用INNER JOIN会把没有次日活跃的用户丢掉导致留存率虚高。7日留存把DATEDIFF改成7即可。3. Python数据分析与清洗实操题拆解3.1 数据清洗题pandas处理脏数据的标准动作小满笔试Python部分很少让你写复杂算法重点在pandas数据处理。题目大概长这样给出一份含缺失值、重复值、异常值的用户订单表包含字段order_id, user_id, order_date, order_amount, city要求在20分钟内完成清洗并输出每个城市的订单总量和订单金额总量。做这类题一定要形成肌肉记忆按照固定顺序处理数据先看数据规模和字段类型data.info()了解有没有明显异常。处理重复值drop_duplicates()按order_id去重。处理缺失值先看缺失比例如果order_amount缺失就填充或删除如果city缺失就按user_id关联其他表补齐。处理异常值order_amount明显为负或超过合理阈值的标记出来人工判断。统一时间格式pd.to_datetime()方便后续按时间聚合。我当时写的核心代码大概是这样的import pandas as pd df pd.read_csv(order_table.csv) df[order_date] pd.to_datetime(df[order_date]) # 去重 df df.drop_duplicates(subsetorder_id) # 缺失值处理金额缺失用中位数填充 df[order_amount] df[order_amount].fillna(df[order_amount].median()) # 异常值处理金额小于0的置为0 df.loc[df[order_amount] 0, order_amount] 0 # 按城市聚合 result df.groupby(city).agg( order_cnt(order_id, count), order_amount_sum(order_amount, sum) ).reset_index()这类题目本身不难真正的分水岭在于你对pandas API的熟练度。如果你写代码时还要翻文档那时间肯定不够。建议大家在笔试前把pandas的核心方法过一遍groupby、merge、apply、pivot_table、fillna、drop_duplicates这几个高频操作做到闭着眼睛能写。3.2 一份真实的SQLPython结合题用pandas做RFM用户分层和小满同期出现的一道好题我把原题分享给大家给定一份用户订单数据user_id, order_date, order_amount要求用Python实现RFM分层Recency最近购买间隔、Frequency购买频率、Monetary购买金额输出每个用户的RFM分数和分层结果。这是个经典的“SQL能算但Python更好写逻辑”的题目。解题思路分三步第一步计算每个用户的R、F、M值import pandas as pd import numpy as np # 假设df是原始订单表参考日期为2023-02-28 ref_date pd.to_datetime(2023-02-28) rfm df.groupby(user_id).agg( recency(order_date, lambda x: (ref_date - x.max()).days), frequency(order_id, count), monetary(order_amount, sum) ).reset_index()第二步给每个字段打分。常用方法是四分位数打分——比如R值越小越好F和M越大越好按顺序分成1到4分rfm[R_score] pd.qcut(rfm[recency], 4, labels[4, 3, 2, 1]) rfm[F_score] pd.qcut(rfm[frequency], 4, labels[1, 2, 3, 4]) rfm[M_score] pd.qcut(rfm[monetary], 4, labels[1, 2, 3, 4])注意R分数和F、M分数的方向是反的——间隔越短分数越高。这个方向搞反了整个RFM分层就全错了。第三步按业务规则分层。常见的规则是R和F都高的是重要价值用户M高但R低的是重要挽回用户等。这道题考查的不只是pandas用法更是对“数据分析方法论”的掌握程度。如果你连RFM是什么都不知道代码写得再漂亮也拿不到分。这就引出了笔试准备的核心思路——分析方法论和代码能力是一体两面缺一不可。3.3 可视化题matplotlib和seaborn出图的速度与规范Python部分的最后一道题通常涉及可视化。小满的版本是基于清洗后的订单数据画一张各城市订单金额的对比图并指出哪个城市业务贡献最高。这类题不只是画图还要考察你是否能“看图说话”。我当时画了个seaborn柱状图import matplotlib.pyplot as plt import seaborn as sns plt.figure(figsize(10, 6)) sns.barplot(dataresult, xcity, yorder_amount_sum) plt.title(各城市订单金额对比) plt.xticks(rotation45) plt.tight_layout() plt.savefig(city_order_amount.png)做题时的经验教训是可视化一定要先明确“图给谁看”。如果是给管理层看的图要简洁、省色、突出结论如果是给分析团队做探索用的可以信息密度高一点。笔试中建议直接标注出数值、加上标题让阅卷人一眼看到你要表达的结论。还有一个小技巧出图前先用groupby确认聚合结果再画图避免画出来的图和数据不一致。4. 业务案例分析题从模糊问题到可执行分析方案4.1 案例分析题的标准解题框架拆解量化落地业务案例分析题是数据分析笔试题里最让人头疼的部分因为它没有标准答案又最能拉开考生差距。小满这批笔试的案例分析题大概是这样的背景小满APP近一个月的用户活跃度出现明显下降尤其是新用户的次日留存率从35%下降到28%。请设计一套分析方案找出活跃度下降的原因并提出可落地的改进建议。这种问题一看就很“真实”但也很“模糊”。和代码题不同这类题没有唯一正确解阅卷人看的是你的分析思路是否合理、是否结构化、是否可落地。我的解题框架固定分四步第一步明确问题定义。这里要区分“是什么下降了”——是整体活跃下降还是某个功能模块活跃下降是新用户留存下降还是老用户活跃下降题目里已经给出了一个线索新用户次日留存从35%降到28%但还要进一步定义清楚。我会先把问题拆成几个子问题哪些用户群下降最明显下降是从什么时候开始的是新增用户变差还是存量用户变差第二步提出假设并量化。这一步是案例分析题的核心。基于业务常识列出可能的下降原因每个原因都要有可验证的指标和应对的数据表渠道质量变差新用户的来源渠道结构是否变化各渠道的次日留存率同期对比如何产品功能改版近期是否上线了新版本、改了首页或核心流程竞品或外部环境影响同期是否有竞品拉新活动市场投放策略调整投放量级、投放渠道、投放人群是否有变化技术bug或体验问题关键页面是否出现加载失败、支付异常等故障每个假设都必须落到“用什么数据、看什么表、对比什么指标”上。比如“渠道质量变差”就对应渠道明细表和渠道留存表对比每个渠道在下降前后的留存变化找Delta最大的渠道。第三步确定分析优先级。假设列了一大堆不可能全做。用“影响程度×发生概率”来排序优先验证影响最大、最可能发生的原因。在实际工作中这叫“用最小成本找到最大根因”。第四步输出可落地的建议。写完原因之后一定要有改进建议且建议要具体到“做什么、预期效果如何、怎么验证”。比如针对渠道质量变差可以建议“暂停低质渠道投放、将预算挪向高留存渠道并建立渠道质量日报监控”。这样阅卷人才能判断你是真正理解了问题而不是在背书上看到的分析框架。4.2 指标拆解的实战示例案例分析题还会考一类具体的“指标拆解”题小满笔试的版本是某天支付成功率下降了2个百分点请定位原因。这种题本质上考的是“漏斗分析”能力。支付成功率的定义是支付成功人数/发起支付人数所以拆解公式支付成功率 支付成功人数 / 发起支付人数分子和分母都可以继续往下拆。分母发起支付人数的下降本身就会导致成功率下降——如果更多人发起支付但没成功那可能是支付渠道出了问题如果发起支付人数少了可能是入口曝光少了、用户点击意愿低了。分子和分母再分别按用户类型、设备类型、支付渠道、地域维度拆分对比前一天、前一周同一天就能定位到“哪个维度、哪个环节”出了问题。一个关键技巧遇到率值类指标异动永远先拆分子分母看绝对值变化再看是哪个细分维度贡献了主要Delta。很多人遇到率值下降就慌了急着猜原因其实是基础的分母变了导致率值被稀释。4.3 指标体系设计题的作答套路小满这批笔试还有一个更进阶的题目给出一段业务描述小满APP计划推出一款“智能理财助手”功能请为该功能设计一套指标体系用于评估功能上线后的效果。这套题的答题思路不要堆砌指标而是按“漏斗分层”的逻辑组织指标。分为三个层级一级指标功能北极星指标比如“智能理财助手周使用用户数”这是衡量功能是否成功的最核心指标。二级指标用户体验类指标包括开通率、使用频次、功能停留时长、次日再次使用率。三级指标业务效果类指标包括用户资产提升金额、理财买入转化率、付费用户占比等。这样分层设计的逻辑是一级指标看整体二级指标看体验三级指标看商业价值三层指标形成“用户用→用户觉得好用→用户产生业务价值”的完整闭环。这正好是数据分析师在工作中设计报表/看板的标准思路——先定北极星指标再逐层拆解子指标。5. 统计与AB实验题数据科学决策的地基5.1 假设检验和AB实验的综合题怎么答统计专业知识是区分“只会取数的数据分析师”和“能科学决策的数据分析师”的关键。小满笔试统计部分有一道综合题产品经理提出一个新版首页方案认为可以提升用户点击率。现有数据对照组点击率10%样本量5000实验组点击率10.6%样本量5000问是否应该全量上线新方案请给出你的统计分析和决策建议。这道题考的是AB实验最基本的完整流程计算显著性、判断是否有统计意义、结合业务实际做决策。答案分三部分第一先算p值或者置信区间。用双样本比例检验Z检验在Python里可以直接用statsmodelsfrom statsmodels.stats.proportion import proportions_ztest count [530, 500] # 实验组点击成功数, 对照组点击成功数 nobs [5000, 5000] # 两个组的样本量 z_stat, p_value proportions_ztest(count, nobs) print(fZ统计量: {z_stat:.4f}, P值: {p_value:.4f})经计算p值大概在0.31左右远大于0.05说明实验组和对照组的点击率差异在统计上不显著。也就是说这0.6个百分点的提升很可能是抽样误差造成的。第二结合业务实际给出决策建议。虽然统计不显著但不一定直接否定方案——需要考虑这个改动是否有长期价值比如用户体验、品牌感知等非量化指标。如果这些方面没有明显的负面反馈可以考虑扩大样本量再做一轮实验如果改动成本很低也可以灰度放量继续观察。这道题的完整作答体现了数据分析师的核心能力之一——“不完只看结果还要看结果是否可信、代价是否值得”。这类题没有标准答案但一定要把“统计显著性”和“业务显著性”分开讲再给出一个有逻辑的决策。统计显著性回答“差异是不是偶然”业务显著性回答“差异值不值得做”两者缺一不可。5.2 无监督学习和其他机器学习常识除了AB实验统计模块还会考一些机器学习基础尤其是聚类相关的无监督学习。小满笔试有一道题问如何对用户进行分群以便制定差异化运营策略请简述至少两种分群方法。这道题最稳妥的答法是先讲K-means聚类的标准流程——确定特征如消费金额、消费频次、活跃天数、标准化、选K值手肘法或轮廓系数、聚类、解读簇特征。再讲PCA降维和聚类结合——如果特征太多可以用PCA降到二维或三维再聚类方便可视化。还可以提到RFM分层作为一种基于业务规则的分群方法分群结果更易解释适合业务方快速使用。另一类高频考点是特征构造和特征选择。比如遇到回归类题目特征中既有数值型又有分类变量你要能说清楚数值特征要不要做标准化分类特征用label encoding还是one-hot encoding缺失值用什么策略填充这些都直接在真实工作中用得到也是面试官区分“刷题型选手”和“实战型选手”的地方。5.3 离线数据分析常用工具的加分项如果笔试或面试中问到你做过哪些离线数据分析可以主动提工具链用SQL和Python做离线数据清洗、加工和聚合用spark处理海量数据场景用DBeaver这类数据库客户端连接各种数据源做可视化查询。这些工具不一定每道笔试都会考但在“项目经验介绍”和“开放性题目”中主动提到能显著提升专业感。我个人的笔试答题习惯是SQL题目尽量用窗口函数精简写法Python题目先写import、再写主体逻辑、最后补充异常处理工具类题目就结合“我实际在XX项目中用过”来展开哪怕那个项目很小也能让答案显得具体可信。6. 完整复盘与冲刺建议笔试前一周我做了什么6.1 笔试前7天的复习计划安排我知道很多人是临时抱佛脚型的选手但数据分析岗笔试这东西突击3天和系统准备7天差距非常大。我复盘了自己准备小满笔试那一周的计划直接分享出来供参考第1-2天刷SQL。重点练窗口函数、连续问题、留存率、分组TopN每天10道题做题时强制用窗口函数而不用子查询训练写复杂SQL的肌肉记忆。第3天刷pandas。把groupby、merge、apply、pivot_table这几个高频操作各练10遍先跑一遍官方文档示例再合上文档默写核心代码。第4天过一遍统计知识。重点是假设检验流程、p值含义、AB实验样本量计算、K-means聚类原理。不用背公式要能讲清“为什么需要它”“什么场景用”。第5天业务案例分析专项。找5道公开的案例分析真题练习“拆解问题→提出假设→量化验证→给出建议”这一整套框架。第6天模拟一套完整笔试。按真实笔试时间计时中间不查资料完完整整做一套题体验考场节奏。第7天复盘错题重点看之前反复错的类型准备一下自我介绍和项目复盘因为很多公司笔试完很快就是一面前脚接后脚。这个计划的核心逻辑是先保基础分SQL和Python再拉高上限业务分析和统计。如果你的SQL基础已经很扎实可以直接把第1-2天压缩成1天把省出来的时间投到业务案例题上。6.2 应试技巧与时间分配先拿分后抠细节笔试现场的时间分配也是决定成败的关键。小满这批笔试一共约90分钟我的策略是前10分钟通读所有题目标记出“会做且分高”“会做但耗时”“完全没思路”三类题。先做SQL的前两题简单题先拿分建立信心控制在15分钟内。再做Python数据清洗题控制在20分钟内这类题只要按流程走基本能拿满分。留35分钟给业务案例分析题这是最拉分的模块不能因为前面的代码题耗时而被压缩。最后5分钟检查主要扫一眼SQL的JOIN条件、Python的字段名是否有拼写错误、案例分析有没有漏掉步骤。这个时间分配的精髓是永远不要在一道题上死磕超过15分钟。如果一道SQL题10分钟写不出来先跳过做完全部再回头补。大多数笔试不指望你答满分而是看你在有限时间内能拿到多少分。注意案例分析题的时间一定不能省。哪怕代码题空一道案例分析题也至少要写完“问题定义→假设列表→验证方案→落地建议”这个完整框架因为这类题写一半和写完整得分差距极大。6.3 复盘时发现的高频丢分点希望你别踩我批改过不少同学模拟卷也复盘过自己的答题过程发现有四个丢分点真的是“高频又冤大头”第一SQL不明确定义业务口径。比如“成交量”是订单量还是支付成功量“用户数”是UV还是去重设备数这些口径必须在SQL里明确体现否则计算结果无意义。第二Python代码能跑但逻辑粗糙。比如不做重复值处理就直接聚合结果被重复数据污染最后分析结论完全跑偏。第三业务案例分析缺少量化。很多人只写“拉取用户分群数据看看”不写具体看什么表、算什么指标、怎么判断。这种回答在阅卷人眼里等于没答。第四AB实验只看p值不论业务。甚至有人把“p值小于0.05”简单等同于“一定有效”忽略置信区间、效应量、业务成本这些关键维度。这几个问题本质上都是同一个症结——把数据分析当成了“做题”而不是把它当成“解决业务问题的手段”。笔试前一定要提醒自己分析不是终点决策才是。6.4 笔试后如何顺势准备面试笔试结束后建议趁热打铁把笔试题里自己不太熟练的模块整理成错题本。小满这类公司笔试和面试通常间隔比较短题面和面试问题经常高度相关——笔试里考过RFM分层面试里很可能追问“RFM分层结果怎么和运营活动配合”笔试里考过留存率面试里可能会让你现场设计一个提升次日留存的实验方案。我笔试后必做的一件事是把每道题重新用文字写一遍完整的解题思路然后对着自己讲一遍。这个过程看起来笨但能帮你把“会做题”变成“会讲题”而“会讲题”正是面试环节最需要的核心能力。面试官问“你当时为什么这么分析”的时候你能清晰说出思考过程就赢过一多半候选人了。另外面试前一定把自己的项目经历里“数据清洗”“SQL取数”“AB实验”“业务洞察”这几个环节的细节补充完整。数据分析岗面试问项目几乎必问“你在这个项目里具体负责哪部分”“用了什么方法”“遇到什么困难怎么解决的”——这本质上还是在考察你处理数据的完整思路和表达清晰度。最后再分享一个小技巧笔试答题中凡是涉及率值留存率、转化率、成功率的计算一定顺手写下口径定义比如“次日留存次日活跃用户/当日激活用户”。这一行字不费时间但能让阅卷人确认你真的理解业务含义而不是死套公式。我在多次笔试中验证过这个细节虽然不起眼但确实能降低被扣“逻辑不清”分数的概率。