小红书数据分析笔试题解析：SQL、统计与业务思维全攻略

小红书2020校招数据分析笔试题，这块内容我前前后后带过不少应届生复盘，也亲眼见过有人靠着一套系统的准备拿到offer，也有人连基础SQL都写不顺就冲上去裸考，结果自然不太好看。今天我就把这份笔试题背后考察的东西掰开揉碎讲一遍，同时把数据分析岗位校招笔试常见的套路、知识点和踩坑点整理出来，希望对正在准备校招、或者想转行做数据分析的朋友有实际帮助。

这套笔试题虽然名字带“小红书”，但它并不是只适用于小红书一家。互联网公司的数据分析笔试，尤其是校招层级，核心考察方向高度相似：SQL能力、统计学基础、业务分析思路、数据敏感度。你把小红书这套题吃透了，再去面其他大厂的数据分析岗位，至少能避开80%的常见坑。

1. 小红书2020校招数据分析笔试题整体拆解

1.1 轮次设置与考察范围

先把这套题放在当年的校招流程里看。小红书数据分析岗的校招一般分简历筛选、笔试、业务面、HR面几个环节，笔试是简历通过后的第一道硬门槛。2020年那会儿，笔试基本线上完成，题型以选择题、SQL题、简答/分析题为主，整体时间在60到90分钟之间，题量不小，节奏很快。

从考察范围来看，这套笔试题覆盖了三个核心模块：

• SQL与数据处理：主要考察取数能力，比如表的连接、聚合、窗口函数、去重、空值处理。
• 统计与概率基础：均值、中位数、方差、假设检验、概率计算，这部分是判断候选人有没有基本的数据sense。
• 业务分析题：给你一个业务场景，比如笔记曝光下降、用户留存变差、某类目GMV波动，让你拆解原因、给出分析框架、提出解决方案。

有些版本还包含Excel题或者Python题，但2020年这个节点，小红书对Python的要求还没那么高，重点还是SQL和业务分析思路。

1.2 为什么这套题值得反复研究

我见过很多人刷题只刷力扣SQL，或者只刷统计学教材，实际上笔试挂掉往往不是因为某一项能力缺失，而是因为“不知道对方在考什么”。

小红书这套题最大的特点是：它不考死记硬背的概念，而是把数据和业务绑在一起考。比如给你一个“用户发布笔记后7日留存”的数据表，让你写出计算逻辑；再比如告诉你“某天推荐流量占比突然下降”，让你分析可能原因。这些问题没有标准答案，但能明显区分出你是“只会写SQL的工具人”，还是“能通过数据理解业务的分析师”。

另外，这套题也代表了当时互联网公司对校招数据分析师的定位：不需要你有非常深的算法功底，但你必须能把一个模糊的“业务问题”转化为“数据问题”，再用“SQL/统计工具”去解决，最后把结果用“业务语言”讲清楚。这四个环节，笔试里全部覆盖。

注意：准备小红书或其他大厂数据分析笔试时，不要只刷题不思考。公司想看到的不是一个“数据库查询员”，而是一个能站在业务角度用数据说话的人。

2. 核心题型精讲：SQL、统计与业务分析

2.1 SQL题：从取数到窗口函数的进阶考察

SQL题在校招数据分析笔试中占比最高，小红书2020这套题也不例外。选择题会考一些基础语法，大题则直接给你一个业务数据表，让你写出查询语句。

常见考察点包括：

• 多表连接：内连接、左连接的区别，什么时候用left join而不是join。
• 聚合函数与group by：按用户、按日期、按品类分组统计。
• 去重计数：count(distinct user_id)的使用。
• 窗口函数：row_number()、rank()、dense_rank()的区别，以及sum() over(partition by)这类累计计算。
• 子查询与临时表：如何通过嵌套查询实现多步计算。
• 日期函数：日期间隔计算、按周/月聚合。

举个例子，有一道经典题目是：“统计每个用户首次发布笔记的时间，并计算从注册到首次发布的天数。”这道题看着简单，但很多人会卡在“取每个用户首次发布笔记时间”这一步，下意识想用group by，却不知道该用什么函数把对应的发布时间带出来。

正确的做法有两种：

-- 方法一：min() + group by 后 join select a.user_id, a.first_publish_time, datediff(a.first_publish_time, b.register_time) as diff_days from ( select user_id, min(publish_time) as first_publish_time from publish_log group by user_id ) a left join user_info b on a.user_id = b.user_id;

