又是一年校招季,每年这个时候后台问数据分析岗笔试的人总是特别多。之前有不少读者在准备58同城2020校招笔试时,会拿着各种零零散散的面经来问我对不对。说实话,数据分析这个岗位的笔试范围是真的大,从SQL、Python到统计概率、业务常识,甚至Excel函数都会考,如果只是零散刷题,很容易漏掉关键得分点。最近在做项目复盘时翻到了当时整理的一套58同城2020校园招聘笔试数据分析方向的备考点,重新梳理了一遍之后,发现里面的考察逻辑对现在想进互联网大厂做数据分析的同学依然有很高的参考价值。这篇博文我就把它完整地分享出来,结合当时的考题分布和我在实际业务中积累的经验,尽量把每一类考点背后的考察意图和使用场景讲清楚。
如果你是正在备战数据分析校招的应届生,或者刚转行准备投递数据分析岗位、但不太确定笔试该从哪些方向下手的初学者,这篇文章应当能帮你节省不少瞎摸索的时间。文中涉及所有代码和思路不仅适用于58同城的笔试场景,放到其他公司的数据分析笔试中同样成立。
1. 从考纲反推岗位画像:58同城数据分析笔试到底在筛选什么人
先别急着刷题,理解一道笔试题背后的出题逻辑,比你多刷十道题都管用。我重新复盘58同城2020校招数据分析笔试时,最大的感受是:这套题的设计逻辑其实非常清晰,它要筛选的不是“会背算法的人”,而是“能把数据变成业务判断的人”。所以在准备之前,先理解一下这个岗位在58同城这样的分类信息平台里,到底承担什么样的角色。
58同城的业务线覆盖招聘、房产、二手车、本地生活服务等板块,用户流量大、信息类目多、双边平台特征明显。这意味着什么?意味着平台每天产生的数据不仅是单纯的“交易数据”,还包含大量“信息发布数据”“用户浏览数据”“供需匹配数据”。数据分析师在这些业务场景里,核心任务往往是这几类:做用户留存分析、评估信息发布质量、追踪供需匹配效率、设计核心指标监控体系。考试题目自然也就围绕这些真实业务场景展开。
我当时把整套笔试题的考察点拆成了四大块,占比大概是这样的:
| 考察模块 | 大致占比 | 考察形式 |
|---|---|---|
| SQL查询能力 | 30%左右 | 手写SQL代码题 |
| 统计学与概率基础 | 25%左右 | 计算题、判断题 |
| Python/Excel数据分析能力 | 20%左右 | 代码补全、流程理解、计算逻辑 |
| 业务案例分析 | 25%左右 | 开放型问答题,需要搭建分析框架 |
在这个结构背后,出题方想要的人其实很明确:SQL必须有实战水平,不是只会select from where;统计和概率的基础必须扎实,因为业务分析中的很多判断本质上就是统计推断;Python和Excel至少精通其中一项,能快速动手处理数据;最重要的是,面对一个业务问题时,能够拆解问题、定义指标、搭建分析链路,而不是上来就说“我要用机器学习”。
理解了这个底层逻辑后,再看每一类题目,你就知道它们考察的不是知识点本身,而是知识点在业务场景中的应用能力。接下来我按模块逐个拆解考题类型,并给出一些可以落到笔头的解决方案。
2. 类型一:SQL手写题,用最朴素的方式拿到最稳的分
SQL这个模块是整份笔试里最“性价比高”的,因为它有标准答案,只要平时写过,基本不会失分。但也恰恰是因为它有标准答案,很多人容易眼高手低,看的时候觉得都会,一到笔试限时手写,各种小错误全冒出来了。58同城2020数据分析笔试里的SQL题,风格很贴近58、赶集这类分类信息平台的业务数据,常见的表也就是用户表、信息发布表、浏览记录表、订单表这几类,考察点集中在:去重、分组统计、留存计算、窗口函数排序和一对多关联时的数据准确性。
先说说最基础也是最重要的一个场景——去重统计。平台里的用户可能一天有多次访问记录,表里就会产生多行记录。笔试里很典型的题目是统计每日活跃用户数,要求同一个用户当天只计算一次。很多人在这一步会用distinct,这是没问题的。但紧接着题目可能会加一个条件,比如“只看在发布过有效信息的城市活跃的用户”,这时候关联表以后distinct可能会让结果数变小,因为关联产生了数据膨胀后,再把两列一起distinct就错乱了。我当时在笔试时特意留了个心:凡是涉及多表关联后的去重,写SQL之前先在草稿纸上画一下主表和关联表的粒度关系。
再聊一个高频考点,留存分析。分析用户次日留存、7日留存是业务分析中每天都要做的事,笔试里一般不会让你用很复杂的case when套嵌,而是考察你能不能把留存计算逻辑写清楚。假设有一张用户登录时间表user_login(user_id, login_date),要计算每个自然日的次日留存率,我当时写的思路是这样的:
with user_first as ( select user_id, min(login_date) as first_date from user_login group by user_id ) select t1.first_date as stat_date, count(distinct t1.user_id) as new_user_cnt, count(distinct t2.user_id) as retained_user_cnt, round(count(distinct t2.user_id) * 1.0 / nullif(count(distinct t1.user_id), 0), 4) as day1_retention_rate from user_first t1 left join user_login t2 on t1.user_id = t2.user_id and t2.login_date = date_add(t1.first_date, 1) group by t1.first_date order by t1.first_date;这段代码的核心逻辑就是先取出每个用户的首登日期作为新增日期,然后和登录表做关联,关联条件里限定“首登日期的后一天也登录了”。用left join而不是inner join,是因为要保留那些次日没有回来的用户作为分母。这段代码看起来不复杂,但笔试时有个很常见的坑:直接用user_login表做关联,没有先算每个用户的首登日期,结果一个用户只要在后续任意一天登录过,就被错误地算成了“某天的次日留存”,留存率虚高。这个错我在平时练习时踩到过,后来养成了“凡是说新增用户,先想清楚定义”的习惯。
接下来是窗口函数,58同城笔试里出现过类似于“给每个城市下的每个类目的信息发布量排序,取每个城市发布量最高的前3个类目”这类题目。这种题目用row_number()是最直接的,但很多人会在partition by和order by上写反。比如:
select city, category, publish_cnt, row_number() over (partition by city order by publish_cnt desc) as rn from ( select city, category, count(*) as publish_cnt from info_publish group by city, category ) t where rn <= 3;一个小细节:rn这一列是在子查询的select里算出来的,外层where直接引用rn在部分数据库里会报错,因为SQL的执行顺序里where是在select之前过滤的。笔试手写时建议直接在子查询外层套一层select过滤,稳妥一点。另外,如果题里要求并列的名次也算同一个名次,就需要用dense_rank()而不是row_number()。这两个函数的区别在笔试里是送分题,但很多人一紧张就忽略条件里的“并列”两个字。
说完了SQL的具体题型,我觉得还有一个特别值得展开的地方:为什么笔试题里明明有简单的先聚合再关联的写法,但出题人却偏要把一对多关联放在题目里?因为在实际业务表里,一对多几乎是无处不在的。一个用户对应多条浏览记录、一个店铺对应多条商品信息、一个订单对应多个商品明细。SQL笔试真正要考的就是你面对这种数据模型时,能不能快速判断哪个表是事实表、哪个表是维表,然后选择正确的聚合粒度。我实践经验是,先搞清楚粒度再写SQL,错误率能降低一半以上。
3. 类型二:统计概率与AB实验基础,不用背公式但要懂场景推断
在58同城这类平台做数据分析,统计知识不只是用来考试的,它是每一个业务结论的“合法性”来源。笔试里统计概率题的分值不低,而且往往是那种看起来每个选项都对、实际上只有一个真正理解概念的人才能选对的题。我复盘时发现,2020年这批笔试题涉及的统计考点主要有:条件概率计算、期望值推导、假设检验中的p值解读、置信区间含义、AB测试的结果判断等。题目本身不算难,但考察的绝对不是你能否背出t分布的公式,而是你能不能识别出在什么场景下使用什么推断逻辑。
这里面最典型的就是p值这道送命题。题目大概会给你一个AB实验的结果:实验组点击率5%,对照组点击率4.8%,p值等于0.03,然后问下列哪种解读是对的。很多人一看p值小于0.05,直接选“实验组显著优于对照组”,这个选项往往是错的。正确的解读应该是“在原假设为真的前提下,观察到当前或更极端结果的概率是3%”。这背后的含义是,p值不是一个“效果概率”,而是一个证伪逻辑。出题人就是想看看你是否真的理解假设检验的语义,还是在机械地执行“p<0.05就显著”这个规则。
我当时备考时专门梳理了几个容易混淆的统计概念,这里也一并贴出来,你可以直接对照理解:
| 概念 | 常见误解 | 正确理解 |
|---|---|---|
| p值 | 犯错的概率 | 原假设为真时,观测到当前数据的概率 |
| 置信区间95% | 参数有95%的概率落在区间内 | 反复抽样时,95%的区间会包含参数真值 |
| 显著 | 效果量一定很大 | 样本量足够大时,微小的差异也能显著 |
| AB测试显著性提升 | 可以立即全量 | 还要评估业务收益、成本、长期影响 |
尤其是最后一行,我平时做分析时感受非常深。技术上显著性达标了,业务上不一定就能直接推全。比如一个策略能提升点击率0.2个百分点,在每天千万级流量的情况下统计上是显著的,但如果需要很大的运营成本来维护这个策略,ROI可能根本不划算。数据分析笔试里经常考这种“统计显著≠业务显著”的辨析题,遇到这种题,思路应该从统计概率跳到商业收益视角展开。
再来说贝叶斯和期望值。2020年笔试里出现过一类题:已知某城市用户中,大概有10%是付费用户,通过某个行为特征识别付费用户的准确率是80%,误报率是20%,求“被该行为特征标记的用户真的会付费的概率”。这道题其实就是贝叶斯公式的应用,但很多人看到数字就开始直接乘除出错了。正确做法是设一个具体的总人数(比如1000人),算出100个真付费中标记出的80人,再加900个非付费中误报的180人,最后结果是80除以260,约30.77%。这类题在笔试里很常见,它不考复杂公式,但考你情景转换能力。
期望值的计算通常以业务收益的方式出现。比如:某信息发布平台置顶推广位每个曝光赚0.5元,若用户点进详情页则额外赚2元,点击概率是10%,求每个曝光的期望收益。这个就是0.5 + 2×0.1 = 0.7元,很基础。但如果题目再给一个条件“只有广告主余额大于100元时才触发投放”,你就要考虑这个筛选条件对流量规模的影响了。笔试里这类延伸条件设计往往是想看你在不确定性条件下做决策的能力,而不单单是计算能力。
关于AB试验部分,我还想多说两句。笔试不会让你写完整的AB实验平台搭建方案,但会给出一个简化的业务场景,让你判断实验分组是否合理。典型的坑是:直接按用户ID奇偶分组、按注册时间先后分组、对已经知道高活跃用户特征的群体单独分组。这些分组方式会导致实验组和对照组在活跃度、消费习惯等维度上不均衡,进而污染实验结果。正确的做法应该是用户粒度的随机分组,并在分组后做一次AA测试或者特征平衡性检验。这个思路既是笔试的答案,也是我实际工作中做任何策略评估时会优先检查的步骤。
4. 类型三:Python和Excel,数据清洗与可视化的实战能力摸底
说实话,很多备考数据分析的同学会把大部分时间花在SQL和统计上,对Python和Excel这部分题不太上心,觉得“反正笔试时间短,考不了太深”。但从我看到的58同城2020数据分析笔试和近年来的校招笔试趋势来看,Python和Excel的实操考查比重在逐渐增加,因为业务部门不吃“只会写SQL提数”的人,他们需要的是能拿到数据后独立完成清洗、分析、可视化这条流水线的分析师。笔试里不会要求你现场写一个完整的机器学习模型,但一定会通过几个代码片段和小问答题,来验证你的数据处理基本功。
Python方面,最常考的是pandas库的常规操作。2020年笔试题里有一道很典型的:给出一份订单DataFrame,包含order_id、user_id、order_time、city、amount、status几个字段,要求做数据清洗后的汇总统计。表面上这是考pandas,实际上是在模拟日常工作中第一个真实场景:拿到一份基础数据表,先清洗后分析。我当时在准备的笔记里整理过一套可复用的流程,这里给你一个精简版:
import pandas as pd # 1. 读取 df = pd.read_csv('order.csv', parse_dates=['order_time']) # 2. 清洗:去重 df = df.drop_duplicates(subset=['order_id']) # 3. 清洗:处理缺失值 # 注意:先看缺失比例再决定怎么填充 # 城市缺失但金额不为空时,可以用众数填充;金额缺失但其他字段完整时,可先置为0再单独标记 df['city'] = df['city'].fillna(df['city'].mode()[0]) df['amount'] = df['amount'].fillna(0) # 4. 衍生字段:提取日期 df['order_date'] = df['order_time'].dt.date # 5. 分组聚合:统计每个城市每日订单金额 daily_city = df.groupby(['order_date', 'city'])['amount'].agg(['sum', 'count']).reset_index() # 6. 排序与TopN top_city = daily_city.sort_values('sum', ascending=False).head(10)这道题背后隐藏的考点其实是:你知不知道dt.date这个用法?你知不知道groupby之后要用reset_index()才能把分组键转回列?如果你平时只跑教科书上的例子,可能对这些细节并不敏感。我在实际业务里处理过大量订单数据,总结下来,最浪费时间的往往不是分析本身,而是前面几十分钟的清洗环节。谁能在清洗环节少踩坑,谁就有更多时间做真正的业务洞察。
Python笔试里另一个高频考点是自定义函数和apply的用法。比如要求写一个函数,把订单状态字段映射成中文标签,然后通过apply应用到DataFrame列上。这种题目非常“业务日常”,因为几乎所有公司内部的数据表状态字段都是英文缩写,比如success、pending、failed,而业务方要看的报表是中文标签“成功”“处理中”“失败”。有些同学到了笔试现场还在用for循环一行行遍历赋值,既慢又容易出错,用apply一行就能解决。
def map_status(status): mapping = {'success': '交易成功', 'pending': '处理中', 'failed': '交易失败'} return mapping.get(status, '未知状态') df['status_cn'] = df['status'].apply(map_status)再说Excel,这是一个很多人在简历上写了“精通Excel”,但一到笔试就露馅的部分。58同城笔试的Excel题不直接考界面操作,而是通过描述一个数据处理需求,问你应该用哪个函数,或者给一段公式让你判断输出结果。最经典的无非就是VLOOKUP和IF嵌套组合。比如:有一个订单明细表和一个用户注册表,需要根据user_id匹配用户所在城市,很多人的第一反应就是VLOOKUP,但对“VLOOKUP只能从左往右找”这个限制并不清楚。如果目标列在匹配列左边,VLOOKUP就无能为力,需要改用INDEX加MATCH组合。这个知识点在2020年笔试里出现过一道选择题,选项就是VLOOKUP、INDEX+MATCH、LOOKUP和XLOOKUP的优劣对比。平时用Excel做数据报表的人可能会觉得这太简单,但只靠临时抱佛脚的同学很容易在这道题上翻车。
数据可视化这块,笔试通常不会让现场做图,但会给一张图表,让你解读其中的趋势和异常点。比如给出一张“近30天全站信息发布量趋势图”和“同期浏览量趋势图”,问为什么浏览量下跌了但发布量上涨,可能的业务解释是什么。这种题没有标准答案,但需要你能从数据趋势和业务逻辑两个角度给出合理推断:可能是投放导流策略变化,可能是审核规则调整导致发布门槛降低,也可能是某个大促或假期导致的周期性波动。重点不在于你的答案必须绝对正确,而在于你的思考路径是否包含了“数据指标下降不等于业务变坏”的多维度归因意识。
如果你想要在Excel和Python之间找到一个又好学又好用的切入点,我推荐去了解下Excel里直接用Python处理数据的插件,这在当时是我们做日常数据整理时特别提效的一个工具。它不需要你在两个软件之间来回切换,可以在Excel表格中直接运行Python脚本,实现复杂清洗和数据转换。笔试的时候一般不指望你用这种组合拳,但在实际工作和简历项目里,这绝对是个加分展示点。
5. 类型四:业务案例分析题,从标题热词到完整分析框架
笔试的重头戏,也是拉开分数差距最大的模块,就是业务案例分析题。2020年58同城校招数据分析笔试里,业务题占到了四分之一左右,而且全都是开放题。这种题目看起来没有标准答案,实际上阅卷人的眼里是有明确的采分点的。我在复盘这套题的时候,能明显感觉到出题人关注的是:能不能拆解问题、能不能定义核心指标、能不能搭建分析链路、能不能根据数据给出可行的业务动作。
先说一道贴近58同城业务的典型题:“某城市站点的信息发布量近两周持续下滑,请给出你的分析思路”。如果你遇到这种题,千万不要上来就写“因为竞品抢走了用户”这种拍脑袋的结论。数据分析最基本的一条原则就是,任何结论都必须有数据支撑。我当时给自己定的答题框架是四步走:
第一步,口径确认。先确认信息发布量的统计口径是什么,是新增发布的帖数、审核通过的帖数,还是最终在前台展示出来的帖数?这一步非常关键,因为很多线上指标的下滑只是口径调整导致的“假下滑”,比如统计时把测试帖纳入导致上周基数虚高,这周清理掉后自然下跌。
第二步,维度下钻。从城市、类目、用户类型(新用户/老用户,个人用户/商家用户)、设备端(App/PC/H5)等多个维度拆分,找出下滑是全局性还是局部性的。如果只有某几个类目在跌,问题大概率出在供给端或审核端;如果全类目都在跌,问题可能出在流量端或平台政策端。
第三步,归因分析。结合时间线看,下滑是从哪天开始的,那一天前后是否有业务策略调整、产品功能改动、审核规则收紧、市场环境变化等事件。比如平台调整了信息发布审核策略,导致一批低质量帖被过滤,发布量确实会下降,但用户看到的帖子质量可能反而变好,这时候单纯的发布量下滑就不是一个需要“修复”的问题。
第四步,给出建议。分析不只是为了发现问题,还要能推动决策。如果确认是某类目供给被竞品分流,建议是加大对应类目的运营补贴;如果是审核通过率下降导致,建议是优化审核规则或提高信息质量;如果是App端流量下滑,建议是联动用户增长团队做针对性召回。
这道题背后考官真正想看的是你有没有数据分析思维。你不需要真的知道58同城当时业务发生了什么,只要你展示出“多维度拆解、定义指标、结合业务归因”的完整思路,分数就不会低。
再来看另一类业务题,拉新和付费转化这类电商和本地生活服务平台最常见的漏斗分析。比如给你注册到发布的转化漏斗:访问落地页10000人,注册完成5000人,发布信息500人,问哪一步流失最严重,如何优化?很多人第一反应是“发布信息只有5%,所以发布环节流失最严重”,这个判断没有错,但不够完整。更深入的分析应该结合每一步的流失成本和优化空间来看:注册环节流失了50%,但解决方案可能是简化注册流程,改成一键登录,改动成本低;发布环节流失了90%,但用户可能是来看房、找工作的,本来就不一定要发布,这个环节的“流失”未必是问题。所以,做漏斗分析时,不能只看同级转化率的高低,还要结合业务逻辑判断哪些流失是“健康的漏斗收缩”,哪些流失才是“真正的优化机会”。
再有就是分层分析题。分类信息平台最常见的用户分层方式是按身份分:需求方和供给方;按活跃度分:新用户、周活用户、月活用户、沉默用户;按贡献分:高价值用户、普通用户、低价值用户。笔试里可能会给你一段用户行为数据,让你设计分层规则,并针对不同层给出差异化的运营策略。我当时的答题思路是:先用RFM模型做用户分层,R是最近一次行为距今间隔,F是行为频次,M是价值贡献。比如把用户按R和F分成四类:高R高F是核心用户、高R低F是活跃但频次低的用户、低R高F是有粘性但近期不活跃的用户、低R低F是流失风险用户。然后针对每一类给出策略。RFM模型虽然经典,但在实际业务里只要不过度复杂化,依然是快速切入用户分层的好方法。
此外,业务题还特别喜欢考察“指标异常波动的归因”,这直接对应了数据分析岗位的日常核心工作。我的经验是,答这类题一定要形成“数据求证+多维拆解+事件关联+落地建议”的肌肉记忆,平时多看看平台指数的异常波动案例,对建立业务敏感度非常有帮助。当年做数据分析项目时,我把大量时间花在对比正常波动区间和异常点上,后来笔试遇到这类题,基本不用过多思考就能整理出答案结构,熟能生巧是真的。
6. 进阶与加餐:结构化思维、工具链和备考节奏复盘
如果你能把前面四个模块都准备扎实,基本已经可以应付笔试中的绝大多数常规题目。但如果目标是高分通过,或者说想在候选人里排到前列,那么有两样东西是值得额外发力的:一是应对“送分但容易丢分”的细节题,二是笔试时间分配的节奏控制。
先说说细节题。58同城2020校招笔试里有几道让我印象很深的细节题,不是不会做,而是如果平时没有积累,现场会犹豫很久。比如有一道概率题:一个班级有50人,问至少有两个人生日相同的概率是多少?这个题目背后是经典的生日悖论,正确答案大约在97%左右,但由于它违反直觉,很多人会选择一个很小的数值。如果做过一遍,就不会在考场上发怵。再比如有一道关于样本量和统计功效的题,问“样本量增大时,p值会怎么变化”,很多人只记得p值越小越显著,却忽略了样本量对p值的影响机制。这类题需要的是考前对经典统计案例的过目,不需要深入推导,但要熟悉结论和直觉。
在时间分配方面,我自己有一套比较稳的策略,也推荐你参考:拿到试卷后先用2分钟快速浏览全部题目,判断每道题的难度和预计耗时。优先做SQL题和计算题,这类题有明确答案,得分效率高;再做Python代码补全题,这类题通常有提示、方向明确;统计概念题和业务开放题安排在中段,保证有足够时间展开思路;最后留10到15分钟检查前面写的SQL是否存在语法和逻辑漏洞。笔试和面试不同,面试更看沟通表达,笔试更看重准确率,所以宁可在容易得分的SQL题上多花两分钟自查,也不要留一堆开放题写不完。
说起工具链,这里还想多说一句。现在数据分析的生态越来越丰富,除了Python和Excel,很多平台也把SQL查询、图表可视化、数据处理流程打通到了一个工具里。如果你日常工作要频繁做数据清洗和可视化,可以看看dify这类能够承接数据清洗和分析流水线的平台,或者像dbeaver这种可以和数据库联动做图表可视化的工具,它们能在处理“脏乱差数据”的时候节省不少时间。对于笔试备考来说,不要求你掌握这些工具的所有细节,但能够说出一个完整的数据分析工具链——数据从哪来、怎么接入、怎么清洗、怎么分析、怎么可视化——会让你的简历项目和面试表达都更有说服力。
很多同学在备考数据分析时,总想着要面面俱到,把机器学习算法也深挖一遍。但从58同城2020校招数据笔试和我后来分享过的多个笔试复盘来看,校招笔试阶段对机器学习模型的考查其实很浅,最多就是考你无监督学习中的聚类概念,比如KMeans的适用场景、如何选择K值、和标签体系的区别。没必要在笔试前啃完一本《统计学习方法》,你更需要的是把SQL写熟练、把pandas用顺手、把统计概念理解到位、把业务分析思维理清楚。这四项能力对笔试分数的提升是立竿见影的。
复盘到这儿,我觉得最有价值的其实不是某道题的答案,而是这套备考框架本身。数据分析这个岗位,表面上是“分析数据”,本质上是在“用数据思维解决业务问题”。笔试只是检验的第一步,到了真实工作里,你会发现每天面对的不再是工工整整的考题,而是各种口径混乱、数据缺失、业务诉求模糊的真实场景。你能不能在混乱中找到关键变量,能不能在不可控中找到相对确定的规律,才是真正拉开分析师之间差距的地方。希望这篇复盘能帮你少走一些弯路,把时间花在最值得的地方。