2019小红书数据分析校招笔试复盘：SQL、业务思维与统计基本功-编程实验室

1. 一场笔试背后的筛选逻辑：2019年那批题到底想考什么

先说说我为什么到现在还在翻这份2019年小红书数据分析岗的笔试题。这几年帮学弟学妹做面试辅导，发现一个很有意思的现象：很多人刷了大量的SQL题、背了一堆机器学习公式，结果一遇到校招笔试还是发懵。原因很简单——校招笔试和社招笔试的考察逻辑完全不同，它不是在考你"会不会写某个函数"，而是在考你"有没有做数据分析的思维底子"。小红书2019年校园招聘数据分析岗位在线笔试第二批这套题，恰好是这种筛选逻辑的典型样本。

这套题当时面向的是应届生，岗位是数据分析，笔试形式是在线答题，分两批进行。第二批的题目整体给我的感觉是：不偏、不怪、不炫技，但非常吃基本功。它没有让你手推GBDT的公式，也没有让你从零写一个TF-IDF，而是把大量的分值压在三个维度上：SQL取数的熟练度、业务指标的理解深度、统计概率的直觉判断。这三个维度，恰好对应了数据分析师日常工作中最常打交道的三件事：从数据库里拿数据、把数据变成业务结论、判断结论是否靠谱。

如果你现在正准备校招笔试，或者已经在面试流程中但心里没底，这篇文章值得你花十分钟看完。我会把第二批这套题的结构拆开，逐个题型讲清楚考察意图，再给出具体的解题思路和答题模板，最后聊聊那些"笔试时感觉良好、出分却翻车"的隐藏失分点。这不仅仅是复盘一套过去的真题，更是一份可以直接套用的备考框架。

这里先给一个总结论：2019年小红书数据分析笔试二批的核心不是"难"，而是"全面"。它覆盖了SQL、业务分析、统计学、数据敏感度四个板块，每个板块的分值分配相对均匀，任何一个板块出现明显短板都很难通过。所以备考的关键不是押题，而是补短板。

2. 题型总览与分值分布：先知道战场长什么样

在拆具体题目之前，先把第二批这套题的整体框架拉出来。我当时做完的第一感觉是：题量不算大，但每一道题都需要认真思考，不存在"秒杀"题。整张卷子大概分为四个部分，下面我结合记忆和同类笔试的普遍情况做个还原。

题型板块	大致题量	考察核心	难度系数
数据分析基础概念	5-8题	指标理解、业务场景判断	中等偏易
SQL编程题	3-4题	取数逻辑、表关联、聚合计算	中等
统计学与概率	4-6题	假设检验、分布、AB实验	中等
业务案例分析	1-2大题	指标体系搭建、异动归因	较难

这个结构在当时的主流互联网公司校招笔试中属于标准配置，但注意几个细节。

第一，基础概念题占比不低。很多人备考时直接跳过概念题去刷SQL，这是策略性失误。概念题虽然单题分值不高，但胜在稳定，属于"送分题"。如果在这里丢分，后面的大题压力会非常大。我见过太多候选人SQL写得飞起，结果被"DAU和WAU的关系""留存率的正确计算方式"这类基础题绊倒。

第二，SQL题的考察方式是"场景化取数"，不是单纯的语法测试。它通常会给一个简化的业务数据表结构，然后让你写出满足某个业务需求的查询语句。这意味着你不仅要会写JOIN、GROUP BY，还要能读懂题目背后的业务含义，知道为什么要这样取数。

第三，业务案例题是真正的分水岭。这道大题没有标准答案，考察的是你的分析框架和表达能力。很多理工科背景的同学在这道题上栽跟头，不是因为不会分析，而是因为分析思路太"技术化"，没有站在业务方的角度思考问题。

下面我们逐个板块来拆解。

3. 数据分析基础题：你以为会做，其实一直在踩坑

先聊基础概念题。这批笔试的基础题主要集中在以下几个方向：指标定义、漏斗分析、留存计算、归因逻辑。这些概念听起来都耳熟能详，但题目的问法往往藏着陷阱。