-- 方法二：窗口函数 row_number() select user_id, publish_time, datediff(publish_time, register_time) as diff_days from ( select p.user_id, p.publish_time, u.register_time, row_number() over(partition by p.user_id order by p.publish_time asc) as rn from publish_log p left join user_info u on p.user_id = u.user_id ) t where rn = 1;

方法一逻辑直观，方法二更简洁，还能顺便处理“同一用户同一天发布多条笔记”时的排序问题。笔试时推荐用窗口函数，因为代码更紧凑，而且在面试环节，面试官通常更欣赏你对窗口函数的熟练度。

实际操作中还会遇到一个坑：日期字段的格式不统一，有的存成字符串"2020-01-01"，有的存成时间戳，做datediff之前必须先格式化。线上数据表经常有这种脏数据，笔试虽然不会故意整你，但养成先检查字段格式的习惯没有坏处。

如果笔试环境允许使用Python，也可以用pandas处理：

import pandas as pd publish_log = pd.read_csv('publish_log.csv') user_info = pd.read_csv('user_info.csv') first_publish = publish_log.groupby('user_id')['publish_time'].min().reset_index() first_publish.columns = ['user_id', 'first_publish_time'] result = first_publish.merge(user_info, on='user_id', how='left') result['diff_days'] = (pd.to_datetime(result['first_publish_time']) - pd.to_datetime(result['register_time'])).dt.days

有些公司笔试平台支持jupyter环境，能用pandas就尽量用pandas，既快又不容易出错，但前提是你对pandas的groupby和merge足够熟悉。

2.2 业务分析题：从数据波动到归因拆解

另一类必考题型是业务分析题，也就是给你一个业务现象，让你分析原因。小红书2020笔试里，这类题通常放在简答题最后，分值很高，也是最容易拉开差距的部分。

举一个常见题干：“某天发现社区笔记的日均曝光量下降了10%，请分析可能的原因，并给出你的分析思路。”

很多应届生看到这种题第一反应是：“可能是算法策略改了，导致流量分配变化。”这个回答不是不对，而是太笼统，缺乏结构化思维。

正确的打开方式应该分四步走：

1. 确认数据的真实性：先排除数据口径问题，比如是否因为埋点缺失、报表bug、流量日志丢失导致数据“假下降”。这一步很多人会忽略，但实际工作中，10%的波动真有可能是数据问题。
2. 维度拆解：把曝光量按渠道、用户类型、内容类型、设备端、时间维度进行拆解，找到是哪个维度导致的整体下降。
3. 内外部因素分析：内部看产品改版、算法策略调整、推荐位变动、活动结束等；外部看竞品动态、节假日效应、舆情事件等。
4. 提出验证方案：比如拉取分维度数据验证假设，或者做AB实验验证策略影响。

回答的时候，最好结合具体的数据公式来拆。比如曝光量可以拆成：

曝光量 = 活跃用户数 × 人均浏览笔记数 × 人均产生曝光次数

如果曝光下降10%，先看是哪个因子变了：是DAU降了，还是人均刷的笔记数降了，还是每次浏览产生的曝光变少了。不同因子的变化对应完全不同的排查方向，这种“先分拆、再定位”的思路，是面试官最想看到的。

这个公式拆解法，在数据分析工作中几乎每天都在用。无论是GMV、订单量、留存率，只要遇到指标波动，第一件事就是构建指标公式，然后逐层拆解。这也是商业数据分析的核心思维之一。

2.3 统计与概率：容易被忽视的送分题和失分题

统计与概率题在校招笔试里一般占比在20%到30%，难度不算高，但很琐碎，容易因为粗心丢分。

常见考点包括：

• 描述统计：均值、中位数、众数、方差、标准差，以及它们对异常值的敏感度。
• 概率计算：条件概率、贝叶斯公式、排列组合求概率。
• 分布：正态分布、二项分布、泊松分布的基本性质和应用场景。
• 假设检验：p值含义、第一类错误与第二类错误、置信区间。
• AB实验：实验分组、显著性判断、样本量计算。

有一道很经典的送分题：“一组数据中有三个数：2，4，100，请问中位数和均值分别是多少？哪个更能代表数据中心？”均值是35.33，中位数是4，显然中位数更能代表这组数据的典型水平，因为100是明显的异常值。

