小红书2019校园招聘数据分析岗在线笔试（第二批）复盘：题型拆解与备考思路
2019年秋季，我参加了小红书校招数据分析岗的第二批在线笔试。那次笔试给我的感觉是：题型不偏，但覆盖面很广，从SQL到概率统计再到业务案例分析都有涉及，而且非常看重候选人能不能用数据思维去理解社区产品。这篇文章不是原题复述（毕竟平台有保密要求），而是结合那次笔试以及后续面试中反复出现的考核点，把数据分析岗校招笔试的完整备考框架整理出来，给正在准备类似岗位的读者一个参考。
无论你是准备小红书、还是其他互联网公司的数据分析岗位，只要笔试环节包含“SQL + 统计 + 业务题”这三个模块，这篇文章的思路都可以直接复用。我会从岗位能力模型讲起，逐类拆解题型，再分享实际的做题顺序、时间分配和踩坑经验。
1. 笔试前先搞明白：数据分析岗在筛选什么能力
1.1 校招笔试的定位：不是考你会多少，而是看你怎么思考
很多人以为在线笔试就是刷题，把SQL语法和概率公式背熟就能过。但小红书这类内容平台的校招笔试，实际考察的重点是：你面对一堆表和业务问题时，能不能快速建立分析框架。
2019年那批笔试整体是“选择题 + 问答题 + 编程题”的组合，题量大概在40道左右，时间是90分钟到120分钟。选择题偏统计和概率基础，问答题偏向业务场景，编程题主要考SQL或简单的Python数据处理。这和社招面试不同，校招候选人没有太多真实项目经验，笔试是最快的筛选方式，筛的不是知识储备，而是“能不能用逻辑拆解一个不熟悉的业务问题”。
1.2 三个核心能力维度
我在备考时把能力要求拆成三层，笔试的每一道题基本都能落到这三层里面：
- 数据提取能力：给你一套表结构，你能不能写出正确的SQL，取数逻辑是不是严谨。这一层考察的是硬功夫，SQL的窗口函数、多表关联、去重逻辑是高频考点。
- 量化分析能力：给一个业务指标，你能不能判断它的波动是否显著，能不能用概率模型去解释现象。考察的是统计学功底，假设检验、常见分布、贝叶斯公式几乎必考。
- 业务落地能力：给一个产品问题，比如“社区笔记曝光量下降了”，你能不能拆解原因、给出可执行的建议。考察的是分析思维，也是数据分析师区别于取数工程师的核心能力。
这三个维度的比重，在笔试里大约是SQL 40%、统计概率30%、业务分析30%。我这样说不是为了给出一个精确比例，而是提醒大家，别把时间全押在SQL刷题上，业务分析和统计思路上也需要专项训练。
2. SQL题：先读懂业务表，再谈写代码
2.1 考场上你会看到什么样的表结构
小红书这类产品，数据表一定是围绕“人、内容、互动、交易”来设计的。笔试给出的表结构通常不会太复杂，但会尽量贴近真实业务。我整理了一个典型的表结构示例，大家可以参考：
- 用户表（user_info）：user_id（用户ID）、register_date（注册日期）、city（城市）、gender（性别）
- 内容表（content_info）：content_id（内容ID）、author_id（作者ID）、publish_date（发布日期）、content_type（图文/视频）、category（品类）
- 互动表（interact_log）：user_id（互动用户ID）、content_id（被互动的内容ID）、interact_type（点赞/收藏/评论/转发）、interact_time（互动时间）
- 订单表（order_info）：order_id（订单ID）、user_id（用户ID）、goods_id（商品ID）、pay_amount（支付金额）、order_time（下单时间）
这类表结构是内容电商平台的“通用骨架”，笔试题目基本都围绕这些表展开。看到题目的第一步，不要急着写代码，先把表之间的关联字段找出来，想清楚你要的是“用户维度”的数据还是“内容维度”的数据，再动手写SELECT。
2.2 高频题型：留存率、漏斗、TopN和环比同比
从我做过的笔试和经验汇总来看，SQL题翻来覆去就是几个固定套路：
- 留存率计算：给定用户登录/活跃表，求某一天新增用户在之后第N天的留存率。题眼在于“新增用户”的定义，通常要用子查询先圈定新增用户，再关联后续活跃记录，保留率的分母是新增用户数。
- 漏斗转化：给定浏览→加购→下单行为日志，求每一步的转化率。经典写法是分段统计或者JOIN多个聚合结果。
- TopN问题：“各品类下支付金额最高的前3个用户”这类题目，需要用窗口函数ROW_NUMBER()或RANK()按品类分组排序。2019年那会儿窗口函数在一些笔试平台里已经支持，但也有平台只支持MySQL 5.7及以下版本，这时候就要用“用户变量 + 自连接”来实现分组TopN，非常痛苦。建议备考时两种写法都练一下。
- 同比环比：“某渠道本月支付金额较上月增长了多少”，这题本质是日期处理 + 自关联。要注意月初月末的边界，以及日期字段的数据类型转换。
2.3 一个典型SQL题的完整思路
举个例子，如果笔试让你“统计2024年1月每天的新增用户数，以及这些用户在次日、7日、30日后的留存数”，可以这样拆解：
先定义什么叫做“新增用户”：当天注册，并且注册日期是第一次出现的日期（通常用户表里每个用户只有一条注册记录，所以直接取register_date即可）。然后先建一个每日新增用户表：
SELECT DATE(register_date) AS reg_date, COUNT(DISTINCT user_id) AS new_user_cnt FROM user_info WHERE register_date >= '2024-01-01' AND register_date < '2024-02-01' GROUP BY DATE(register_date);接着计算次日留存。留存的定义是：这些新增用户中，在注册次日也有活跃行为（登录、发布、互动均可）的用户比例。这里需要一张活跃表active_log，然后通过LEFT JOIN把活跃记录关联到新增用户上：
SELECT a.reg_date, a.new_user_cnt, COUNT(DISTINCT b.user_id) AS retain_1day_user FROM ( SELECT DATE(register_date) AS reg_date, user_id FROM user_info WHERE register_date >= '2024-01-01' AND register_date < '2024-02-01' ) a LEFT JOIN ( SELECT user_id, DATE(active_time) AS active_date FROM active_log WHERE active_date = DATE_ADD(a.reg_date, INTERVAL 1 DAY) ) b ON a.user_id = b.user_id GROUP BY a.reg_date, a.new_user_cnt;上面这段SQL在MySQL里不能直接引用a.reg_date，因为子查询的别名在多层嵌套中有作用域限制。比较稳妥的写法是把活跃记录先按用户去重，再一次性关联。实际笔试时，我先写一个“用户活跃日期表”（每个用户每天去重），然后通过JOIN条件限制活跃日期等于注册日期+1，这样逻辑更清晰：
WITH reg AS ( SELECT user_id, DATE(register_date) AS reg_date FROM user_info WHERE DATE(register_date) BETWEEN '2024-01-01' AND '2024-01-31' ), active AS ( SELECT DISTINCT user_id, DATE(active_time) AS active_date FROM active_log WHERE DATE(active_time) BETWEEN '2024-01-02' AND '2024-03-01' ) SELECT r.reg_date, COUNT(DISTINCT r.user_id) AS new_cnt, COUNT(DISTINCT CASE WHEN a.active_date = DATE_ADD(r.reg_date, INTERVAL 1 DAY) THEN r.user_id END) AS retain_1d FROM reg r LEFT JOIN active a ON r.user_id = a.user_id AND a.active_date BETWEEN DATE_ADD(r.reg_date, INTERVAL 1 DAY) AND DATE_ADD(r.reg_date, INTERVAL 30 DAY) GROUP BY r.reg_date;需要注意的细节是：留存计算的时间窗口越长，活跃表要过滤的范围越大，否则数据量一大，JOIN的性能就会出问题。笔试虽然数据量不大，但养成这个习惯，面试手撕SQL时也会显得思路清晰。
2.4 SQL备考建议：无他，但手熟尔
练SQL没有捷径，但我有一个很有效的方法：不要只看题解，而是把每道题自己跑一遍。我当时用了本地MySQL搭了一个模拟数据环境，把牛客网和LeetCode上的SQL题都刷了一遍，每次写完都顺手把执行计划和结果检查一遍。另一个建议是，考前重点看窗口函数的语法，包括ROW_NUMBER、RANK、DENSE_RANK、SUM() OVER(PARTITION BY ...)，因为窗口函数能解决80%的“分组内排序”“分组内累计”类题目。
3. 统计与概率题：背公式之外，更要懂场景
3.1 选择题里的统计学高频考点
这类题往往是选择题或填空题，考察范围很集中。我复盘了当时遇到的考点，结合同批次同学分享的信息，以下内容反复出现：
- 常见分布：正态分布、二项分布、泊松分布、均匀分布，以及它们的期望和方差。比如“某App每天平均收到1000次举报，求一天内收到至少1050次举报的概率”就是典型的泊松分布近似。
- 条件概率与贝叶斯公式：给一个“患病率+检测准确率”的经典问题，求检测阳性后真实患病的概率。这类题的关键是别被95%置信度绕晕，要先把条件概率的分子分母搞清楚。
- 抽样与估计：标准误和标准差的区别，置信区间怎么解释。注意置信区间不是概率区间，而是重复抽样下参数落入区间的频率。
- 假设检验：p值、一类错误和二类错误、功效（power）的概念。注意差异，比如“p值小于0.05就代表原假设为假的概率小于0.05”是错误说法。
3.2 简答题可能出现的概率计算
除了选择题，笔试还可能出几道需要手算的简答题。例如：
假设某内容平台上，视频内容的平均完播率是30%，图文内容的平均读完率是60%。现在随机抽取一个内容，其中视频占70%，图文占30%。问：抽到一个完播率超过50%的内容，它是视频的概率是多少？
这类题就是贝叶斯公式的应用。解题过程要写清楚：
- 设事件V为视频内容，T为图文内容，A为完播率超过50%。
- P(V) = 0.7，P(T) = 0.3。
- 需要根据分布信息计算P(A|V)和P(A|T)。这里如果假设完播率服从正态分布或均匀分布，可以估算。例如假设完播率在[0,1]服从均值为0.3的分布，那么P(A|V)不是简单说“50%以下”，而要明确分布形式。若简化为均匀分布，则P(A|V) = (1-0.5)/(1-0) = 0.5，不过这个假设过于粗糙。更合适的是假设完播率服从Beta分布，用累计概率计算。
这种题目考的不是你算得多么精确，而是你能不能把条件概率的定义和计算流程清晰地写出来。我在答题时特意把贝叶斯公式先列出来，再代入数值，即使最后结果算错了，步骤分也能拿到。
3.3 统计题回答时的两个习惯
第一，单位不要漏。概率题经常有百分号和小数点混用的情况，比如“提升5个百分点”和“相对提升5%”是完全不同的概念。第二，结论要有业务解释。写一道概率题最后最好加一句话：“这说明在小红书这样的内容平台上，虽然视频内容占比高，但遭遇完播率超过50%的内容更可能来自图文，因为图文的基准读完率更高。”这样哪怕计算有小问题，也能向面试官展示你的业务敏感度。
4. 业务案例题：用结构化思维拆解开放问题
4.1 典型的业务题长什么样
这类题通常没有标准答案，但特别能拉开差距。我记得当时有一道大致的题目方向是：
“某个月平台上笔记的日均发布量出现了明显下滑，请你分析可能的原因，并设计一套分析方案。”
这题看起来像产品面试题，实际上考察的是数据分析师如何把业务问题转化为可量化的分析问题。正确的思路不是直接说“可能是假期原因”，而是给出一个“假设清单 + 验证方法”的框架。
我的回答思路大致分四步：
- 定义指标：先确认“日均发布量”的口径，是每天发布的内容数，还是发布人数？是去重后的曝光量还是可展示的内容量？口径不同，分析方向完全不同。
- 拆解维度：把总量下拆到“新用户发布”和“老用户发布”，再进一步看“发文人数”和“人均发文数”。哪个环节下降明显，问题就聚焦在哪里。
- 列举假设：原因可能包括季节性因素（学生放寒暑假）、产品功能迭代（发布入口改版）、内容审核策略变动（违规内容过滤增多）、竞品分流、外部热点变化等。
- 验证方案：该查什么数据、做什么分析来验证每个假设。比如要验证审核策略变动，就看同期审核拒绝率和内容通过率；要验证发布入口改版，就查各入口的漏斗转化数据。
4.2 为什么这类题是笔试的分水岭
SQL题和概率题大家刷一刷都能对付，但业务案例题能直接筛掉一批只会死记硬背的候选人。2019年那批笔试的感受是，业务题占比不算特别高，但一旦出现，分值就很大，而且答题质量直接影响能不能进入面试。
好的业务题回答有几个共同点：
- 不急着给结论，先拆分问题边界。
- 能用指标和量化的语言来描述“可能的原因”，而不是空泛地说“运营没做好”。
- 提出的验证方案具有可执行性，能让面试官顺着你的思路想象出数据图表。
- 最后会给出“可以监控哪些指标”或“建议做哪些实验”来进一步判断，体现闭环思维。
4.3 案例延展：如果问题是“完播率下降”或“广告收入下滑”
同一个框架可以套用到很多业务题上。比如“信息流广告的eCPM下降”，我会拆解为eCPM = 广告出价 × 点击率 × 转化率，然后逐项排查是出价策略调整、广告素材吸引力下降，还是落地页加载速度变慢导致转化降低。再比如“视频完播率下降”，拆分为内容时长结构变化、推荐算法分发变化、用户观看环境（网络、时间）变化、视频清晰度与卡顿率变化。
准备业务案例题的高效方法是：在笔试前找5-6个常见的业务场景（用户留存下降、推荐点击率降低、GMV未达标、内容互动率下降、广告收入波动），每个场景都写一个“分析预案”，不需要背下来，但要在脑海中形成条件反射式的框架。
5. Python编程题：不一定是必考，但会了有备无患
5.1 笔试中Python题的常见形式
2019年那次笔试，Python不是每套题都有，有的批次是“SQL + 统计”，有的批次加了一道Python处理数据的小题。但近年来校招笔试Python的出现频率越来越高，建议备考时至少掌握pandas的基本操作。
常见题型包括：
- 用pandas读取一份CSV日志，完成数据清洗：去重、缺失值填充、字段格式转换。
- 统计分组聚合：按用户分组计算平均消费金额、按城市分组计算活跃用户数。
- 简单可视化：用matplotlib画柱状图或折线图，考察的其实就是把数据结构和图表参数对上的能力。
5.2 一道典型的pandas小题
如果笔试题目是“用Python统计每个用户每天的内容发布数量，并找出发布数量TOP10的用户”，参考答案会是这样：
import pandas as pd df = pd.read_csv('publish_log.csv', parse_dates=['publish_date']) df['publish_date'] = df['publish_date'].dt.date daily_cnt = df.groupby(['user_id', 'publish_date']).size().reset_index(name='cnt') top10_user = daily_cnt.groupby('user_id')['cnt'].sum().nlargest(10) print(top10_user)这类题考得很基础，但仍会出现一些低级错误，比如读CSV后忘了转换日期格式，或者groupby后没有reset_index导致后续操作报错。写代码时先想清楚数据类型，再执行操作，能节约很多调试时间。
5.3 不会Python行不行
如果你目前只会SQL，也先别慌。笔试中Python题的分数占比通常不高，而且有的公司允许用“SQL 或 Python任选”的方式完成。但如果目标是长期做数据分析师，Python几乎是必学的，因为日常分析中很多工作（爬虫、自动化报表、复杂统计建模、机器学习）需要用Python来完成。我的建议是：笔试前至少学完pandas的“数据读取、筛选、分组聚合、合并”这四个模块，有余力再看一点numpy和matplotlib。
6. 答题顺序与时间分配：策略比蛮干重要
6.1 我采用的做题顺序
在线笔试的时间其实很紧，尤其是有SQL编程题和业务简答题时，很容易陷入“一道题卡太久，后面的题没时间看”的困境。我的经验是：先快速浏览全卷，把题目类型和分值分布标出来，然后按下面的顺序答题：
- 先做业务分析简答题。这类题不需要精确计算，只需要思路清晰，在头脑清醒时写出来的回答质量最高。
- 再做SQL编程题。SQL题需要逻辑连贯，趁精力充沛时集中攻克。
- 最后做选择题和统计概率题。选择题能快速拿分，计算量也不大，如果时间不够还可以蒙。
这个顺序并非绝对，但能保证“分值最大的题先拿到手”。我见过不少同学在选择题上花了太多时间，结果最后一道SQL大题因为时间不够只写了一半，非常可惜。
6.2 时间分配参考
假设笔试总时长120分钟，题量45道，我会大约这样分配：
- 前10分钟：浏览全卷，标记题目类型和分值。
- 30分钟：完成业务简答题（通常2-3道）。
- 45分钟：完成SQL大题（通常2-3道）。
- 25分钟：完成统计概率和选择题。
- 10分钟：检查遗漏题目，补充不完整的答案。
重点提醒：在线笔试的编辑器往往没有自动保存功能，如果是纯网页答题，最好每完成一道题就点一次保存。有些平台在失去焦点或网络波动时会自动提交，所以做题时不要频繁切换浏览器窗口，避免被系统判定为作弊。
7. 常见问题与避坑指南：真实踩过的坑都在这
7.1 笔试环境的坑
在线笔试最大的不确定性来自环境。我所在那年，笔试平台要求用指定浏览器，且不能开任何外部通讯工具。有几个问题特别常见：
- 网络波动导致答案没提交。解决办法是考试前先测速，准备一个备用网络热点。
- 浏览器兼容问题导致代码编辑器无法正常补全。考前一定要提前登录平台测试设备，检查摄像头、麦克风、浏览器版本是否符合要求。
- 误开广告拦截插件导致页面元素加载异常。建议考试时使用一个干净的浏览器配置，关闭无关插件和弹窗拦截。
7.2 答题技巧的坑
- 别在“用SQL取数”时忘记去重。很多题目里一个用户可能对应多条记录，不加DISTINCT或者不按主键去重，结果就是错的。
- 概率题别忘记写公式。即使最后结果没算出来，把贝叶斯公式或假设检验的关键步骤写出来，都能拿到步骤分。
- 业务题别只写“原因分析”，还要写“验证方法”。面试官看的是你是否具备闭环思维，能不能把原因和动作用数据串起来。
7.3 备考资料的避坑
市面上的数据分析笔试资料质量参差不齐。我的经验是，优先刷三类：
- 牛客网的SQL题库，覆盖了大厂真题的常见题型，还有讨论区可以看其他人的写法。
- 《商务与经济统计》或《深入浅出统计学》，把假设检验、置信区间、回归部分吃透。
- 各公司往年的数据分析面经和笔试经验帖，重点看业务案例题的答题框架，这比背代码语法更有普适性。
我在准备期间也看到过很多号称“小红书笔试原题”的资料，说实话大多是机构归纳的模拟题，建议只用来练手，别当真。真正有价值的是在刷题中总结出属于自己的分析框架。
7.4 面试前的心态调整
笔试只是校招第一关，成绩好坏不完全代表能力，因为平台、题量、临场状态都会影响发挥。我当时考完感觉一般，但后来还是进入了面试。现在回想起来，笔试更多是筛掉“准备不足”的人，而不是筛掉“智商不够”的人。你只要系统刷过SQL和统计题，能够用框架回答业务问题，就没有太大问题。
8. 个人体会与后续建议
从我实际准备和参加那次笔试的经历来看，数据分析岗的校招笔试本质上不是在考技能，而是在考“你能否用数据语言解决业务问题”的思维习惯。SQL和统计是工具，业务案例才是你真正展示分析素养的地方。
最后分享一个小技巧：备考业务案例题时，不要只看面经，试着把每个场景做成一张A4纸的“分析预案”，包括指标定义、拆解维度、假设清单、验证方法和建议动作。这个习惯不仅帮我通过了笔试，在后续实习和全职工作中也一直在用，每次接到一个分析需求，我都会先按这个结构把问题拆清楚，再动手处理数据。希望这篇复盘能帮你少走一些弯路，顺利拿下笔试。