举例来说，有一类经典问题："某App次日留存率下降了5个百分点，请分析可能的原因。"这看起来像个业务分析题，但实际上笔试时它可能以选择题的形式出现，给你四五个选项，让你选出"最不可能的原因"。很多人会直接选"竞品上线了同类功能"——因为大家本能地觉得竞品是万能的背锅侠。但正确答案往往不是这个，而是某个更隐蔽的逻辑漏洞，比如"统计口径发生了变化，将iOS用户单独拆出"或者"版本更新后强制登录才能浏览内容"。

这类题背后考察的是你的指标敏感度。指标波动时，第一步永远不是找外部原因，而是确认内部统计逻辑是否一致。我在实际工作中吃过这个亏。有一次DAU突然掉了3%，全组人分析了两天，最后发现是埋点代码在某个版本被误删了。那次之后我总结了一条铁律：任何指标异动，先查口径，再查数据质量，最后才谈业务原因。这个顺序应该在笔试时就已经刻在骨子里。

再来看留存率。留存率的基础计算公式大家都懂：第N日留存率 = 第N日仍活跃的用户数 / 首日新增用户数。但笔试时它会变着法子考察你对"用户数"的理解。比如："某日新增用户1000人，其中300人在次日有登录行为，但50人在次日凌晨被系统判定为异常用户并封禁，请问次日留存率是多少？"这里就涉及一个细节：被封禁的用户算不算在分母里？统计口径不同，答案完全不一样。

笔试时遇到这种题目，我的建议是不要急着算，先把口径写清楚。哪怕题目没有要求，你在草稿纸上写出"分母=当日新增总用户数，分子=次日有活跃行为的用户数（剔除封禁用户？）"，然后再根据题目的业务场景做判断。这样即使最终答案错了，阅卷时也能看到你的思考过程——虽然笔试是机器阅卷，但这个习惯能帮你避免计算出错。

第三个高频考点是漏斗分析。这里考察的不是漏斗怎么画，而是如何定位漏斗中的关键流失环节。题目通常给出一组转化数据：曝光→点击→加购→下单，每一步的转化率分别是多少，问你最应该优化哪一步。很多人一看转化率最低的环节就选它，比如加购到下单只有30%，就觉得这里流失最严重。但正确的分析逻辑是看绝对流失量和环节提升空间的乘积，而不是单看转化率。

举个例子：曝光100万，点击10万，加购5万，下单1万。点击率10%，点击到加购50%，加购到下单20%。如果只看转化率，加购到下单（20%）是最低的，应该优化这里。但如果你把加购率从50%提升到60%，下单会变成1.2万；而如果把点击到加购的转化率从50%提升到60%，下单也是1.2万。两者提升效果一样。但如果考虑优化难度——电商场景下加购到下单的流失通常和价格、运费、支付方式有关，优化空间有限；而点击到加购的流失可能和商品详情页质量有关，通过优化详情页提升点击到加购，难度更低，收益更确定。所以笔试中的"最优解"往往不是转化率最低的环节，而是提升空间和提升难度的综合权衡。

4. SQL场景化取数：笔试里最不该丢分的硬功夫

SQL是数据分析笔试的标配，小红书的这批题也不例外。和LeetCode那种纯算法SQL题不同，校招笔试的SQL题更接近实际工作场景——它给你几张表，让你完成一个业务取数需求。这里我想重点聊聊三道典型题目，它们基本覆盖了SQL笔试的核心考点。

4.1 多表关联与聚合的考察逻辑

第一类典型题是多表关联统计。比如题目给出用户表（user_id, reg_date, channel）、订单表（order_id, user_id, order_date, amount），让你统计"每个渠道的新用户在下单后7天内的复购率"。这题考察的不仅仅是JOIN语法，还有你对"7天内"这个时间窗口的处理逻辑。

我当时做题时总结了一个模板，适用于大部分"每个XX的YYY"类题目：

SELECT u.channel, COUNT(DISTINCT o.user_id) AS repurchase_users, COUNT(DISTINCT u.user_id) AS new_users, COUNT(DISTINCT o.user_id) / COUNT(DISTINCT u.user_id) AS repurchase_rate FROM users u LEFT JOIN orders o ON u.user_id = o.user_id AND o.order_date BETWEEN u.reg_date AND DATE_ADD(u.reg_date, INTERVAL 7 DAY) WHERE u.reg_date >= '2019-01-01' GROUP BY u.channel;