这类题本身不难，但很多人对“p值”的理解是模糊的。比如问“p值小于0.05意味着什么？”正确答案是“在原假设为真的前提下，观察到当前样本或更极端样本的概率小于5%”，而不是“原假设为假的概率小于5%”。这两个表述有本质区别，面试官常借此考察候选人有没有真正理解假设检验的逻辑。

再补充一个跟小红书场景相关的例子：如果平台要把一个新推荐算法上线，先做小流量实验，实验组和对照组各覆盖10万用户，观察点击率是否有显著提升。这里就需要知道样本量估算的基本思路，至少要理解“样本量越大，越容易检测出微小差异”这个直觉。

3. 实操复盘：一道完整笔试的解答过程

3.1 经典题目复现与分步解答

下面我从2020年流传出来的题目版本里选一道有代表性的题，完整走一遍解答过程。题目大意是：

有用户表user_info(user_id, register_date, city)和内容发布表publish_log(pid, user_id, publish_date, tag)。请计算2020年1月每天新增用户的次日留存率。

这个题考察的是留存计算，几乎是所有互联网数据分析笔试的必考题。即使不是小红书，你在其他家也可能遇到类似的问题，所以务必吃透。

我一般建议分三步解答：

第一步，先理解“次日留存率”的定义：某日新增用户中，第二天下单（这里就是发布内容、登录，根据业务定义）的占比。

第二步，拆解SQL逻辑：

• 先找到2020年1月每天新增的用户；
• 再找到这些用户在注册日第二天是否有活跃行为；
• 最后用次日活跃人数除以当日新增用户数，得到留存率。

第三步，写SQL：

select a.register_date, count(distinct a.user_id) as new_users, count(distinct b.user_id) as retained_users, count(distinct b.user_id) / count(distinct a.user_id) as next_day_retention_rate from ( select user_id, register_date from user_info where register_date between '2020-01-01' and '2020-01-31' ) a left join ( select distinct user_id, publish_date from publish_log where publish_date between '2020-01-01' and '2020-02-01' ) b on a.user_id = b.user_id and b.publish_date = date_add(a.register_date, interval 1 day) group by a.register_date;

这段SQL里有两个关键点：一是用left join而不是join，否则活跃用户没记录时会直接丢掉新增用户，新用户数会被少算；二是活跃行为表里要先做distinct，防止一个用户当天发布多条笔记导致重复计数。

如果你使用的平台支持CTE，写成下面这种结构可读性更好：

with new_users as ( select user_id, register_date from user_info where register_date between '2020-01-01' and '2020-01-31' ), active_users as ( select distinct user_id, publish_date from publish_log where publish_date between '2020-01-01' and '2020-02-01' ) select n.register_date, count(distinct n.user_id) as new_users, count(distinct a.user_id) as retained_users, count(distinct a.user_id) / count(distinct n.user_id) as next_day_retention_rate from new_users n left join active_users a on n.user_id = a.user_id and a.publish_date = date_add(n.register_date, interval 1 day) group by n.register_date;

笔试现场不一定支持CTE，但多数在线编译环境（如Hive、MySQL 8.0以上）都能跑。如果平台只支持旧版MySQL，就用子查询的写法，别在关键时刻冒险。

3.2 笔试时间分配与答题顺序

小红书这套笔试题的时间压力不小。我建议的分配方法是：

• 前5分钟：快速浏览全部题目，判断哪些题有把握、哪些题比较陌生。
• SQL大题：优先做，因为每道分值最高，且一旦写出来了基本能拿满分。每道SQL控制在15到20分钟内。
• 业务分析题：其次做，这类题没有标准答案，只要逻辑清晰、表达完整，得分空间很大。
• 统计选择题：最后做，虽然知识点碎，但每题分值低，即使时间紧张也可以用直觉猜一猜。

做题顺序为什么这么安排？因为笔试过程中，人越往后写越疲惫，而SQL题需要高度集中。把最强状态留给分值最高的题，是性价比最高的策略。我当年自己参加笔试，也栽过“先做简单题结果SQL没时间写”的跟头，后来每次都是先扫全卷再排序，整体命中率高很多。

另外要特别注意：有些在线笔试题会限制每道题单独计时，SQL题过了时间就交卷，不能回看。这种情况下必须看准倒计时，不要在一道题上死磕到最后一分钟。

3.3 常见错误与排查技巧

我总结过候选人做这套题时最常犯的几类错误，供大家避坑：

