直接开工。这阵子身边好几个朋友在准备数据方向的校招翻来覆去问我同一个问题小红书这种内容平台的笔试题到底怎么准备刚好我手里有一份小红书2020校招数据分析笔试题卷二当时做完之后整理过一版复盘今天把它重新打磨一下发出来给正在准备校招或者社招跳槽的朋友一个参考。这套题覆盖了SQL、概率统计、业务分析和Python整体难度中等偏上但对业务理解的要求比较高。如果你正在刷题准备面试或者刚入行想了解大厂数据分析师都在考什么、用什么思路解题那这篇文章值得看完。先说一下我对这份卷子的整体印象。小红书是内容社区产品核心业务围绕笔记、用户、互动、电商这几个板块展开所以笔试题里天然会带很强的业务场景色彩。卷二这个难度和卷一相比SQL占比差不多但业务分析题篇幅更大更看重候选人能不能从数据里推出可落地的运营建议——这和后面面试轮次的考察点一脉相承。换句话说笔试题不是单纯考你会不会写代码而是考你有没有分析问题的框架感。1. 试卷整体设计与考察逻辑拆解1.1 题型分布与考察能力矩阵先上结论整套卷子虽然是2020年的但现在回看它的出题思路和当前主流数据分析笔试高度一致——基础代码功底占总分的45%左右统计概率占20%业务分析与AB实验占20%剩下15%是综合性案例分析。这种配比决定了备考策略SQL必须扎实统计概念必须清晰业务场景题不能死记硬背框架要能结合业务逻辑现场推导。我当时把卷子里的题目按能力项重新归类了一下大概是这样考察模块占比典型题型核心能力SQL取数与表处理40%-45%留存计算、活跃用户统计、订单明细分析窗口函数、多表关联、去重逻辑概率与统计20%期望计算、置信区间、假设检验概率论基础、分布理解业务指标体系15%指标口径定义、指标异动原因分析指标体系思维、业务理解AB实验与因果推断15%-20%实验设计评估、结果显著性判断实验原理、常见陷阱识别Python数据处理少量DataFrame操作、简单数据清洗pandas基础这个分布其实透露了一个重要信息笔试阶段不太考算法题和机器学习模型推导那些是面试轮次的重点。笔试更关注“你拿到一堆业务数据能不能快速准确地算明白”。这和大厂数据分析师日常工作的核心是匹配的——先保证数据能取对、算对再谈分析深度。1.2 为什么业务分析题是卷面的重头戏卷二和卷一的最大区别就是把部分SQL题从纯代码技能题升级成了“代码业务判断”的复合题。比如让你统计不同来源渠道的用户次日留存率结果出来后还要判断哪个渠道质量更好、应该对哪个渠道加大投入。这种题考的不仅仅是你会不会写SQL而是你能不能把一张留存率表格翻译成业务行动。这种出题逻辑背后反映的是小红书这类内容平台数据分析团队的真实工作方式。日常业务方问的最多的问题就是“最近数据怎么跌了”“这个功能上线后效果咋样”“下个月目标是XX现在这个趋势能不能达成”——所有这些问题都要求分析师既能写复杂SQL取数又能结合业务逻辑给出解读。笔试题就是为了提前筛选具备这种复合能力的人。1.3 备考优先级排序建议如果你现在才开始准备笔试时间有限的情况下我建议按这个优先级来SQL窗口函数和复杂查询排第一因为这个分值最高而且可以通过短时间刷题快速提升概率统计里重点复习期望计算、条件概率、正态分布和置信区间AB实验部分搞清楚原理和常见误区不需要会手动推导样本量公式但要能看懂实验结论并指出坑。我当时用的备考方式是“以题带练”。每做完一道题不是对完答案就完事而是把这个题背后的知识点重新整理一遍比如遇到留存率计算的SQL题就把各种留存口径自然日留存、自然周留存、滑动窗口留存全部写一遍遇到置信区间题就把正态分布、t分布、Z检验和t检验的适用场景全部默写一遍。这套方法让我在笔试前把所有核心考点都过了一到两遍考场上看到题目基本不会慌。2. 核心考点解析SQL题目的高分解法2.1 留存率计算从基础写法到窗口函数优化留存率是内容平台笔试的必考题卷二里也不例外。题目大概是这种形式有一张用户登录表包含uid和login_date两个字段要求计算某段时间内新用户的次日、7日、30日留存率。基础做法是用自关联。先找出目标时间范围内的新增用户表再把这些用户和登录表关联判断每个用户在第N天有没有回来登录-- 新用户定义每个uid首次登录日期 WITH new_users AS ( SELECT uid, MIN(login_date) AS first_date FROM user_login GROUP BY uid HAVING MIN(login_date) 2020-01-01 AND MIN(login_date) 2020-02-01 ) -- 次日留存 SELECT COUNT(DISTINCT a.uid) AS new_user_cnt, COUNT(DISTINCT b.uid) AS retention_cnt, COUNT(DISTINCT b.uid) / COUNT(DISTINCT a.uid) AS next_day_retention_rate FROM new_users a LEFT JOIN user_login b ON a.uid b.uid AND b.login_date DATE_ADD(a.first_date, INTERVAL 1 DAY);这个写法能跑通但如果你想展示更进阶的能力可以用窗口函数让整个逻辑更清晰、扩展性更好WITH user_first AS ( SELECT uid, login_date, ROW_NUMBER() OVER(PARTITION BY uid ORDER BY login_date) AS rn FROM user_login ), base AS ( SELECT uid, login_date AS first_date FROM user_first WHERE rn 1 ), retention_calc AS ( SELECT a.first_date, COUNT(DISTINCT a.uid) AS new_users, COUNT(DISTINCT CASE WHEN b.login_date IS NOT NULL THEN a.uid END) AS retained_users FROM base a LEFT JOIN user_login b ON a.uid b.uid AND b.login_date BETWEEN DATE_ADD(a.first_date, INTERVAL 1 DAY) AND DATE_ADD(a.first_date, INTERVAL 1 DAY) GROUP BY a.first_date ) SELECT first_date, new_users, retained_users, retained_users / new_users AS retention_rate FROM retention_calc;这里有个小心机用DATE_ADD而不是直接判断DATEDIFF(b.login_date, a.first_date) 1。原因在于DATE_ADD写法在字段上有索引时更利于数据库优化器走索引扫描量小很多。笔试虽然不要求你写执行计划分析但这是个能体现工程素养的细节。注意笔试里的 SQL 环境大多只要求逻辑正确和数据准确不追求绝对最优性能。但千万不要用DATEDIFF(b.login_date, a.first_date) 1这种写法因为它在login_date字段上做了计算会导致索引失效数据量一大就会慢得离谱。职场上这种写法被数据研发看到大概率会被打回重写。2.2 活跃用户统计如何正确处理去重和跨表关联另一类高频SQL题是统计活跃用户这类题目出题人最爱在“去重”和“时间窗口”两个地方埋坑。比如给定用户行为记录表统计每周活跃用户数周活跃用户WAU、每月活跃用户数月活跃用户MAU以及连续活跃的用户。周活跃统计最经典的坑是“跨周问题”。如果直接按WEEK(login_date)分组周一和周日的数据会被分到同一周没问题但周日23:59产生的活跃和下周一的活跃可能被错误地归入不同周导致周活计算口径不一致。更合理的做法是先把login_date归一到周起始日再计数SELECT DATE_SUB(login_date, INTERVAL WEEKDAY(login_date) DAY) AS week_start, COUNT(DISTINCT uid) AS wau FROM user_behavior WHERE login_date BETWEEN 2020-01-01 AND 2020-03-31 GROUP BY DATE_SUB(login_date, INTERVAL WEEKDAY(login_date) DAY) ORDER BY week_start;WEEKDAY()函数返回周几0是周一6是周日用当前日期减去这个天数就得到了该周周一然后再按周一聚合无论数据落在哪一天都能分到正确的周。这个处理方式我面试的时候也经常拿来考别人十个人里有六七个第一次都会踩到跨周分组的坑。连续活跃用户是另一个常考类型。统计连续登录3天以上的用户核心思路是用login_date减去按用户分组后的行号得到一个分组标识再按用户和分组标识聚合WITH t AS ( SELECT uid, login_date, ROW_NUMBER() OVER(PARTITION BY uid ORDER BY login_date) AS row_num, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER(PARTITION BY uid ORDER BY login_date) DAY) AS diff_date FROM user_login ) SELECT uid, COUNT(DISTINCT login_date) AS consecutive_days FROM t GROUP BY uid, diff_date HAVING COUNT(DISTINCT login_date) 3;这个解题思路的原理很巧妙如果一个用户连续N天登录那么登录日期减去行号得到的结果是一样的。比如用户1号、2号、3号登录行号分别是1、2、3减去后得到的diff_date分别是0号、0号、0号——同一个值。中间如果断了一天diff_date就会往后跳一天用户就会被分到两个组里。把login_date转成日期格式后做减法如果中间有间隔diff_date就会变化。2.3 订单与内容付费多表join的数据口径小红书的业务场景里还有一块是内容付费和电商笔试里可能会有一个订单表和一个商品表要求统计各品类的销售额、订单量、客单价等指标。这题的精髓不在于join本身而在于你用什么字段join——是inner join还是left join。我见过很多人在这个题上翻车用 inner join 把订单表和商品表关联后发现订单量少了很多因为有一部分订单的商品ID在商品表里不存在比如商品已下架被清理。这时候应该用 left join 保留所有订单数据商品信息缺失的用默认值填充SELECT COALESCE(p.category, 未知) AS category, COUNT(DISTINCT o.order_id) AS order_cnt, SUM(o.amount) AS sale_amount, SUM(o.amount) / COUNT(DISTINCT o.order_id) AS avg_order_value FROM orders o LEFT JOIN products p ON o.product_id p.product_id WHERE o.order_date 2020-01-01 AND o.order_date 2020-04-01 GROUP BY COALESCE(p.category, 未知) ORDER BY sale_amount DESC;像这种题笔试评分的核心观察点就是你对业务数据的理解你不知道商品表是否有缺失所以应该主动选择最安全的 join 类型和空值处理方式。这个能力比背再多SQL语法都有用因为分析师每天面对的就是这种脏数据和不完全表。3. 概率、统计与业务推理题深度拆解3.1 条件概率与期望值用贝叶斯思路秒杀复杂题目卷二里的概率题有一道非常典型的条件概率题。大意是某推荐系统给用户推荐内容用户点击某篇笔记的概率是0.2如果这篇笔记是来自关注的人点击概率提升到0.5现在已知用户点击了一篇笔记问这篇笔记来自关注的人的概率是多少。题目还给了关注人内容的占比之类的条件。这题考察的就是贝叶斯公式。关键要抓住题目问的是后验概率而不是先验概率。很多人一看到0.2和0.5就直接二选一写答案但正确做法是设A笔记来自关注的人B用户点击笔记P(A)关注人内容的占比题目会给比如0.3P(B|A)0.5P(B|非A)0.2P(B)P(B|A)×P(A)P(B|非A)×P(非A)0.5×0.30.2×0.70.29P(A|B)0.5×0.3/0.29≈0.517注意这个计算结果会明显高于先验概率 P(A)0.3因为你已经知道了点击行为发生那么“来源是关注的人”这个事件的可能性被证据更新了。这类题放在业务场景里的含义是如果你要做个性化推送策略优先推关注的人的内容因为点击转化率更高。期望值的题也经常出现比如一个抽奖活动每次抽奖成本是3块钱中奖概率0.01中奖后可以获得200块钱奖励问该活动的期望收益。期望收益 0.01×200 0.99×0 - 3 -1也就是平均每抽一次亏1块钱。这种题考的不是计算难度而是期望值的定义——所有可能结果乘概率求和再减去成本。能把负期望的业务方案判断出来是数据分析师的基本盘。3.2 置信区间与假设检验别再死记公式了小红书卷子里统计学部分的题目大概率会有一道关于置信区间或假设检验的。比如给你一组用户的平均浏览时长样本均值是120秒样本标准差是30秒样本量是100让你求95%置信区间。解法95%置信区间 样本均值 ± 1.96 × 标准误标准误 样本标准差 / sqrt(样本量) 30 / 10 3秒。置信区间就是 120 ± 1.96×3也就是 (114.12, 125.88)。这里有个重要的理解层面置信区间不是“有95%的概率真实均值在这个区间内”而是“如果我们重复抽样100次有95次构建出来的置信区间会包含真实均值”。笔试里如果出了判断题这就是经典陷阱。我当年笔试时差点被绕进去还好之前系统看过统计推断知道频率学派对置信区间的定义。假设检验里最容易考的点是p值的含义和两类错误的区分。p值是“在原假设为真的前提下观察到当前样本或更极端情况的概率”。它不代表原假设为真的概率。第二类错误接受错误的原假设通过统计功效衡量增加样本量可以提高功效但也会让本来不显著的微小差异变得显著——这也是业务里经常出现“样本太大导致AB实验结论失真”的原因。3.3 业务分析题指标异动的排查框架卷二里业务分析题最经典的一题是某天小红书App的新用户次日留存率突然下降8%请分析可能的原因并写出你的排查思路。这类题没有标准答案但评卷人心里有一套合理的答题结构。我的建议是分层拆解第一层先确认数据本身没问题。指标下降可能是数据口径变化、埋点上报异常、ETL任务延迟或重复导致首日新增数据虚高。任何业务归因前都要先排除数据问题这个顺序不能反。第二层从“新增用户结构”和“次日留存表现”两个维度拆。新增用户是否集中到了低活跃渠道是否大量买量导致用户质量下降从“新增用户结构”拆是按渠道、按设备、按省份、按年龄段分组对比留存率从“次日留存表现”拆是看每个渠道自己的转化是否也变了如果所有渠道都在跌可能是产品全局出问题如果只是某个渠道跌那就是渠道问题或者买量策略问题。第三层看产品功能变化。有没有发新版、改首页推荐策略、调整兴趣标签体系如果这些变更和指标下跌时间点重合很可能就是原因。第四层再看外部因素比如竞品在同期做了投放活动、节假日效应结束等。最终答题时还要给出建议动作数据校验、维度拆解定位到具体渠道/版本、与产品团队确认版本变更、必要时回滚实验。这套框架我后来在工作中复盘各种指标异动时一直沿用非常好使。4. 业务案例与AB实验实操解析4.1 内容推荐AB实验设计与评价卷子里AB实验题的特点是把实验设计和结果分析糅在一起考。比如假设小红书想在发现页尝试一种新的推荐排序算法假设你有100万日活用户请设计一个实验来验证新算法是否优于旧算法。实验设计要点先把用户随机分组保证实验组和对照组的用户特征活跃度、兴趣分布、设备类型等没有显著差异。流量划分上用用户ID而不是设备ID或会话ID作为随机化单元避免同一用户在不同实验中相互污染。确定样本量时需要设定显著性水平通常α0.05、统计功效通常1-β0.8和最小可检测效应MDE然后带入样本量公式计算每组需要的用户数。到了结果分析部分除了看p值更要关注效应量。假设实验组平均点击率CTR提升0.1%p值小于0.001看起来是显著了但如果这个效应量对企业总体业务指标的贡献微乎其微同时新算法有潜在的成本或风险那这个实验结论就要谨慎落地。我当时答题时特地强调了“第一类错误和第二类错误权衡”实验中做了多个指标维度CTR、停留时长、收藏率、关注转化率如果每个指标都分别看p值会引入多重比较问题需要用bonferroni校正或先定义主指标和次要指标。这道题答到这个深度基本能和其他候选人拉开差距。4.2 案例题如何用数据驱动社区内容供给小红书作为内容社区内容供给是核心命脉。卷二里有一道综合案例分析题大致是发现平台优质笔记数量增长放缓活跃作者开始流失如何通过数据分析找出原因并提出策略建议。我的解题思路是三层结构第一层定义“优质笔记”和“活跃作者”的口径。优质笔记可以用人工评分、收藏量和阅读转化率作为复合指标活跃作者可以用“最近30天发布笔记不少于3篇且总阅读量超过1000”作为圈定标准。口径清晰后才能进行后续所有分析。第二层用漏斗模型分析作者生命周期。从注册、首次发布、多次发布、稳定输出、流失这几个环节分别计算转化率。找到流失最严重的环节——比如很多新作者第一次发布后就没有动力继续发那问题可能出在冷启动流量扶持不足或反馈激励不够。第三层提出数据支持的策略建议。如果流失集中在“首次发布后30天内”可以考虑优化新作者流量池、增加创作引导和正反馈机制如果流失出现在“成为优质作者之后”可能需要关注变现通路、粉丝互动质量和内容监管造成的误伤。这类案例题没有统一答案但思路完整、逻辑清晰、有数据支撑的答案明显比罗列一堆“提高质量、加强激励”这种正确的废话要得分高。我答题时习惯把每个策略建议前面加上“预期通过XX分析验证XX假设”让评卷人知道你不仅是拍脑袋而是有验证思维。4.3 Python与数据清洗题pandas操作要熟练到什么程度卷二里Python题的分值占比不大通常是一两道pandas操作题比如给你一个用户信息表和订单表要求合并、筛选、分组聚合、计算环比。难点不在语法而是考察处理速度和准确性。举个例子合并两个DataFrame时如果订单表的user_id和用户表的uid字段类型不一致一个是字符串一个是整数直接merge会匹配不上输出NaN。这就是真实场景里的经典坑import pandas as pd # 订单表 orders pd.DataFrame({ user_id: [1001, 1002, 1003], order_amount: [50, 30, 80] }) # 用户表 users pd.DataFrame({ uid: [1001, 1002, 1004], city: [上海, 北京, 广州] }) # 不统一类型直接merge匹配不到 merged pd.merge(orders, users, left_onuser_id, right_onuid, howleft) print(merged) # user_id 那列有值uid那列全是NaN # 正确做法先统一类型 orders[user_id] orders[user_id].astype(int) merged_correct pd.merge(orders, users, left_onuser_id, right_onuid, howleft)这道题虽然简单但当时我真的见过有候选人因为没做类型转换结果后续所有统计都是错的。笔试环境中时间紧、没法调试看数据详情所以平时就要养成写完 merge 后立刻检查是否出现了意外 NaN 的习惯。Python题想拿满分重点不是刷多难的算法而是把数据清洗的基本功磨扎实。5. 得分要点与个人实战总结5.1 阅卷人真正在意的三件事综合这份试卷和我后来面试他人的经验笔试阅卷人真正看重的其实是这三件事。第一答案的组织结构是否清晰。SQL题里有没有用CTE让逻辑分步骤可读业务分析题里有没有从数据质量、维度拆解、原因假设、验证方案、落地建议这几个层次依次展开一个结构清晰的答案即使个别细节有瑕疵也比一个思路混乱但结果全对的答案得分高。第二你有没有“业务感觉”。同样的SQL题有人只会机械地算一个数有人会顺带写一句“结合次日留存和7日留存判断不同渠道的用户质量建议对7日留存高但次日一般的内容社区渠道加大投入”。后者明显更有竞争力。第三细节是否经得起推敲。时间范围是闭区间还是开区间去重用的是COUNT(DISTINCT)还是COUNTleft join 和 inner join 是否考虑清楚这些细节拼起来决定了你是80分还是95分。5.2 时间分配和答题顺序心得这套卷子的题量按我的经验正常需要90分钟到120分钟。我当时的答题顺序策略是先做SQL题里自己最拿手的类型因为分值高、确定性高然后做Python题快速拿分再做概率统计题计算量小最后留足30分钟给业务大题。业务大题的时间分配尤其关键。很多人前面SQL花了太久最后案例分析题只有10分钟只能罗列几个要点草草收场。我的建议是无论前面多难都要给最后一大题预留至少25分钟。因为案例分析题是区分度最高的题型——SQL和概率题大家水平差不多但案例分析题的分数差距可以很大。宁可前面某道SQL题写得简略一点也要保证案例题有一个完整的分析框架。5.3 考后复盘我踩过的坑和学到的经验回看这份卷子的备考和实战过程有几个坑现在想起来还是很典型的。第一个坑是前期只刷SQL、不练业务题。我备考时候一度陷入“SQL刷题量上去了笔试稳了”的错觉。实际上笔试里的业务分析题和案例分析题没有任何刷题APP能覆盖必须靠平时积累业务分析框架。后来我强行给自己加了一个每天拆解一个业务分析案例的练习坚持了两周效果立竿见影——看到指标异动题脑子里立刻浮现出“数据校验→维度拆解→假设验证→落地建议”的完整路径。第二个坑是概率统计背公式但不懂原理。置信区间的公式谁都会套但p值到底是什么、为什么不能解读为“原假设为真的概率”这种理解层面的东西考试一换着说法考察就露馅。我的经验是把每个统计学概念都用自己的话复述一遍直到能解释给一个完全不懂统计的人听为止。第三个坑是Python题没重视类型检查和NaN检查。平时在自己电脑上跑数据类型不对会报错一眼就看到。但笔试环境里没法实时调试只能靠写代码时的防御性习惯提前规避。从那以后我写pandas代码凡是涉及merge和concat一定会在后面加一行df.isnull().sum()检查一下这个习惯一直保持到现在。5.4 一些后续可以继续扩展的方向如果你这份卷子做完了、复盘也做完了下一步我会建议你把同一套思路迁移到更复杂的场景里去练手。比如将留存率分析从“次日留存”扩展到“滑动窗口留存同期群分析”这类进阶分析方法在流量增长团队非常常用SQL方面可以从单表查询扩展到多表业务模型——用订单、商品、用户、行为日志四张表搭建一个简易的数据仓库模型然后练习各种维度组合查询AB实验方面可以找一些公开的案例分析重点看别人是怎么选择主指标、怎么处理多重比较问题的。数据分析这个岗位的笔试题目虽然每年都在变化但核心考察点非常稳定SQL要熟练、统计要理解、业务要框架化、Python要基本功。小红书这套卷二基本把这几块都覆盖到了吃透这套题再去面其他互联网公司的数据分析岗位至少在笔试阶段是够用的。最后分享一个我自己实际用的一个小技巧笔试答卷时每一道SQL题的最后我都会用注释写一句“本查询假设login_date为date类型若为timestamp需先转date再关联”。这种注释看似多余但能让阅卷人一眼看出你考虑过数据质量问题——这在真实的工作邮件里也是我会写的内容慢慢就形成了习惯。所谓高手就是在这些不起眼的细节上和别人拉开差距的。 小红书校招数据分析笔试题卷二复盘：SQL、业务分析与AB实验
直接开工。这阵子身边好几个朋友在准备数据方向的校招翻来覆去问我同一个问题小红书这种内容平台的笔试题到底怎么准备刚好我手里有一份小红书2020校招数据分析笔试题卷二当时做完之后整理过一版复盘今天把它重新打磨一下发出来给正在准备校招或者社招跳槽的朋友一个参考。这套题覆盖了SQL、概率统计、业务分析和Python整体难度中等偏上但对业务理解的要求比较高。如果你正在刷题准备面试或者刚入行想了解大厂数据分析师都在考什么、用什么思路解题那这篇文章值得看完。先说一下我对这份卷子的整体印象。小红书是内容社区产品核心业务围绕笔记、用户、互动、电商这几个板块展开所以笔试题里天然会带很强的业务场景色彩。卷二这个难度和卷一相比SQL占比差不多但业务分析题篇幅更大更看重候选人能不能从数据里推出可落地的运营建议——这和后面面试轮次的考察点一脉相承。换句话说笔试题不是单纯考你会不会写代码而是考你有没有分析问题的框架感。1. 试卷整体设计与考察逻辑拆解1.1 题型分布与考察能力矩阵先上结论整套卷子虽然是2020年的但现在回看它的出题思路和当前主流数据分析笔试高度一致——基础代码功底占总分的45%左右统计概率占20%业务分析与AB实验占20%剩下15%是综合性案例分析。这种配比决定了备考策略SQL必须扎实统计概念必须清晰业务场景题不能死记硬背框架要能结合业务逻辑现场推导。我当时把卷子里的题目按能力项重新归类了一下大概是这样考察模块占比典型题型核心能力SQL取数与表处理40%-45%留存计算、活跃用户统计、订单明细分析窗口函数、多表关联、去重逻辑概率与统计20%期望计算、置信区间、假设检验概率论基础、分布理解业务指标体系15%指标口径定义、指标异动原因分析指标体系思维、业务理解AB实验与因果推断15%-20%实验设计评估、结果显著性判断实验原理、常见陷阱识别Python数据处理少量DataFrame操作、简单数据清洗pandas基础这个分布其实透露了一个重要信息笔试阶段不太考算法题和机器学习模型推导那些是面试轮次的重点。笔试更关注“你拿到一堆业务数据能不能快速准确地算明白”。这和大厂数据分析师日常工作的核心是匹配的——先保证数据能取对、算对再谈分析深度。1.2 为什么业务分析题是卷面的重头戏卷二和卷一的最大区别就是把部分SQL题从纯代码技能题升级成了“代码业务判断”的复合题。比如让你统计不同来源渠道的用户次日留存率结果出来后还要判断哪个渠道质量更好、应该对哪个渠道加大投入。这种题考的不仅仅是你会不会写SQL而是你能不能把一张留存率表格翻译成业务行动。这种出题逻辑背后反映的是小红书这类内容平台数据分析团队的真实工作方式。日常业务方问的最多的问题就是“最近数据怎么跌了”“这个功能上线后效果咋样”“下个月目标是XX现在这个趋势能不能达成”——所有这些问题都要求分析师既能写复杂SQL取数又能结合业务逻辑给出解读。笔试题就是为了提前筛选具备这种复合能力的人。1.3 备考优先级排序建议如果你现在才开始准备笔试时间有限的情况下我建议按这个优先级来SQL窗口函数和复杂查询排第一因为这个分值最高而且可以通过短时间刷题快速提升概率统计里重点复习期望计算、条件概率、正态分布和置信区间AB实验部分搞清楚原理和常见误区不需要会手动推导样本量公式但要能看懂实验结论并指出坑。我当时用的备考方式是“以题带练”。每做完一道题不是对完答案就完事而是把这个题背后的知识点重新整理一遍比如遇到留存率计算的SQL题就把各种留存口径自然日留存、自然周留存、滑动窗口留存全部写一遍遇到置信区间题就把正态分布、t分布、Z检验和t检验的适用场景全部默写一遍。这套方法让我在笔试前把所有核心考点都过了一到两遍考场上看到题目基本不会慌。2. 核心考点解析SQL题目的高分解法2.1 留存率计算从基础写法到窗口函数优化留存率是内容平台笔试的必考题卷二里也不例外。题目大概是这种形式有一张用户登录表包含uid和login_date两个字段要求计算某段时间内新用户的次日、7日、30日留存率。基础做法是用自关联。先找出目标时间范围内的新增用户表再把这些用户和登录表关联判断每个用户在第N天有没有回来登录-- 新用户定义每个uid首次登录日期 WITH new_users AS ( SELECT uid, MIN(login_date) AS first_date FROM user_login GROUP BY uid HAVING MIN(login_date) 2020-01-01 AND MIN(login_date) 2020-02-01 ) -- 次日留存 SELECT COUNT(DISTINCT a.uid) AS new_user_cnt, COUNT(DISTINCT b.uid) AS retention_cnt, COUNT(DISTINCT b.uid) / COUNT(DISTINCT a.uid) AS next_day_retention_rate FROM new_users a LEFT JOIN user_login b ON a.uid b.uid AND b.login_date DATE_ADD(a.first_date, INTERVAL 1 DAY);这个写法能跑通但如果你想展示更进阶的能力可以用窗口函数让整个逻辑更清晰、扩展性更好WITH user_first AS ( SELECT uid, login_date, ROW_NUMBER() OVER(PARTITION BY uid ORDER BY login_date) AS rn FROM user_login ), base AS ( SELECT uid, login_date AS first_date FROM user_first WHERE rn 1 ), retention_calc AS ( SELECT a.first_date, COUNT(DISTINCT a.uid) AS new_users, COUNT(DISTINCT CASE WHEN b.login_date IS NOT NULL THEN a.uid END) AS retained_users FROM base a LEFT JOIN user_login b ON a.uid b.uid AND b.login_date BETWEEN DATE_ADD(a.first_date, INTERVAL 1 DAY) AND DATE_ADD(a.first_date, INTERVAL 1 DAY) GROUP BY a.first_date ) SELECT first_date, new_users, retained_users, retained_users / new_users AS retention_rate FROM retention_calc;这里有个小心机用DATE_ADD而不是直接判断DATEDIFF(b.login_date, a.first_date) 1。原因在于DATE_ADD写法在字段上有索引时更利于数据库优化器走索引扫描量小很多。笔试虽然不要求你写执行计划分析但这是个能体现工程素养的细节。注意笔试里的 SQL 环境大多只要求逻辑正确和数据准确不追求绝对最优性能。但千万不要用DATEDIFF(b.login_date, a.first_date) 1这种写法因为它在login_date字段上做了计算会导致索引失效数据量一大就会慢得离谱。职场上这种写法被数据研发看到大概率会被打回重写。2.2 活跃用户统计如何正确处理去重和跨表关联另一类高频SQL题是统计活跃用户这类题目出题人最爱在“去重”和“时间窗口”两个地方埋坑。比如给定用户行为记录表统计每周活跃用户数周活跃用户WAU、每月活跃用户数月活跃用户MAU以及连续活跃的用户。周活跃统计最经典的坑是“跨周问题”。如果直接按WEEK(login_date)分组周一和周日的数据会被分到同一周没问题但周日23:59产生的活跃和下周一的活跃可能被错误地归入不同周导致周活计算口径不一致。更合理的做法是先把login_date归一到周起始日再计数SELECT DATE_SUB(login_date, INTERVAL WEEKDAY(login_date) DAY) AS week_start, COUNT(DISTINCT uid) AS wau FROM user_behavior WHERE login_date BETWEEN 2020-01-01 AND 2020-03-31 GROUP BY DATE_SUB(login_date, INTERVAL WEEKDAY(login_date) DAY) ORDER BY week_start;WEEKDAY()函数返回周几0是周一6是周日用当前日期减去这个天数就得到了该周周一然后再按周一聚合无论数据落在哪一天都能分到正确的周。这个处理方式我面试的时候也经常拿来考别人十个人里有六七个第一次都会踩到跨周分组的坑。连续活跃用户是另一个常考类型。统计连续登录3天以上的用户核心思路是用login_date减去按用户分组后的行号得到一个分组标识再按用户和分组标识聚合WITH t AS ( SELECT uid, login_date, ROW_NUMBER() OVER(PARTITION BY uid ORDER BY login_date) AS row_num, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER(PARTITION BY uid ORDER BY login_date) DAY) AS diff_date FROM user_login ) SELECT uid, COUNT(DISTINCT login_date) AS consecutive_days FROM t GROUP BY uid, diff_date HAVING COUNT(DISTINCT login_date) 3;这个解题思路的原理很巧妙如果一个用户连续N天登录那么登录日期减去行号得到的结果是一样的。比如用户1号、2号、3号登录行号分别是1、2、3减去后得到的diff_date分别是0号、0号、0号——同一个值。中间如果断了一天diff_date就会往后跳一天用户就会被分到两个组里。把login_date转成日期格式后做减法如果中间有间隔diff_date就会变化。2.3 订单与内容付费多表join的数据口径小红书的业务场景里还有一块是内容付费和电商笔试里可能会有一个订单表和一个商品表要求统计各品类的销售额、订单量、客单价等指标。这题的精髓不在于join本身而在于你用什么字段join——是inner join还是left join。我见过很多人在这个题上翻车用 inner join 把订单表和商品表关联后发现订单量少了很多因为有一部分订单的商品ID在商品表里不存在比如商品已下架被清理。这时候应该用 left join 保留所有订单数据商品信息缺失的用默认值填充SELECT COALESCE(p.category, 未知) AS category, COUNT(DISTINCT o.order_id) AS order_cnt, SUM(o.amount) AS sale_amount, SUM(o.amount) / COUNT(DISTINCT o.order_id) AS avg_order_value FROM orders o LEFT JOIN products p ON o.product_id p.product_id WHERE o.order_date 2020-01-01 AND o.order_date 2020-04-01 GROUP BY COALESCE(p.category, 未知) ORDER BY sale_amount DESC;像这种题笔试评分的核心观察点就是你对业务数据的理解你不知道商品表是否有缺失所以应该主动选择最安全的 join 类型和空值处理方式。这个能力比背再多SQL语法都有用因为分析师每天面对的就是这种脏数据和不完全表。3. 概率、统计与业务推理题深度拆解3.1 条件概率与期望值用贝叶斯思路秒杀复杂题目卷二里的概率题有一道非常典型的条件概率题。大意是某推荐系统给用户推荐内容用户点击某篇笔记的概率是0.2如果这篇笔记是来自关注的人点击概率提升到0.5现在已知用户点击了一篇笔记问这篇笔记来自关注的人的概率是多少。题目还给了关注人内容的占比之类的条件。这题考察的就是贝叶斯公式。关键要抓住题目问的是后验概率而不是先验概率。很多人一看到0.2和0.5就直接二选一写答案但正确做法是设A笔记来自关注的人B用户点击笔记P(A)关注人内容的占比题目会给比如0.3P(B|A)0.5P(B|非A)0.2P(B)P(B|A)×P(A)P(B|非A)×P(非A)0.5×0.30.2×0.70.29P(A|B)0.5×0.3/0.29≈0.517注意这个计算结果会明显高于先验概率 P(A)0.3因为你已经知道了点击行为发生那么“来源是关注的人”这个事件的可能性被证据更新了。这类题放在业务场景里的含义是如果你要做个性化推送策略优先推关注的人的内容因为点击转化率更高。期望值的题也经常出现比如一个抽奖活动每次抽奖成本是3块钱中奖概率0.01中奖后可以获得200块钱奖励问该活动的期望收益。期望收益 0.01×200 0.99×0 - 3 -1也就是平均每抽一次亏1块钱。这种题考的不是计算难度而是期望值的定义——所有可能结果乘概率求和再减去成本。能把负期望的业务方案判断出来是数据分析师的基本盘。3.2 置信区间与假设检验别再死记公式了小红书卷子里统计学部分的题目大概率会有一道关于置信区间或假设检验的。比如给你一组用户的平均浏览时长样本均值是120秒样本标准差是30秒样本量是100让你求95%置信区间。解法95%置信区间 样本均值 ± 1.96 × 标准误标准误 样本标准差 / sqrt(样本量) 30 / 10 3秒。置信区间就是 120 ± 1.96×3也就是 (114.12, 125.88)。这里有个重要的理解层面置信区间不是“有95%的概率真实均值在这个区间内”而是“如果我们重复抽样100次有95次构建出来的置信区间会包含真实均值”。笔试里如果出了判断题这就是经典陷阱。我当年笔试时差点被绕进去还好之前系统看过统计推断知道频率学派对置信区间的定义。假设检验里最容易考的点是p值的含义和两类错误的区分。p值是“在原假设为真的前提下观察到当前样本或更极端情况的概率”。它不代表原假设为真的概率。第二类错误接受错误的原假设通过统计功效衡量增加样本量可以提高功效但也会让本来不显著的微小差异变得显著——这也是业务里经常出现“样本太大导致AB实验结论失真”的原因。3.3 业务分析题指标异动的排查框架卷二里业务分析题最经典的一题是某天小红书App的新用户次日留存率突然下降8%请分析可能的原因并写出你的排查思路。这类题没有标准答案但评卷人心里有一套合理的答题结构。我的建议是分层拆解第一层先确认数据本身没问题。指标下降可能是数据口径变化、埋点上报异常、ETL任务延迟或重复导致首日新增数据虚高。任何业务归因前都要先排除数据问题这个顺序不能反。第二层从“新增用户结构”和“次日留存表现”两个维度拆。新增用户是否集中到了低活跃渠道是否大量买量导致用户质量下降从“新增用户结构”拆是按渠道、按设备、按省份、按年龄段分组对比留存率从“次日留存表现”拆是看每个渠道自己的转化是否也变了如果所有渠道都在跌可能是产品全局出问题如果只是某个渠道跌那就是渠道问题或者买量策略问题。第三层看产品功能变化。有没有发新版、改首页推荐策略、调整兴趣标签体系如果这些变更和指标下跌时间点重合很可能就是原因。第四层再看外部因素比如竞品在同期做了投放活动、节假日效应结束等。最终答题时还要给出建议动作数据校验、维度拆解定位到具体渠道/版本、与产品团队确认版本变更、必要时回滚实验。这套框架我后来在工作中复盘各种指标异动时一直沿用非常好使。4. 业务案例与AB实验实操解析4.1 内容推荐AB实验设计与评价卷子里AB实验题的特点是把实验设计和结果分析糅在一起考。比如假设小红书想在发现页尝试一种新的推荐排序算法假设你有100万日活用户请设计一个实验来验证新算法是否优于旧算法。实验设计要点先把用户随机分组保证实验组和对照组的用户特征活跃度、兴趣分布、设备类型等没有显著差异。流量划分上用用户ID而不是设备ID或会话ID作为随机化单元避免同一用户在不同实验中相互污染。确定样本量时需要设定显著性水平通常α0.05、统计功效通常1-β0.8和最小可检测效应MDE然后带入样本量公式计算每组需要的用户数。到了结果分析部分除了看p值更要关注效应量。假设实验组平均点击率CTR提升0.1%p值小于0.001看起来是显著了但如果这个效应量对企业总体业务指标的贡献微乎其微同时新算法有潜在的成本或风险那这个实验结论就要谨慎落地。我当时答题时特地强调了“第一类错误和第二类错误权衡”实验中做了多个指标维度CTR、停留时长、收藏率、关注转化率如果每个指标都分别看p值会引入多重比较问题需要用bonferroni校正或先定义主指标和次要指标。这道题答到这个深度基本能和其他候选人拉开差距。4.2 案例题如何用数据驱动社区内容供给小红书作为内容社区内容供给是核心命脉。卷二里有一道综合案例分析题大致是发现平台优质笔记数量增长放缓活跃作者开始流失如何通过数据分析找出原因并提出策略建议。我的解题思路是三层结构第一层定义“优质笔记”和“活跃作者”的口径。优质笔记可以用人工评分、收藏量和阅读转化率作为复合指标活跃作者可以用“最近30天发布笔记不少于3篇且总阅读量超过1000”作为圈定标准。口径清晰后才能进行后续所有分析。第二层用漏斗模型分析作者生命周期。从注册、首次发布、多次发布、稳定输出、流失这几个环节分别计算转化率。找到流失最严重的环节——比如很多新作者第一次发布后就没有动力继续发那问题可能出在冷启动流量扶持不足或反馈激励不够。第三层提出数据支持的策略建议。如果流失集中在“首次发布后30天内”可以考虑优化新作者流量池、增加创作引导和正反馈机制如果流失出现在“成为优质作者之后”可能需要关注变现通路、粉丝互动质量和内容监管造成的误伤。这类案例题没有统一答案但思路完整、逻辑清晰、有数据支撑的答案明显比罗列一堆“提高质量、加强激励”这种正确的废话要得分高。我答题时习惯把每个策略建议前面加上“预期通过XX分析验证XX假设”让评卷人知道你不仅是拍脑袋而是有验证思维。4.3 Python与数据清洗题pandas操作要熟练到什么程度卷二里Python题的分值占比不大通常是一两道pandas操作题比如给你一个用户信息表和订单表要求合并、筛选、分组聚合、计算环比。难点不在语法而是考察处理速度和准确性。举个例子合并两个DataFrame时如果订单表的user_id和用户表的uid字段类型不一致一个是字符串一个是整数直接merge会匹配不上输出NaN。这就是真实场景里的经典坑import pandas as pd # 订单表 orders pd.DataFrame({ user_id: [1001, 1002, 1003], order_amount: [50, 30, 80] }) # 用户表 users pd.DataFrame({ uid: [1001, 1002, 1004], city: [上海, 北京, 广州] }) # 不统一类型直接merge匹配不到 merged pd.merge(orders, users, left_onuser_id, right_onuid, howleft) print(merged) # user_id 那列有值uid那列全是NaN # 正确做法先统一类型 orders[user_id] orders[user_id].astype(int) merged_correct pd.merge(orders, users, left_onuser_id, right_onuid, howleft)这道题虽然简单但当时我真的见过有候选人因为没做类型转换结果后续所有统计都是错的。笔试环境中时间紧、没法调试看数据详情所以平时就要养成写完 merge 后立刻检查是否出现了意外 NaN 的习惯。Python题想拿满分重点不是刷多难的算法而是把数据清洗的基本功磨扎实。5. 得分要点与个人实战总结5.1 阅卷人真正在意的三件事综合这份试卷和我后来面试他人的经验笔试阅卷人真正看重的其实是这三件事。第一答案的组织结构是否清晰。SQL题里有没有用CTE让逻辑分步骤可读业务分析题里有没有从数据质量、维度拆解、原因假设、验证方案、落地建议这几个层次依次展开一个结构清晰的答案即使个别细节有瑕疵也比一个思路混乱但结果全对的答案得分高。第二你有没有“业务感觉”。同样的SQL题有人只会机械地算一个数有人会顺带写一句“结合次日留存和7日留存判断不同渠道的用户质量建议对7日留存高但次日一般的内容社区渠道加大投入”。后者明显更有竞争力。第三细节是否经得起推敲。时间范围是闭区间还是开区间去重用的是COUNT(DISTINCT)还是COUNTleft join 和 inner join 是否考虑清楚这些细节拼起来决定了你是80分还是95分。5.2 时间分配和答题顺序心得这套卷子的题量按我的经验正常需要90分钟到120分钟。我当时的答题顺序策略是先做SQL题里自己最拿手的类型因为分值高、确定性高然后做Python题快速拿分再做概率统计题计算量小最后留足30分钟给业务大题。业务大题的时间分配尤其关键。很多人前面SQL花了太久最后案例分析题只有10分钟只能罗列几个要点草草收场。我的建议是无论前面多难都要给最后一大题预留至少25分钟。因为案例分析题是区分度最高的题型——SQL和概率题大家水平差不多但案例分析题的分数差距可以很大。宁可前面某道SQL题写得简略一点也要保证案例题有一个完整的分析框架。5.3 考后复盘我踩过的坑和学到的经验回看这份卷子的备考和实战过程有几个坑现在想起来还是很典型的。第一个坑是前期只刷SQL、不练业务题。我备考时候一度陷入“SQL刷题量上去了笔试稳了”的错觉。实际上笔试里的业务分析题和案例分析题没有任何刷题APP能覆盖必须靠平时积累业务分析框架。后来我强行给自己加了一个每天拆解一个业务分析案例的练习坚持了两周效果立竿见影——看到指标异动题脑子里立刻浮现出“数据校验→维度拆解→假设验证→落地建议”的完整路径。第二个坑是概率统计背公式但不懂原理。置信区间的公式谁都会套但p值到底是什么、为什么不能解读为“原假设为真的概率”这种理解层面的东西考试一换着说法考察就露馅。我的经验是把每个统计学概念都用自己的话复述一遍直到能解释给一个完全不懂统计的人听为止。第三个坑是Python题没重视类型检查和NaN检查。平时在自己电脑上跑数据类型不对会报错一眼就看到。但笔试环境里没法实时调试只能靠写代码时的防御性习惯提前规避。从那以后我写pandas代码凡是涉及merge和concat一定会在后面加一行df.isnull().sum()检查一下这个习惯一直保持到现在。5.4 一些后续可以继续扩展的方向如果你这份卷子做完了、复盘也做完了下一步我会建议你把同一套思路迁移到更复杂的场景里去练手。比如将留存率分析从“次日留存”扩展到“滑动窗口留存同期群分析”这类进阶分析方法在流量增长团队非常常用SQL方面可以从单表查询扩展到多表业务模型——用订单、商品、用户、行为日志四张表搭建一个简易的数据仓库模型然后练习各种维度组合查询AB实验方面可以找一些公开的案例分析重点看别人是怎么选择主指标、怎么处理多重比较问题的。数据分析这个岗位的笔试题目虽然每年都在变化但核心考察点非常稳定SQL要熟练、统计要理解、业务要框架化、Python要基本功。小红书这套卷二基本把这几块都覆盖到了吃透这套题再去面其他互联网公司的数据分析岗位至少在笔试阶段是够用的。最后分享一个我自己实际用的一个小技巧笔试答卷时每一道SQL题的最后我都会用注释写一句“本查询假设login_date为date类型若为timestamp需先转date再关联”。这种注释看似多余但能让阅卷人一眼看出你考虑过数据质量问题——这在真实的工作邮件里也是我会写的内容慢慢就形成了习惯。所谓高手就是在这些不起眼的细节上和别人拉开差距的。