这里有两个关键点。第一，为什么用LEFT JOIN而不是INNER JOIN。如果用INNER JOIN，那么没有任何订单的用户会被直接过滤掉，复购率的计算中"未复购用户"这个分母就丢失了，得到的结果会虚高。很多人在这个细节上栽跟头——测试数据恰好所有用户都有订单时看不出问题，但换成线上真实数据就错了。第二，关联条件里的时间窗口过滤要写在ON子句而不是WHERE子句。写在WHERE里，LEFT JOIN就变成了INNER JOIN，逻辑直接错误。

提示：笔试SQL题中，看到"统计每个XXX的YYY率"，第一反应先问自己——用户表和数据表是什么关系？一的一方还是多的一方？需要保留没有行为的用户吗？想清楚再动手。

4.2 窗口函数的进阶用法

第二类典型题是窗口函数的应用。2019年那会儿窗口函数在校招笔试中已经不算冷门了，但很多人只会简单的ROW_NUMBER()，遇到复杂场景就抓瞎。

常见题目是："统计每个用户最近一笔订单的金额，以及该订单距离注册日期的天数。"这类题必须用窗口函数才能高效解决。我的写法是：

SELECT user_id, order_amount, DATEDIFF(order_date, reg_date) AS days_since_reg FROM ( SELECT o.user_id, o.order_amount, o.order_date, u.reg_date, ROW_NUMBER() OVER (PARTITION BY o.user_id ORDER BY o.order_date DESC) AS rn FROM orders o LEFT JOIN users u ON o.user_id = u.user_id ) t WHERE rn = 1;

思路是先用ROW_NUMBER()按用户分区、按下单时间倒序编号，取rn=1就是最近一笔订单。这类题还可能有变形，比如"取每个用户第二笔订单"（rn=2）、"取每个品类销量最高的商品"（RANK()）等。掌握一个核心逻辑——"分组TOP N"用窗口函数，不要用GROUP BY + LIMIT——就够应对80%的变体了。

4.3 留存计算的SQL实现

第三类必考题型是留存率计算。留存率的SQL实现有很多种写法，笔试时最容易出错的不是SQL语法，而是对"留存"口径的理解。一个标准写法如下：

SELECT DATE(u.reg_date) AS reg_date, COUNT(DISTINCT u.user_id) AS new_users, COUNT(DISTINCT CASE WHEN DATEDIFF(DATE(o.order_date), DATE(u.reg_date)) = 1 THEN u.user_id END) AS retained_users_day1, COUNT(DISTINCT CASE WHEN DATEDIFF(DATE(o.order_date), DATE(u.reg_date)) = 7 THEN u.user_id END) AS retained_users_day7 FROM users u LEFT JOIN orders o ON u.user_id = o.user_id WHERE u.reg_date >= '2019-01-01' GROUP BY DATE(u.reg_date);

注意几个细节。第一，活跃的定义。题目如果说"次日活跃"，那你应该去用户活跃表找登录行为，而不是订单表——除非题目明确说"次日下单"。用错表会让整个答案失去意义。第二，去重。用户一天可能下多单或登录多次，所以必须用COUNT(DISTINCT ...)。第三，时间的粒度。注册日期和活跃日期都是datetime还是date，如果混用，DATEDIFF的结果会差一个边界小时数。笔试环境里通常给的是date类型，但养成先确认类型的习惯永远不会错。

SQL部分除了语法正确，我特别想提醒一个点：读题时先画出表结构。哪怕题目已经给出了字段列表，也建议在草稿纸上快速写一下每张表的粒度（一行代表什么）。比如订单表的一行可能是一笔订单，也可能是一个订单中的一件商品（订单明细表），差别极大。搞错了粒度，后面的JOIN和COUNT逻辑全都会出错。

5. 统计与概率：数据人的内功心法部分

统计学在数据分析笔试中的比重是"不高但致命"。说它不高，是因为题量通常不会超过三分之一；说它致命，是因为一旦在统计题上失手，基本意味着与offer无缘——这块内容是可以通过短期复习拿满分的，丢分非常可惜。

5.1 假设检验的必考套路

假设检验是统计部分的绝对重点。笔试通常不会让你手算t统计量（那太偏数学系了），而是考察你对第一类错误和第二类错误的理解，以及如何根据业务场景选择检验方法。