还有一个容易被忽略的小坑：笔试环境里的SQL可能是Hive SQL，不是MySQL。Hive中的date_add语法没问题，但字符串日期需要用cast转成日期类型，或者直接使用date_sub、datediff等函数时注意格式。如果编辑器支持本地调试，先跑一小段数据验证再交卷，真的能省掉很多低级错误。

4. 从笔试到工作：数据清洗、可视化与数据分析思维

4.1 数据清洗与准备：笔试不考却是工作日常

笔试考的是SQL和逻辑，但真正入职之后，你第一个星期大概率在跟数据质量作斗争。小红书这类内容平台，数据埋点体系庞大，客户端、服务端日志格式经常不一致，同一个“曝光事件”在不同端上可能叫不同的名字，甚至同一个字段在不同时期的数据类型都不同。

所以我要特别提醒准备校招的朋友：不要只盯着笔试题，也要具备基本的数据清洗思路。比如拿到一个原始日志表，第一步不是急着分析，而是先看数据是否有重复、空值分布在哪些字段、异常值是否在合理范围。用Python做分析的话，pandas里的drop_duplicates()、isnull()、describe()，以及Excel里的“删除重复项”“条件格式”，都是最基础的工具。

我用小红书场景举个例子：你想分析“京沪两地用户发布笔记的互动量差异”，但原始数据里city字段有些是“北京/上海”，有些是“beijing/shanghai”，还有些直接是空值。如果不做清洗和标准化，后面分析结果根本没有可信度。数据分析领域有一句话叫“garbage in, garbage out”，数据没洗干净，模型和结论再漂亮也是白搭。

4.2 数据可视化：从Excel到专业BI工具

笔试题很少直接考可视化，但在业务面或者实习工作里，图表表达能力非常加分。我见过不少候选人口头分析头头是道，一到画图就只会用Excel画个饼图，这其实是不够的。

Excel当然是最基础的，透视表、vlookup、条件格式、基本的折线图和柱状图，这些是必备技能。如果你能熟练掌握以下这些工具中的任意一两个，会给面试加分不少：

• Excel：快速出临时报表，尤其是数据量不大（百万元组以内）时最灵活。
• Python可视化库：matplotlib、seaborn、plotly，适合做探索性分析和需要自定义样式的图表。
• BI工具：Tableau、Power BI、Metabase，适合搭建固定报表。小红书内部数据分析师日常会用自研或开源的BI平台，但底层技能是相通的。
• DBeaver：如果你做SQL查询和数据探索，DBeaver这类数据库客户端非常方便，可以直接看表结构、跑查询结果，甚至支持简单的图表可视化。很多面试官如果看到你的简历里写了熟悉通用数据库工具，会默认你是能直接上手的候选人。

可视化的核心不是“画得好看”，而是用最合适的图表把业务问题讲清楚。时间趋势用折线图，对比构成用柱状图/堆叠图，占比用饼图（但要慎用，分类多时饼图很难读）；地理分布用地图；相关性分析用散点图。这些基本的图表选择逻辑，笔试不考，但面试项目介绍时很可能会被追问。

4.3 数据分析思维：从取数员到业务伙伴

小红书2020这套笔试题里最值钱的不是那些SQL题，而是业务分析题背后的思维方式。如果你能想明白那几道业务题的解答逻辑，你就已经超过了大多数只会写SQL的候选人。

数据分析思维里，最重要的三条：

第一，目标导向。接到一个分析需求，先搞清楚老板或业务方到底想解决什么问题，这个问题的成功标准是什么。很多时候业务方给的需求是“帮我看看数据”，但实际上他想知道的是“为什么不涨了”或“下一步该做哪个方向”。澄清需求本身就是一个很重要的能力。

第二，假设驱动。不要一上来就统计全量数据。先基于对业务的理解提出几个可能假设，再有针对性地取数验证。比如笔记曝光下降，先假设是不是推荐策略变了，再看是不是内容供给不足，最后看是不是竞品分流。每个假设对应一个数据验证方案，整个分析过程会高效很多。

第三，量化表达。不要只说“涨了很多”“用户流失严重”，要量化成“环比上涨12%”“次周留存率从38%下降到30%”。同一件事，量化与否，给决策者的感觉完全不一样。

5. 准备建议与学习路线

5.1 校招准备时间规划

如果你还有两到四个月准备校招，我建议按下面的节奏来：

