前几天帮一个学弟梳理数据分析校招的备考计划翻出了自己当年参加58同城数据分析岗位笔试时留下的复盘笔记。说实话那次笔试给我留下的印象比后来很多面试都深——不是因为题目难而是它让我第一次清楚地意识到企业招数据分析师和学校考数据分析完全是两个物种。这篇东西不打算复述具体考题也早忘了而是基于那次笔试的复盘加上这几年做数据工作、也帮人筛过简历和笔试卷的经验聊聊数据分析校招笔试到底在考什么、怎么准备、有哪些坑。内容按题型拆解 / 知识模块 / 实战推演 / 避坑清单四个部分展开适合正在准备校招、或者打算转行做数据分析的同学。1. 笔试整体设计与考查思路拆解1.1 企业为什么要用一张卷子筛人一开始很多同学对笔试有误解以为笔试就是考知识把大学里统计课的习题集翻出来狂刷。实际上企业笔试的命题逻辑完全不是这样的。数据分析岗在校招里收到的简历量非常大笔试首先是一个筛选漏斗它的目的不是考倒你而是在很短时间内判断你能不能干活。那什么叫能干活对应到日常工作中就是三类能力第一能从数据库里把数据取出来第二能对数据做清洗、分析和可视化第三能基于分析结果给出业务方听得懂的结论。你可以把这理解为一次浓缩版的带薪实习模拟考。我当时总结了一句话笔试里出现的每一道题几乎都能在真实工作里找到对应的任务。SQL题对应你入职后第一周的取数需求pandas题对应你处理运营丢过来的一张乱到不行的Excel表统计题对应你帮产品评估一次改版有没有效果业务题对应你被业务方追问转化率怎么降了你帮我看看。想通了这一点你就知道该往哪使劲复习了——不是把知识点背熟而是把知识点练成看到问题就能反应出解法的手感。1.2 互联网公司数据分析笔试的典型题型分布以58同城这类业务型互联网公司为例它的数据特点非常鲜明用户量大、业务线多招聘、房产、二手车、本地生活服务等、数据口径复杂。所以笔试题目通常不会只考一个方向而是用一张综合卷把工具基本功分析思维业务感都测一遍。根据我当时看到的题型和后来历年校招同学的反馈大致可以整理成下面这个分布具体比例每年会有浮动但方向基本稳定模块大致占比考察能力常见题型SQL30%-40%数据提取能力多表关联、聚合统计、留存/漏斗计算、连续性问题Python/Excel20%-30%数据处理与分析能力pandas清洗、缺失值处理、简单可视化、Excel操作题统计学基础10%-20%数据分析严谨性假设检验、概率题、AB实验理解业务案例题20%-30%业务理解与分析框架指标异动分析、运营策略设计、漏斗优化这里有个值得注意的点SQL和业务题加起来通常要占到一半以上。这背后的逻辑很现实——在真实工作里你80%的日常时间花在写SQL和处理数据上而决定你能不能把数据分析做出价值的是你对业务的理解。所以如果你现在时间有限优先把SQL练熟、把业务分析的框架搭起来投入产出比最高。2. 核心知识模块与答题要点2.1 SQL笔试的硬门槛也是日常工作的地基SQL基本是所有数据分析笔试里权重最高、也最一分耕耘一分收获的部分。它对就是对错就是错没有模糊空间。笔试里高频出现的SQL场景我统计下来无非是这几类各类用户活跃统计日活、周活、月活、留存率计算、漏斗转化率、累计值计算、分组TopN、连续性问题。很多人以为SQL就是把SELECT、JOIN、GROUP BY背熟结果一上笔试就卡在这道题到底要我先做什么再做什么的思路上。这就像背了很多单词却不会造句输入和输出没打通。我建议把SQL学成三板斧第一板斧是聚合思维看到每天每个品类每个城市这类词立刻想到GROUP BY明确聚合粒度第二板斧是关联思维看到用户表订单表这种多表结构先画一下表之间的关系主键是什么、关联键是什么第三板斧是窗口函数思维凡是遇到排名、同比、环比、连续登录这类题优先考虑ROW_NUMBER、RANK、LAG、LEAD这些窗口函数。这三种思维能覆盖笔试里绝大多数的SQL题型。举一个非常经典的例子给一张用户登录记录表字段user_id、login_date求每个用户连续登录的最大天数。这个题目全网都考烂了但每次都能刷掉一大批人。标准思路分四步先把同一用户同一天的重复记录去重然后对每个用户按日期排序用ROW_NUMBER()生成序号再用登录日期减去序号得到一个分组标记日期因为连续登录的日子里日期减去递增的序号会得到同一个值最后按用户和这个标记日期分组数天数取最大值。SQL写出来大致是这样的SELECT user_id, MAX(consecutive_days) AS max_days FROM ( SELECT user_id, grp_date, COUNT(*) AS consecutive_days FROM ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL rn DAY) AS grp_date FROM ( SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM ( SELECT DISTINCT user_id, login_date FROM user_login_log ) t1 ) t2 ) t3 GROUP BY user_id, grp_date ) t4 GROUP BY user_id这道题之所以经典是因为它把去重、窗口排序、日期运算、嵌套分组这些笔试最爱考的点全串起来了。你如果能把这类题的思路写顺笔试里的SQL大关基本就过了。需要注意的是不同在线笔试平台对SQL的语法支持不一样有的用MySQL有的用Hive SQL个别函数写法有差异比如DATE_SUB在有些平台写DATEADD正式考试前一定要先看平台说明。注意SQL题里去重是最容易被忽略的一步。凡是涉及用户数订单数这类计数指标都要先想清楚是否需要DISTINCT否则一旦数据表里存在重复记录结果就会偏大。2.2 Python与Excel数据处理题要拼的是手速规范除了SQL很多数据分析笔试会安排一道数据处理题通常用Python尤其是pandas或者Excel来解。这类题目的难度其实不高考的是你在规定时间内能不能把一件脏活干利索。比较典型的场景包括给一张订单明细表里面有重复值、缺失值、异常的负数和格式不统一的时间字段要求你清洗之后统计各品类的销售额和订单量。这完全就是日常工作里运营扔给你一张表说帮我看看这个月卖得怎么样的场景再现。用pandas处理这类题的常规套路是读数据之后先看形状和缺失情况然后按顺序处理缺失值、重复值、异常值最后用groupby做聚合。伪代码思路大概是import pandas as pd df pd.read_csv(orders.csv) # 1. 看数据概览 print(df.shape) print(df.isnull().sum()) # 2. 去重按订单ID去重 df df.drop_duplicates(subset[order_id]) # 3. 处理缺失值金额缺失按0填充或删除取决于业务约定 df df.dropna(subset[amount]) # 4. 过滤异常值金额必须大于0 df df[df[amount] 0] # 5. 统一时间格式并提取日期 df[date] pd.to_datetime(df[order_time]).dt.date # 6. 聚合统计 result df.groupby([category, date]).agg( total_amount(amount, sum), order_cnt(order_id, nunique) ).reset_index()这里有两个笔试里特别容易丢分的地方。第一处理顺序不要乱。如果你先做聚合再去重重复订单会被重复计入结果就错了第二groupby之后要记得reset_index否则结果是一个Series堆叠的DataFrame后面再操作容易报错。很多人在本地练习时从不在意这些细节一到在线笔试的环境里报错就慌了。我的建议是平时练习就模拟考试环境不开IDE补全不查文档逼自己把常用API的签名记熟。Excel方向也同样重要虽然现在很多公司笔试支持用Python但Excel仍然是数据分析的基本功尤其是VLOOKUP、数据透视表和基础图表。遇到Excel题时我的经验是先把题目的要求拆成要匹配什么字段、要汇总什么维度、要展示什么形式三个问题再动手操作比上来就到处点图标要快得多。2.3 统计学与业务指标体系最容易自以为会的部分统计学在数据分析笔试里占比不一定高但它是区分工具人和分析师的分水岭。常见考点包括假设检验的流程、p值怎么理解、置信区间、两类错误以及AB实验的基本原理。很多同学能背出p0.05拒绝原假设但一到题目里就不明白为什么两组数据的均值明明差了很多结论却是不显著。原因在于样本量和方差会影响显著性——均值差异大但方差更大、样本量不足时照样不显著。这个认知比背公式重要得多。另外笔试里十有八九会出现业务指标相关的问题比如要求你定义月活跃用户付费转化率GMV等指标并说明口径。这种题看似简单其实是坑。比如GMV在不同业务里口径都不一样是拍下算还是支付算包含退款吗含不含运费同一个指标口径不同结果可能差出几个百分点。所以答题时一定要有口径意识主动说明自己在什么条件下算这个指标。这会让阅卷人觉得你是一个有业务常识的人而不是一个只会套公式的学生。这里还要提醒一个经典的分析陷阱辛普森悖论。举个例子A组整体转化率高于B组但拆到每个细分品类B组的转化率却都高于A组。这种整体结论和分组结论相反的情况在真实数据里非常常见笔试业务题也爱考。遇到这类题你要答出不能只看整体要按业务维度拆开看结构差异并提到可能是分组样本量不均衡导致的。能写出这一层分析深度立刻不一样了。2.4 商业案例题用框架感拿分业务案例题通常是整张卷子里最开放、也最能拉开差距的部分。典型的问法是某业务线的核心指标最近一周环比下降了10%你会怎么分析这种题没有标准答案阅卷人看的是你的分析框架和思维路径。我总结了一个可以套用的四步框架基本能应对绝大多数指标异动分析题。第一步定义问题。先确认这个指标下降是不是真实下降数据口径有没有变化有没有节假日或大促的影响是不是统计bug这一步很多人会忽略直接开始找原因显得很不严谨。第二步拆解指标。把核心指标按业务逻辑拆成几个可分析的部分。比如房源量可以按城市拆、按房源类型拆、按新增/存量拆找到下降最明显的子维度。第三步验证假设。结合你的业务常识列出可能的原因供给端问题、产品入口变化、竞品影响、季节性因素等然后用数据逐一验证。第四步给出建议。分析题最后一定要落到所以呢给出可执行的建议哪怕很简单也比只分析不给结论强。我当时在笔试里遇到过一个类似的场景某城市的业务数据连续三周下滑要求分析原因。我的答题思路就是先说明要排除口径和季节因素再把数据按城市层级下钻看是普遍性下滑还是个别区域拖累再结合外部环境判断是供给问题还是需求问题最后给出针对性的运营动作。这套框架的好处是即使你对具体业务不了解也能展现出遇到问题不慌、有条理地拆解的素质而这恰恰是企业最看重的。3. 实操过程与笔试实战复盘3.1 拿到试卷后我是如何分配时间的笔试的实战经验和平时刷题完全是两回事最大的区别在于时间压力。我记得当时那张综合卷大概有十几道题时间是90到120分钟平均下来每道题只有几分钟。如果按顺序硬磕很容易前面一两道SQL卡住了后面能拿分的题反而没时间做。我的建议是拿到试卷后先花两分钟通读一遍做三件事第一标出每道题的题型和大致分值第二判断哪些题是稳拿分的比如简单的SQL查询、指标定义题第三确定做题顺序原则是先易后难、先工具后业务、先保底后冲刺。我自己的做题顺序是这样的先快速做完概念题和指标定义题因为这类题就是送分题基本不用想然后做SQL和Python题这些题分值重而且答案客观做出来就拿分再然后是统计概率题这类题需要心算和思考放在中段做最后留出至少20到30分钟做业务大案例题因为这类题要用文字表达写了就有分但写完整需要时间。在最后十分钟一定要检查一遍有没有漏题、有没有看错题目条件比如按自然日统计排除测试用户这些细节往往就藏在题目末尾。我见过不少同学在笔试里犯一个很可惜的错误在一道20分的SQL题上死磕了40分钟结果后面一道30分的业务题只写了两行。从得分效率来看这是完全不划算的。数据分析笔试的题量设计本身就是在模拟突发需求多、时间永远不够的日常工作场景你如何处理时间分配本身就是一道隐藏的考察题。3.2 一道典型SQL题的完整推演过程为了把这个过程讲得更具体我拿一道非常经典的数据分析笔试题来完整走一遍流程题目是这样的有一张用户支付流水表user_id、pay_time、pay_amount一张用户维度表user_id、register_time、city要求统计每个城市2020年1月的实付用户数、总支付金额、人均支付金额。拿到这个题我先明确三件事表结构、关联键、统计口径。表结构很清楚两张表通过user_id关联统计口径有两个关键点一是时间范围是2020年1月二是用户口径是实付用户也就是至少有一笔有效支付记录的用户。这里就有个容易忽略的细节如果用user_id去关联用户维度表可能会因为用户维度表里有重复user_id导致支付流水被重复计数所以稳妥的做法是先对用户维度表按user_id去重或者直接只取需要的城市字段。接下来是SQL写法。我的思路是先限制支付流水表的时间范围再按user_id聚合出每个用户的支付总额和支付笔数最后和用户表关联按城市分组汇总。这里先聚合再关联比先关联再聚合效率更高而且能避免多对多关联导致的重复计算。参考写法如下SELECT u.city, COUNT(DISTINCT p.user_id) AS pay_user_cnt, SUM(p.pay_amount) AS total_amount, ROUND(SUM(p.pay_amount) / COUNT(DISTINCT p.user_id), 2) AS per_capita_amount FROM ( SELECT user_id, SUM(pay_amount) AS pay_amount FROM pay_flow WHERE pay_time 2020-01-01 AND pay_time 2020-02-01 GROUP BY user_id ) p LEFT JOIN ( SELECT user_id, city FROM user_dim GROUP BY user_id, city ) u ON p.user_id u.user_id GROUP BY u.city ORDER BY total_amount DESC这里有几个细节值得展开说一下。第一我用了LEFT JOIN而不是INNER JOIN这是因为支付流水表里可能存在用户维度表里查不到的用户用LEFT JOIN能保留这些订单城市显示为NULL在最终结果里可以做标记如果用INNER JOIN这些数据就丢了总金额就会偏低。第二时间过滤我写的是大于等于月初且小于下月月初避免用LIKE 2020-01%这类写法因为后者在字段是datetime类型时会索引失效。第三人均支付金额我用了总金额/去重用户数而不是AVG(p.pay_amount)因为后者是按流水行数平均两者含义完全不同。这些思考写不进最终答案但决定了SQL的正确性和效率。3.3 业务案例题的书面表达技巧业务题是笔试里唯一可以大量输出文字的地方很多人却不知道怎么写才能得分。我的经验是把自己想象成一个分析师正在给业务负责人写一份简短的邮件不是给阅卷人写标准答案。所以表达上要有几个特点结论先行把最重要的判断放在开头分段清晰一个段落只讲一个原因给数据佐证哪怕题目没给具体数字也要用从数据上看可以进一步验证这类表述来体现你的数据意识。我整理了一个对比表可以直观展示低分表达和高分表达的差别维度容易丢分的表达更容易得分的表达结论可能是用户流失了先拆到新老用户确认是新增用户次留下降导致的再分渠道定位依据我觉得是产品改版的问题建议对比改版前后同口径的转化率并排除季节性影响建议要提高转化率针对转化率下跌明显的城市上线定向优惠并做一周AB实验验证光看这个表就能感受到高分表达的核心是可验证、可执行、有结构。另外有一个小技巧业务题如果涉及指标答题时把指标公式或拆解树写在前面会让阅卷人一眼看出你的分析思路。比如分析GMV下滑第一行就写GMV 流量 × 转化率 × 客单价然后分别展开这三个因子。公式一亮框架就有了后面无论怎么展开都不会跑偏。4. 常见问题与排查技巧实录4.1 在线笔试环境里最容易踩的坑一个很普遍的情况是很多同学平时练习用的是本地IDE自动补全、报错提示、无限查资料都可以但一到在线笔试平台没有了这些拐杖立刻手足无措。我建议在备考后期一定要用在线平台做模拟练习特别是那种有计时、有代码提交、有批改的模拟环境提前适应眼睛看题、脑子里出代码、手上直接敲的节奏。另外在线平台有时候对SQL的字符串格式、日期函数写法有特殊要求练习时就要养成看平台说明的习惯。还有一个很多人栽过跟头的坑是题目理解偏差。比如题目说统计留存用户你得确认留存的定义是首日后第N天再次访问还是当月内再次访问题目说统计每个用户的消费金额你得确认是实付金额还是订单金额是否包含退款题目说排除测试数据你得知道测试用户通常有什么特征比如用户名包含test、注册时间异常、金额为0等。这些限定条件往往不是考察重点但忽略它们会导致整个结果作废。我的习惯是读题时把关键条件圈出来在答题纸或者草稿纸上写下一句话版的口径确认再开始动手。注意在线笔试平台一般没有撤销和自动保存的容错。SQL题在提交前建议把结果表截图或复制下来防止平台异常导致答案丢失代码题也要养成随手保存的习惯。4.2 分析内容中常见的新手病笔试里给我留下最深印象的不是谁SQL写得漂亮而是很多人在分析题里暴露出的思维方式问题。最常见的三个新手病我总结一下。第一个是只给结论不给依据。比如写我认为转化率下降是因为页面改版导致的但完全不提怎么验证、看什么数据、对比哪个时间段。这种回答看起来是分析实际上只是个人感觉在企业里是要被业务方追着问你的依据呢的。第二个是不做对比就直接下判断。比如本月销售额100万说明业绩不行可如果去年同月只有80万那这明明是增长。数据分析最基础的思维就是对比同比、环比、目标对比、行业对比。第三个是只做描述不做归因。描述是A城市订单下降了20%归因是因为A城市的供给端商家流失了15%导致可展示商品减少进而订单下降。企业要的是后者。把这些毛病一个个改掉分析能力就会有肉眼可见的提升。我有一个自己的检查习惯每写完一段分析用三句话自问——我的结论有数据支撑吗我的对比基准是什么我能给出一个可执行的建议吗如果三个问题都能答上来这段分析基本上就是合格的。4.3 备考时间线与资源清单如果你现在离笔试还有一段时间我建议按下面的时间线来准备。提前三个月到两个月主攻SQL和Python把语法基础打牢每天刷3到5道SQL题提前一个月专项突破统计和业务题重点练假设检验、AB实验、指标异动分析最后两周做整套的模拟卷卡时间、练手速顺便整理一份自己的答题模板库把SQL窗口函数模板、指标拆解模板、业务分析框架模板都沉淀下来。这套节奏的核心逻辑是前两个月把工具练到顺手最后一个月把思维练到专业。资源方面SQL可以刷LeetCode数据库题库和HackerRank的SQL模块重点练中高难度题Python就盯住pandas官方文档和一本讲数据分析实战的书把groupby、merge、apply这些高频API用熟统计和业务分析方面可以看一些AB实验和数据驱动决策的经典书籍网上也有不少数据分析面经帖可以借鉴。上面这些热搜词里我特别想点一下数据分析项目——很多人笔试准备只是刷题我建议一定要完整做一个端到端的数据分析项目包括取数、清洗、分析、可视化、结论输出。做项目的过程中你会把笔试里分散的知识点串联起来形成真正的分析手感。最后再说一个我自己的体会。笔试之前我最担心的其实是业务案例题总觉得没有标准答案、不知道怎么写才算对。后来我发现阅卷人并不指望一个校招生真的能解决业务问题他们想看到的只是你有没有一套自己的思考路径。所以遇到业务题不要慌不要试图憋出一个完美答案而是把你脑子里真实的思考过程分步骤写下来用上指标拆解、对比分析、假设验证这些基本功。哪怕最后的建议很朴素也比空白卷强得多。这个习惯我后来带团队时也一直在用——分析能力不是靠灵光一现而是靠一套稳定、可复用的思考流程。你把这套流程练熟了笔试、面试、甚至以后的工作都会顺很多。
数据分析校招笔试备考：题型拆解与避坑指南
前几天帮一个学弟梳理数据分析校招的备考计划翻出了自己当年参加58同城数据分析岗位笔试时留下的复盘笔记。说实话那次笔试给我留下的印象比后来很多面试都深——不是因为题目难而是它让我第一次清楚地意识到企业招数据分析师和学校考数据分析完全是两个物种。这篇东西不打算复述具体考题也早忘了而是基于那次笔试的复盘加上这几年做数据工作、也帮人筛过简历和笔试卷的经验聊聊数据分析校招笔试到底在考什么、怎么准备、有哪些坑。内容按题型拆解 / 知识模块 / 实战推演 / 避坑清单四个部分展开适合正在准备校招、或者打算转行做数据分析的同学。1. 笔试整体设计与考查思路拆解1.1 企业为什么要用一张卷子筛人一开始很多同学对笔试有误解以为笔试就是考知识把大学里统计课的习题集翻出来狂刷。实际上企业笔试的命题逻辑完全不是这样的。数据分析岗在校招里收到的简历量非常大笔试首先是一个筛选漏斗它的目的不是考倒你而是在很短时间内判断你能不能干活。那什么叫能干活对应到日常工作中就是三类能力第一能从数据库里把数据取出来第二能对数据做清洗、分析和可视化第三能基于分析结果给出业务方听得懂的结论。你可以把这理解为一次浓缩版的带薪实习模拟考。我当时总结了一句话笔试里出现的每一道题几乎都能在真实工作里找到对应的任务。SQL题对应你入职后第一周的取数需求pandas题对应你处理运营丢过来的一张乱到不行的Excel表统计题对应你帮产品评估一次改版有没有效果业务题对应你被业务方追问转化率怎么降了你帮我看看。想通了这一点你就知道该往哪使劲复习了——不是把知识点背熟而是把知识点练成看到问题就能反应出解法的手感。1.2 互联网公司数据分析笔试的典型题型分布以58同城这类业务型互联网公司为例它的数据特点非常鲜明用户量大、业务线多招聘、房产、二手车、本地生活服务等、数据口径复杂。所以笔试题目通常不会只考一个方向而是用一张综合卷把工具基本功分析思维业务感都测一遍。根据我当时看到的题型和后来历年校招同学的反馈大致可以整理成下面这个分布具体比例每年会有浮动但方向基本稳定模块大致占比考察能力常见题型SQL30%-40%数据提取能力多表关联、聚合统计、留存/漏斗计算、连续性问题Python/Excel20%-30%数据处理与分析能力pandas清洗、缺失值处理、简单可视化、Excel操作题统计学基础10%-20%数据分析严谨性假设检验、概率题、AB实验理解业务案例题20%-30%业务理解与分析框架指标异动分析、运营策略设计、漏斗优化这里有个值得注意的点SQL和业务题加起来通常要占到一半以上。这背后的逻辑很现实——在真实工作里你80%的日常时间花在写SQL和处理数据上而决定你能不能把数据分析做出价值的是你对业务的理解。所以如果你现在时间有限优先把SQL练熟、把业务分析的框架搭起来投入产出比最高。2. 核心知识模块与答题要点2.1 SQL笔试的硬门槛也是日常工作的地基SQL基本是所有数据分析笔试里权重最高、也最一分耕耘一分收获的部分。它对就是对错就是错没有模糊空间。笔试里高频出现的SQL场景我统计下来无非是这几类各类用户活跃统计日活、周活、月活、留存率计算、漏斗转化率、累计值计算、分组TopN、连续性问题。很多人以为SQL就是把SELECT、JOIN、GROUP BY背熟结果一上笔试就卡在这道题到底要我先做什么再做什么的思路上。这就像背了很多单词却不会造句输入和输出没打通。我建议把SQL学成三板斧第一板斧是聚合思维看到每天每个品类每个城市这类词立刻想到GROUP BY明确聚合粒度第二板斧是关联思维看到用户表订单表这种多表结构先画一下表之间的关系主键是什么、关联键是什么第三板斧是窗口函数思维凡是遇到排名、同比、环比、连续登录这类题优先考虑ROW_NUMBER、RANK、LAG、LEAD这些窗口函数。这三种思维能覆盖笔试里绝大多数的SQL题型。举一个非常经典的例子给一张用户登录记录表字段user_id、login_date求每个用户连续登录的最大天数。这个题目全网都考烂了但每次都能刷掉一大批人。标准思路分四步先把同一用户同一天的重复记录去重然后对每个用户按日期排序用ROW_NUMBER()生成序号再用登录日期减去序号得到一个分组标记日期因为连续登录的日子里日期减去递增的序号会得到同一个值最后按用户和这个标记日期分组数天数取最大值。SQL写出来大致是这样的SELECT user_id, MAX(consecutive_days) AS max_days FROM ( SELECT user_id, grp_date, COUNT(*) AS consecutive_days FROM ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL rn DAY) AS grp_date FROM ( SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM ( SELECT DISTINCT user_id, login_date FROM user_login_log ) t1 ) t2 ) t3 GROUP BY user_id, grp_date ) t4 GROUP BY user_id这道题之所以经典是因为它把去重、窗口排序、日期运算、嵌套分组这些笔试最爱考的点全串起来了。你如果能把这类题的思路写顺笔试里的SQL大关基本就过了。需要注意的是不同在线笔试平台对SQL的语法支持不一样有的用MySQL有的用Hive SQL个别函数写法有差异比如DATE_SUB在有些平台写DATEADD正式考试前一定要先看平台说明。注意SQL题里去重是最容易被忽略的一步。凡是涉及用户数订单数这类计数指标都要先想清楚是否需要DISTINCT否则一旦数据表里存在重复记录结果就会偏大。2.2 Python与Excel数据处理题要拼的是手速规范除了SQL很多数据分析笔试会安排一道数据处理题通常用Python尤其是pandas或者Excel来解。这类题目的难度其实不高考的是你在规定时间内能不能把一件脏活干利索。比较典型的场景包括给一张订单明细表里面有重复值、缺失值、异常的负数和格式不统一的时间字段要求你清洗之后统计各品类的销售额和订单量。这完全就是日常工作里运营扔给你一张表说帮我看看这个月卖得怎么样的场景再现。用pandas处理这类题的常规套路是读数据之后先看形状和缺失情况然后按顺序处理缺失值、重复值、异常值最后用groupby做聚合。伪代码思路大概是import pandas as pd df pd.read_csv(orders.csv) # 1. 看数据概览 print(df.shape) print(df.isnull().sum()) # 2. 去重按订单ID去重 df df.drop_duplicates(subset[order_id]) # 3. 处理缺失值金额缺失按0填充或删除取决于业务约定 df df.dropna(subset[amount]) # 4. 过滤异常值金额必须大于0 df df[df[amount] 0] # 5. 统一时间格式并提取日期 df[date] pd.to_datetime(df[order_time]).dt.date # 6. 聚合统计 result df.groupby([category, date]).agg( total_amount(amount, sum), order_cnt(order_id, nunique) ).reset_index()这里有两个笔试里特别容易丢分的地方。第一处理顺序不要乱。如果你先做聚合再去重重复订单会被重复计入结果就错了第二groupby之后要记得reset_index否则结果是一个Series堆叠的DataFrame后面再操作容易报错。很多人在本地练习时从不在意这些细节一到在线笔试的环境里报错就慌了。我的建议是平时练习就模拟考试环境不开IDE补全不查文档逼自己把常用API的签名记熟。Excel方向也同样重要虽然现在很多公司笔试支持用Python但Excel仍然是数据分析的基本功尤其是VLOOKUP、数据透视表和基础图表。遇到Excel题时我的经验是先把题目的要求拆成要匹配什么字段、要汇总什么维度、要展示什么形式三个问题再动手操作比上来就到处点图标要快得多。2.3 统计学与业务指标体系最容易自以为会的部分统计学在数据分析笔试里占比不一定高但它是区分工具人和分析师的分水岭。常见考点包括假设检验的流程、p值怎么理解、置信区间、两类错误以及AB实验的基本原理。很多同学能背出p0.05拒绝原假设但一到题目里就不明白为什么两组数据的均值明明差了很多结论却是不显著。原因在于样本量和方差会影响显著性——均值差异大但方差更大、样本量不足时照样不显著。这个认知比背公式重要得多。另外笔试里十有八九会出现业务指标相关的问题比如要求你定义月活跃用户付费转化率GMV等指标并说明口径。这种题看似简单其实是坑。比如GMV在不同业务里口径都不一样是拍下算还是支付算包含退款吗含不含运费同一个指标口径不同结果可能差出几个百分点。所以答题时一定要有口径意识主动说明自己在什么条件下算这个指标。这会让阅卷人觉得你是一个有业务常识的人而不是一个只会套公式的学生。这里还要提醒一个经典的分析陷阱辛普森悖论。举个例子A组整体转化率高于B组但拆到每个细分品类B组的转化率却都高于A组。这种整体结论和分组结论相反的情况在真实数据里非常常见笔试业务题也爱考。遇到这类题你要答出不能只看整体要按业务维度拆开看结构差异并提到可能是分组样本量不均衡导致的。能写出这一层分析深度立刻不一样了。2.4 商业案例题用框架感拿分业务案例题通常是整张卷子里最开放、也最能拉开差距的部分。典型的问法是某业务线的核心指标最近一周环比下降了10%你会怎么分析这种题没有标准答案阅卷人看的是你的分析框架和思维路径。我总结了一个可以套用的四步框架基本能应对绝大多数指标异动分析题。第一步定义问题。先确认这个指标下降是不是真实下降数据口径有没有变化有没有节假日或大促的影响是不是统计bug这一步很多人会忽略直接开始找原因显得很不严谨。第二步拆解指标。把核心指标按业务逻辑拆成几个可分析的部分。比如房源量可以按城市拆、按房源类型拆、按新增/存量拆找到下降最明显的子维度。第三步验证假设。结合你的业务常识列出可能的原因供给端问题、产品入口变化、竞品影响、季节性因素等然后用数据逐一验证。第四步给出建议。分析题最后一定要落到所以呢给出可执行的建议哪怕很简单也比只分析不给结论强。我当时在笔试里遇到过一个类似的场景某城市的业务数据连续三周下滑要求分析原因。我的答题思路就是先说明要排除口径和季节因素再把数据按城市层级下钻看是普遍性下滑还是个别区域拖累再结合外部环境判断是供给问题还是需求问题最后给出针对性的运营动作。这套框架的好处是即使你对具体业务不了解也能展现出遇到问题不慌、有条理地拆解的素质而这恰恰是企业最看重的。3. 实操过程与笔试实战复盘3.1 拿到试卷后我是如何分配时间的笔试的实战经验和平时刷题完全是两回事最大的区别在于时间压力。我记得当时那张综合卷大概有十几道题时间是90到120分钟平均下来每道题只有几分钟。如果按顺序硬磕很容易前面一两道SQL卡住了后面能拿分的题反而没时间做。我的建议是拿到试卷后先花两分钟通读一遍做三件事第一标出每道题的题型和大致分值第二判断哪些题是稳拿分的比如简单的SQL查询、指标定义题第三确定做题顺序原则是先易后难、先工具后业务、先保底后冲刺。我自己的做题顺序是这样的先快速做完概念题和指标定义题因为这类题就是送分题基本不用想然后做SQL和Python题这些题分值重而且答案客观做出来就拿分再然后是统计概率题这类题需要心算和思考放在中段做最后留出至少20到30分钟做业务大案例题因为这类题要用文字表达写了就有分但写完整需要时间。在最后十分钟一定要检查一遍有没有漏题、有没有看错题目条件比如按自然日统计排除测试用户这些细节往往就藏在题目末尾。我见过不少同学在笔试里犯一个很可惜的错误在一道20分的SQL题上死磕了40分钟结果后面一道30分的业务题只写了两行。从得分效率来看这是完全不划算的。数据分析笔试的题量设计本身就是在模拟突发需求多、时间永远不够的日常工作场景你如何处理时间分配本身就是一道隐藏的考察题。3.2 一道典型SQL题的完整推演过程为了把这个过程讲得更具体我拿一道非常经典的数据分析笔试题来完整走一遍流程题目是这样的有一张用户支付流水表user_id、pay_time、pay_amount一张用户维度表user_id、register_time、city要求统计每个城市2020年1月的实付用户数、总支付金额、人均支付金额。拿到这个题我先明确三件事表结构、关联键、统计口径。表结构很清楚两张表通过user_id关联统计口径有两个关键点一是时间范围是2020年1月二是用户口径是实付用户也就是至少有一笔有效支付记录的用户。这里就有个容易忽略的细节如果用user_id去关联用户维度表可能会因为用户维度表里有重复user_id导致支付流水被重复计数所以稳妥的做法是先对用户维度表按user_id去重或者直接只取需要的城市字段。接下来是SQL写法。我的思路是先限制支付流水表的时间范围再按user_id聚合出每个用户的支付总额和支付笔数最后和用户表关联按城市分组汇总。这里先聚合再关联比先关联再聚合效率更高而且能避免多对多关联导致的重复计算。参考写法如下SELECT u.city, COUNT(DISTINCT p.user_id) AS pay_user_cnt, SUM(p.pay_amount) AS total_amount, ROUND(SUM(p.pay_amount) / COUNT(DISTINCT p.user_id), 2) AS per_capita_amount FROM ( SELECT user_id, SUM(pay_amount) AS pay_amount FROM pay_flow WHERE pay_time 2020-01-01 AND pay_time 2020-02-01 GROUP BY user_id ) p LEFT JOIN ( SELECT user_id, city FROM user_dim GROUP BY user_id, city ) u ON p.user_id u.user_id GROUP BY u.city ORDER BY total_amount DESC这里有几个细节值得展开说一下。第一我用了LEFT JOIN而不是INNER JOIN这是因为支付流水表里可能存在用户维度表里查不到的用户用LEFT JOIN能保留这些订单城市显示为NULL在最终结果里可以做标记如果用INNER JOIN这些数据就丢了总金额就会偏低。第二时间过滤我写的是大于等于月初且小于下月月初避免用LIKE 2020-01%这类写法因为后者在字段是datetime类型时会索引失效。第三人均支付金额我用了总金额/去重用户数而不是AVG(p.pay_amount)因为后者是按流水行数平均两者含义完全不同。这些思考写不进最终答案但决定了SQL的正确性和效率。3.3 业务案例题的书面表达技巧业务题是笔试里唯一可以大量输出文字的地方很多人却不知道怎么写才能得分。我的经验是把自己想象成一个分析师正在给业务负责人写一份简短的邮件不是给阅卷人写标准答案。所以表达上要有几个特点结论先行把最重要的判断放在开头分段清晰一个段落只讲一个原因给数据佐证哪怕题目没给具体数字也要用从数据上看可以进一步验证这类表述来体现你的数据意识。我整理了一个对比表可以直观展示低分表达和高分表达的差别维度容易丢分的表达更容易得分的表达结论可能是用户流失了先拆到新老用户确认是新增用户次留下降导致的再分渠道定位依据我觉得是产品改版的问题建议对比改版前后同口径的转化率并排除季节性影响建议要提高转化率针对转化率下跌明显的城市上线定向优惠并做一周AB实验验证光看这个表就能感受到高分表达的核心是可验证、可执行、有结构。另外有一个小技巧业务题如果涉及指标答题时把指标公式或拆解树写在前面会让阅卷人一眼看出你的分析思路。比如分析GMV下滑第一行就写GMV 流量 × 转化率 × 客单价然后分别展开这三个因子。公式一亮框架就有了后面无论怎么展开都不会跑偏。4. 常见问题与排查技巧实录4.1 在线笔试环境里最容易踩的坑一个很普遍的情况是很多同学平时练习用的是本地IDE自动补全、报错提示、无限查资料都可以但一到在线笔试平台没有了这些拐杖立刻手足无措。我建议在备考后期一定要用在线平台做模拟练习特别是那种有计时、有代码提交、有批改的模拟环境提前适应眼睛看题、脑子里出代码、手上直接敲的节奏。另外在线平台有时候对SQL的字符串格式、日期函数写法有特殊要求练习时就要养成看平台说明的习惯。还有一个很多人栽过跟头的坑是题目理解偏差。比如题目说统计留存用户你得确认留存的定义是首日后第N天再次访问还是当月内再次访问题目说统计每个用户的消费金额你得确认是实付金额还是订单金额是否包含退款题目说排除测试数据你得知道测试用户通常有什么特征比如用户名包含test、注册时间异常、金额为0等。这些限定条件往往不是考察重点但忽略它们会导致整个结果作废。我的习惯是读题时把关键条件圈出来在答题纸或者草稿纸上写下一句话版的口径确认再开始动手。注意在线笔试平台一般没有撤销和自动保存的容错。SQL题在提交前建议把结果表截图或复制下来防止平台异常导致答案丢失代码题也要养成随手保存的习惯。4.2 分析内容中常见的新手病笔试里给我留下最深印象的不是谁SQL写得漂亮而是很多人在分析题里暴露出的思维方式问题。最常见的三个新手病我总结一下。第一个是只给结论不给依据。比如写我认为转化率下降是因为页面改版导致的但完全不提怎么验证、看什么数据、对比哪个时间段。这种回答看起来是分析实际上只是个人感觉在企业里是要被业务方追着问你的依据呢的。第二个是不做对比就直接下判断。比如本月销售额100万说明业绩不行可如果去年同月只有80万那这明明是增长。数据分析最基础的思维就是对比同比、环比、目标对比、行业对比。第三个是只做描述不做归因。描述是A城市订单下降了20%归因是因为A城市的供给端商家流失了15%导致可展示商品减少进而订单下降。企业要的是后者。把这些毛病一个个改掉分析能力就会有肉眼可见的提升。我有一个自己的检查习惯每写完一段分析用三句话自问——我的结论有数据支撑吗我的对比基准是什么我能给出一个可执行的建议吗如果三个问题都能答上来这段分析基本上就是合格的。4.3 备考时间线与资源清单如果你现在离笔试还有一段时间我建议按下面的时间线来准备。提前三个月到两个月主攻SQL和Python把语法基础打牢每天刷3到5道SQL题提前一个月专项突破统计和业务题重点练假设检验、AB实验、指标异动分析最后两周做整套的模拟卷卡时间、练手速顺便整理一份自己的答题模板库把SQL窗口函数模板、指标拆解模板、业务分析框架模板都沉淀下来。这套节奏的核心逻辑是前两个月把工具练到顺手最后一个月把思维练到专业。资源方面SQL可以刷LeetCode数据库题库和HackerRank的SQL模块重点练中高难度题Python就盯住pandas官方文档和一本讲数据分析实战的书把groupby、merge、apply这些高频API用熟统计和业务分析方面可以看一些AB实验和数据驱动决策的经典书籍网上也有不少数据分析面经帖可以借鉴。上面这些热搜词里我特别想点一下数据分析项目——很多人笔试准备只是刷题我建议一定要完整做一个端到端的数据分析项目包括取数、清洗、分析、可视化、结论输出。做项目的过程中你会把笔试里分散的知识点串联起来形成真正的分析手感。最后再说一个我自己的体会。笔试之前我最担心的其实是业务案例题总觉得没有标准答案、不知道怎么写才算对。后来我发现阅卷人并不指望一个校招生真的能解决业务问题他们想看到的只是你有没有一套自己的思考路径。所以遇到业务题不要慌不要试图憋出一个完美答案而是把你脑子里真实的思考过程分步骤写下来用上指标拆解、对比分析、假设验证这些基本功。哪怕最后的建议很朴素也比空白卷强得多。这个习惯我后来带团队时也一直在用——分析能力不是靠灵光一现而是靠一套稳定、可复用的思考流程。你把这套流程练熟了笔试、面试、甚至以后的工作都会顺很多。