一个经典选择题："在AB测试中，我们将显著性水平α从0.05调整为0.01，以下说法正确的是（）？A. 犯第一类错误的概率降低 B. 犯第二类错误的概率降低 C. 统计检验力提高 D. 样本量需求降低"。正确答案是A。但很多人因为对两类错误的关系不熟练，错选C或D。这里有个便于记忆的口诀：α降低，第一类错误降低，第二类错误升高，检验力降低，所需样本量增大。所有变化方向都是反着来的。

还有一个高频考点是p值怎么解释。很多人会写成"p值为0.03，说明原假设为真的概率是3%"——这是错的。正确解释是"在原假设为真的前提下，观察到当前样本或更极端样本的概率是3%"。笔试时可能会用一个判断题来考察这个区别。这个知识点非常基础，但恰恰是区分"背过统计"和"理解统计"的分水岭。

5.2 概率题的商业包装

概率题在校招笔试中往往会披上商业的外衣。比如："某社区内容平台，用户发布一篇笔记后，48小时内获得超过100个赞的概率为30%。假设该用户在周五晚上8点发布了一篇笔记，截至周六晚上8点获得了80个赞。请问该笔记在周日晚上8点前获得100个赞的概率是多少？请用贝叶斯定理说明思路。"

这类题的目的不是让你算出精确数值——实际上给的信息也无法直接算——而是考察你能否识别出这是一个贝叶斯更新问题。你需要在答题中明确写出：先验概率是30%；观察到"48小时时只获得80个赞"这个新证据后，需要根据这个证据修正先验；如果能知道"48小时获得80个赞"的条件概率分布，就能计算后验概率。即使不会算最终数字，把思路框架写清楚，就能拿到大部分分数。

这里想多说一句：概率题里的业务背景不是装饰，而是提示。比如"周五晚上8点发布"这个信息，暗示这个时间点的用户活跃度和内容消费特征不同于工作日，会影响点赞速率。答题时如果能点出"发布时段是重要协变量"，会让阅卷人眼前一亮——即使在机器阅卷的环境下，这份敏感度也会在其他环节体现出来。

5.3 常见分布与实际业务的对号入座

统计部分偶尔会考察常见分布的识别。比如"用户在一小时内到达某直播间的次数，最可能服从什么分布？"答案是泊松分布。这种题靠背就能得分，但我会建议你多想想"为什么"——泊松分布描述的是单位时间内随机事件的发生次数，要求事件独立且发生率恒定。直播间的用户到达虽然不是完全恒定（有开播冷启动、峰值效应），但作为近似是合理的。理解背后的假设，比单纯记住"计数数据用泊松"要靠谱得多。

6. 业务案例分析：没有标准答案的送命题，也是送分题

业务案例题是整个笔试中分值最大、最开放、也最能拉开差距的部分。小红书的这批笔试中，业务题给我的印象是：问题朴素，但考察的分析深度不朴素。我挑两个典型的问法来拆解。

6.1 "DAU下降5%，怎么分析"的完整回答结构

这道题几乎可以算数据分析面试的"国歌"了。小红书版本的问法大致是："某内容社区产品近一周DAU持续下降，降幅约5%，作为数据分析师，你会如何分析？请写出完整的分析思路。"

很多人看到这道题第一反应是"这题我都会，就是拆维度嘛"。但真正动笔时，要么只列了几个维度，要么直接跳到结论。我的建议是：用结构化的问题清单来组织回答。

第一步是定义问题。DAU下降5%是相对哪个基准？是环比上周还是同比去年？不同基准的解读完全不同。如果去年同期也呈现类似下降（比如春节因素），那可能只是季节性波动，不算真正异动。

第二步是校验数据。确认统计口径没有变化、埋点没有缺失、数据仓库有没有延迟。这一步的权重甚至应该高于业务归因——我前面也说过，很多"异动"最后查出来都是数据问题。

第三步是维度拆解。"DAU = 新用户 + 老用户回流 + 老用户持续活跃"，分别看这三大块的贡献。然后再往下拆：新用户看渠道、看获客成本；老用户看留存曲线、看访问频次、看内容消费时长。平台侧看内容供给是否充足、推荐算法是否有变动、是否有重大舆情事件。