• 第一个月：重点突击SQL。把所有常见的SQL写法过一遍，包括join、group by、子查询、窗口函数、日期处理。每天至少写3到5道SQL题，题库可以刷LeetCode数据库板块、牛客SQL实战，以及各个公司的历年笔试题。这个阶段不追求难题，只求基础语法熟练。
• 第二个月：重点补充统计学和业务分析框架。统计学不需要啃大部头，把概率论基础、假设检验、AB实验这些核心知识点弄明白即可。业务分析部分多看看行业分析案例，比如“某App留存率下降原因分析”“某品类GMV增长拆解”，学着用指标拆解的方法写分析报告。
• 第三个月及以后：反复刷历年真题，同时准备自己的项目案例。项目不在多，一两个能讲清楚的数据分析项目就够，重点是要能回答“你为什么要分析这个问题”“用了什么方法”“结论是什么”“业务方采纳之后效果如何”这一整套问题链。

5.2 刷题工具与环境准备

笔试题有的平台支持在线执行SQL，有的不支持，只让你在文本框里写。不管哪种，都要提前熟悉以下环境：

• 牛客网：有大量公司历年笔试题和面经，适合专项刷题。
• LeetCode Database：SQL题难度梯度清晰，用来练窗口函数很合适。
• Hive/MySQL本地环境：如果电脑配置允许，装一个MySQL或者用Docker起一个Hive环境，自己建表造数练习，效果比光看不练好太多。
• Excel + Python：Excel练透视表和函数，Python练pandas和seaborn，两个工具配合使用，处理日常分析场景完全够用。

另外，如果看到笔试题里描述了一个你完全不懂的业务概念，比如“北极星指标”“AARRR模型”“漏斗分析”，先不要慌，把题目里给的数据和条件吃透，用最基本的比率、趋势、对比来回答，往往也能答对一半以上。业务概念可以快速补充，数据逻辑则是硬功夫。

5.3 一些容易踩的面试坑

笔试只是第一关，后面还有面试。我见过不少笔试成绩不错的人挂在面试上，原因不是技术不行，而是表达方式和思维习惯出了问题。

第一个坑：只会给结论，不给推导过程。面试官问“你觉得留存率下降可能是什么原因”，你直接回答“产品体验变差了”，等于没说。你应该说：“我首先会计算不同维度的留存率，比如新老用户、不同版本、不同渠道，先定位下降主要是哪个人群带来的，然后再结合产品迭代时间点分析。”先给分析框架，再给具体假设，最后给验证方法，这套表达方式在任何业务面试里都好用。

第二个坑：不懂装懂。数据分析面试覆盖面很广，遇到不会的问题很正常。与其硬编一个答案，不如坦白说“这块我之前接触不多，我的理解是……如果有不对的地方希望能得到指点”。比起一个会胡编的候选人，面试官更欣赏真诚和学习意愿强的候选人。

第三个坑：忽略业务场景。很多候选人喜欢把SQL技术、算法模型挂在嘴边，但一到“这个分析对业务有什么价值”就讲不清楚。数据分析岗位终究是服务于业务的，不能落地到业务动作的分析，在公司眼里价值有限。

6. 写在最后的一些经验

小红书2020校招数据分析笔试题，本质上是一面镜子，照出你对数据基本功的掌握程度，也照出你的业务思维和问题拆解能力。我在带人的时候经常说，笔试不是“考试”，更像一次“模拟实战”，只不过把平时工作中的取数、分析和汇报压缩到90分钟里。

如果你正在准备校招，我建议不要抱着“刷完题就万事大吉”的心态。笔试题会变，但底层能力不会变：SQL写得干净利落，统计概念能讲清楚，面对一个模糊的业务问题时能迅速拆解成数据问题，这三件事做到位，你基本能轻松应对大多数互联网公司的数据分析校招笔试。

最后再分享一个小技巧：每次做完一套笔试题，无论结果是过了还是挂了，都要留出半小时复盘。把错题归类，统计一下自己是因为SQL语法不熟扣分、统计概念混淆扣分，还是业务分析结构不完整扣分。这个复盘动作比多刷十道题还有用。我自己当年就是这样，一边刷小红书这类真题，一边给自己做错误归因，到后面几家公司笔试时，基本上看一眼题目就能判断出对方想考什么。机会是留给有准备的人的，希望你能在笔试这一关走得稳一点。