第四步是提出假设并验证。比如"推荐算法调整导致新用户首刷体验变差"，那么应该去对比调整前后的新用户次留数据；"某个大V停止更新导致内容供给下降"，那么应该去看头部内容生产者的活跃度数据。

第五步是输出结论和行动建议。这一步很多人忽略，但它恰恰是数据分析师和"取数机器"的区别。分析完了不能只说"DAU下降了是因为老用户流失"，还得给出"建议召回策略""建议调整推送频次"这样的可落地方案。

我见过一个不错的答题框架，分享出来供你参考：

我将按照"口径确认→维度拆解→假设验证→落地建议"四个步骤进行分析。先确认统计口径和数据质量，再按新老用户和大盘维度拆解下降来源，然后针对贡献最大的下降部分分别提出业务假设并用数据验证，最后输出可执行的建议。

这个框架好在先确认口径、再拆维度、最后才谈归因，逻辑链条完整，面试官一眼就能看出你是有实战经验思路的，而不是背了一堆结论。

6.2 指标体系的搭建思路

业务题还有一种问法是"为一个新功能设计核心指标"。比如小红书的内容平台，如果要上线一个新的"合集"功能，你会关注哪些指标？

这类题没有标准答案，但有一个通用的思考框架：从用户行为链路出发，拆出感知、使用、沉淀、传播四个环节。感知环节看功能曝光量和点击率；使用环节看创建合集的用户数、人均创建数量、合集内笔记的添加率；沉淀环节看合集页的访问深度、回访率；传播环节看合集被分享的次数、带来的新用户转化。再往上，还要挂钩业务价值——合集是否提升了用户的长期留存量、是否带动了笔记发布频次。

写这类题时，记住一个原则：指标要成体系，而不是罗列。不要把所有想到的指标全列上去，那会让阅卷人觉得你缺乏优先级判断。更好的做法是分主次指标：一个北极星指标（比如"每周创建合集用户数"）+ 三个过程指标 + 两个防风险指标（比如"合集功能是否挤压了普通笔记的发布"）。这样既体现了全局观，又体现了取舍能力。

7. 笔试中的隐藏失分点：为什么你感觉答得不错，分却不理想

最后聊聊一个很扎心的话题——笔试复盘时觉得自己答得还行，为什么不通过？结合我自己的经验和带人辅导时的观察，校招笔试的失分点往往藏在下面几个不起眼的地方。

失分点一：只看结果不看过程。这在SQL题里特别明显。很多人写出的SQL能跑出结果，但写法非常粗暴——比如用子查询嵌套了七八层，或者一个字段反复计算多次。笔试虽然不像面试那样会现场追问优化思路，但如果有主观评分环节，可读性和规范性的价值就会体现出来。养成用WITH语句拆解复杂逻辑、给关键计算加注释的习惯，是值得的。

失分点二：业务题答成了数据分析报告。有些同学业务题写得洋洋洒洒，从宏观环境讲到竞品分析，篇幅很大但信息量很低。业务题考察的是分析框架与可执行建议，不是叙事能力。建议只用总分结构，先说核心结论，再说推导过程，最后给行动项。写太多冗余内容反而稀释了重点。

失分点三：统计题只看数字不解释业务含义。比如算出了p值，却不说明"这个差异在业务上是否重要"。显著性不等于业务显著性——样本量足够大时，0.1%的差异也能显著，但对业务毫无意义。答题时最好在统计结论后补一句业务解读，这会体现出你是"用统计做决策"的人，而不是"会算统计题"的人。

失分点四：时间分配严重失衡。这套题的二批卷子整体难度中上，如果在一道SQL题上卡了20分钟，后面的业务大题大概率会写得很仓促。我的建议是：先扫一遍全卷，把概念题和简单的SQL题快速做完，把业务大题留足20-25分钟，最后再啃硬骨头。数据分析笔试的本质是"在有限时间内展示你的稳定输出能力"，而不是"证明你能解出最难的题"。

失分点五：忽略审题中埋的"口径时间线"。校招笔试题里经常出现类似"近7日""次月""自然周"这样的时间范围限定。很多人做题时默认按自然周计算，结果题目要求的是滚动7天。笔试没有机会提问，所以读题时用笔圈出所有时间词、主体词、排除词，宁可多花30秒审题，也不要写到最后发现跑题。