每年到秋招季社群里都会有人问小红书2020校招数据分析笔试题卷三的解析。这套题流传很广口碑也有点特殊它没有卷四那种偏算法的压迫感又比卷一更贴近真实业务难度恰好卡在“看起来都会做、但想拿满分很难”的位置上。我自己当年做这套题的时候最大的感受是它不考你背了多少公式而是考你在一个内容社区的业务场景里能不能用数据把问题拆清楚。后来我参与过几届校招面试也拿这套题当模拟卷给实习生练手。站在出题人的角度回头看这套题其实很有代表性——数理统计、SQL、业务分析、开放题四个模块基本把数据分析岗日常工作里最常碰到的四类问题都覆盖了。这篇文章按题型模块逐题复盘把我当时做题的思路、后来批改时看到的典型错误以及针对性的备考建议一次性写清楚。1. 试卷整体复盘一套考“业务直觉工程能力”的组合题先说试卷结构。根据网上流传的考生回忆版卷三总时长120分钟整体分为四大部分数理统计与概率、SQL与数据提取、业务分析、综合开放题。前两块偏硬技能后两块偏业务思维分值分布大致是2:3:3:2。这个比例本身就在传递一个信号数据分析岗不是纯技术岗SQL再溜业务题答偏了照样拿不到offer。我当时做题的时间分配大致是数理统计题25分钟SQL题40分钟业务分析题30分钟开放题15分钟剩下10分钟检查。这个节奏偏紧尤其是SQL题如果平时没练过窗口函数很容易卡在第三道题上导致后面业务题没时间细想。这套题值得做的原因在于它的业务题全部围绕内容社区展开比如笔记互动率、博主活跃、推荐曝光、收藏转化。这对准备投社区产品、内容平台、种草电商方向的候选人来说几乎是量身定做的模拟训练。哪怕你投的不是小红书这套题的业务分析思路也可以直接迁移到其他UGC产品上。卷三最典型的特征是它非常忌讳“背答案式”的答题方式。比如业务题里给你一个互动率下降的场景如果你上来就写“因为内容质量下降”那基本拿不到分。出题人想看的是你如何定义质量、用哪些指标度量、怎么排除其他可能的原因、最后怎么用数据验证假设。这套逻辑就是分析师日常工作的基本盘。从我自己批改模拟卷的经验看数理统计题的错误率集中在“不会区分先验概率和条件概率”SQL题的错误率集中在“留存用户没有按天去重”业务题的错误率集中在“只给结论不给过程”。这些问题在后面逐个展开讲。2. 数理统计题贝叶斯和显著性检验里那些“看着对但不对”的答案2.1 一道贝叶斯题干掉一半人卷三有一道题的大致场景是在内容池里高质量笔记占比20%普通笔记占比80%。高质量笔记被推荐系统选入推荐池的概率是90%普通笔记被选入的概率是10%。现在有一篇笔记被选入了推荐池问它是高质量笔记的概率是多少。这道题表面是概率计算实际考的是贝叶斯公式和基率谬误。很多人的第一反应是“都进推荐池了肯定是高质量啊概率至少80%以上”这就是典型的忽略先验概率。先验里高质量笔记只占20%就算被选入的概率很高也会被基数庞大的普通笔记稀释。正确做法是用贝叶斯公式P(高质量|进推荐池) P(进推荐池|高质量) × P(高质量) / [P(进推荐池|高质量) × P(高质量) P(进推荐池|普通) × P(普通)]代入数值P 0.9 × 0.2 / (0.9 × 0.2 0.1 × 0.8) 0.18 / 0.26 ≈ 69.2%也就是说一篇被推荐系统选中的笔记是高质量的概率并不是90%而是约69%。这就是“先验概率”在真实业务里的作用。推荐池的precision看着很高但在低质量笔记基数庞大的前提下池子里依然会混入不少低质内容。放到实际场景里这直接关系到推荐算法团队怎么设定内容质量门槛。这道题想通之后再看很多业务问题就会有新感觉。比如内容审核部门标记了一批违规笔记模型召回率做到90%precision做到90%听起来很厉害。但如果整个平台的违规笔记比例只有1%那一个被标记为违规的笔记真正违规的概率其实不到10%。不是模型不好而是基率太低。数据分析师如果不能把这个逻辑讲给业务听很容易导致资源错配。2.2 显著性检验的陷阱数值提升不等于效果显著卷三的统计题里还有一类很典型的AB测试题。大致场景是推荐策略改版后实验组点击率2.2%对照组2.0%样本量每组10000问这个提升是否显著。这里有个很常见的坑只看数值2.2%比2.0%高了10%新人很容易直接写“显著提升”。但如果做显著性检验用两独立样本比例检验的z统计量z (0.022 - 0.02) / sqrt(0.02 × 0.98 / 10000 0.022 × 0.978 / 10000) ≈ 0.986z值不到1.96p值大约0.32远大于0.05差异根本不显著。换句话说2.2%和2.0%的差距很可能只是随机波动不能得出实验有效的结论。这个题目的价值不在于计算本身而在于提醒你数据报表里每天有无数的指标在涨涨跌跌如果每次波动都当成业务变化去分析团队会累死决策也会被噪声带着跑。真正负责任的分析师看到指标变化的第一反应应该是“这个变化有没有超过正常波动范围”而不是马上写归因报告。我还见过一个进阶版问法如果想让这个实验能检测出5%的相对提升需要多少样本量。这个就要用到样本量预估公式核心参数是基线转化率、最小可检测效应、显著性水平0.05和统计功效0.8。它考察的不只是公式记忆而是“你知不知道做实验之前就要想好样本量”这个工程经验。2.3 统计题背后的真实考察点这套卷子里的统计题与其说在考数学不如说在考“对不确定性的理解”。贝叶斯题考的是“看到结果后如何修正认知”显著性检验考的是“看到差异后如何排除随机性”。这两个能力恰好是数据分析师日常做归因、做实验评估时最核心的底层思维。我在批改模拟卷时发现很多同学的解题过程是公式写对了数值代对了结果也算对了但完全没解释结论的业务含义。比如算完贝叶斯概率不写“这意味着推荐池里的低质内容比想象中多建议提高准入门槛”这类落地的结论。算完显著性检验不写“当前样本量不足以支撑结论建议延长实验周期或扩大流量”。这就是典型的“会做题不会做分析”。所以我的建议是刷概率统计题的时候不要只满足于算出答案每道题都要想一步——如果这是在业务周会上我会怎么把这个结论讲给产品经理听。3. SQL实战题留存、漏斗和连续行为SQL写对只是及格线3.1 留存计算去重是保命题卷三的SQL题里留存计算几乎是必考的。常见的题目形式是给定一张用户活跃表user_id, dt求某个新增用户群体的次日留存率、7日留存率、30日留存率。这道题的核心难点有三个一是如何定义“新增用户”二是如何做每日去重三是如何处理未来没有活跃记录的用户。先把标准写法给出来SELECT a.install_date, COUNT(DISTINCT a.user_id) AS new_users, COUNT(DISTINCT CASE WHEN DATEDIFF(b.dt, a.install_date) 1 THEN b.user_id END) AS d1_retained, COUNT(DISTINCT CASE WHEN DATEDIFF(b.dt, a.install_date) 6 THEN b.user_id END) AS d7_retained, COUNT(DISTINCT CASE WHEN DATEDIFF(b.dt, a.install_date) 29 THEN b.user_id END) AS d30_retained FROM dim_new_user a LEFT JOIN user_active b ON a.user_id b.user_id AND b.dt a.install_date GROUP BY a.install_date为什么用LEFT JOIN而不用INNER JOIN这是第一个坑。用INNER JOIN会直接把没有后续活跃记录的新增用户丢掉导致留存率被严重高估。比如100个新增用户只有30个次日回访如果这30个人才出现在结果表里算出来留存率是100%这就完全错了。第二个坑是去重。用户一天内可能打开App多次活跃表里同一个user_id同一天会有多行记录。如果不加COUNT(DISTINCT)留存用户数会被重复计数数字虚高。我在批卷时经常看到有人写COUNT(b.user_id)这就是实打实的丢分点。第三个坑是时间窗口的边界。DATEDIFF(b.dt, a.install_date) 1算次日 6算7日内留存还是 7算第7天留存不同公司的口径不一样笔试里只要统一口径并写清楚就行但千万别混用。3.2 漏斗转化注意时序和去重漏斗题在卷三里也有出现通常是给一张用户行为事件表user_id, event_time, event_name事件包括曝光、点击、收藏、下单等求相邻环节的转化率。一个标准思路是把事件表自关联限定后一个事件发生在前一个事件之后SELECT COUNT(DISTINCT CASE WHEN e1.event_name exposure AND e2.event_name click THEN e1.user_id END) * 1.0 / NULLIF(COUNT(DISTINCT CASE WHEN e1.event_name exposure THEN e1.user_id END), 0) AS click_rate FROM event_log e1 LEFT JOIN event_log e2 ON e1.user_id e2.user_id AND e2.event_time e1.event_time AND e2.event_name click这个写法能跑通但有个隐藏问题如果一个用户先曝光、再点击、再曝光、再点击那它会被重复匹配所以COUNT(DISTINCT)不能省。另外如果你只关心“曝光后24小时内的点击”还要在JOIN条件里加上时间窗口否则一个用户两天后的点击也会被算进转化漏斗就失真了。在实际业务中漏斗题的答题质量往往体现在你是否主动补充了“时间窗口”和“去重口径”。比如电商场景里一次浏览后7天内的下单才算转化那SQL的JOIN条件里就要写e2.event_time BETWEEN e1.event_time AND DATE_ADD(e1.event_time, INTERVAL 7 DAY)。能把这一层写进去说明你是真正做过漏斗分析的不是背题的。3.3 连续行为窗口函数的经典应用卷三有一道比较有区分度的SQL题是求连续7天发布笔记的用户。这道题需要处理同一个用户每天可能有多条发布记录需要先去重然后对每个用户按日期排序最后用日期与序号差值的稳定性来识别连续区间。核心写法WITH user_pub_daily AS ( SELECT DISTINCT user_id, dt FROM user_publish ), ranked AS ( SELECT user_id, dt, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY dt) AS rn FROM user_pub_daily ) SELECT user_id, MIN(dt) AS continuous_start, MAX(dt) AS continuous_end, COUNT(*) AS continuous_days FROM ( SELECT user_id, dt, DATE_SUB(dt, INTERVAL rn DAY) AS grp FROM ranked ) t GROUP BY user_id, grp HAVING COUNT(*) 7这个方法的原理是对于连续日期序列比如7月1日、2日、3日它们对应的rn分别是1、2、3相减后得到6月30日、6月30日、6月30日是同一个grp。如果中间断了一天比如7月1日、3日rn是1、2相减后是6月30日、7月1日grp就不同了。我当时第一次做这道题卡在了一个细节上忘了先对(user_id, dt)去重。如果用户某天发布了两篇笔记同一个日期对应两个rn连续的判定就错乱了。这个去重步骤就是这道题最容易丢分的地方。3.4 SQL题为什么要这样考从题型设置能看出来SQL题考察的重点不是语法炫技而是三件基本功一是对业务口径的理解什么是留存、什么是漏斗二是对数据质量问题的敏感度要不要去重、要不要处理NULL三是写出的查询能否高效落地是不是全表扫描、能不能用分区字段。这也解释了为什么卷三的SQL题要和业务场景绑定。因为真实工作里你拿到手的绝不是一张干净的“测试表”而是要自己判断哪些字段可能有重复、哪些用户需要排除、哪些事件才算有效转化。笔试里多踩几个坑面试时被打个措手不及的概率就小一点。4. 业务分析题内容社区的指标异动和流失预警考的是拆解能力4.1 指标体系先讲清楚北极星指标再谈拆解业务分析题里有一类基础题给一个内容社区产品让你设计核心指标体系并确定北极星指标。这类题没有唯一答案但答题框架是有高下之分的。我当时写的是北极星指标拆成供给侧和消费侧两条链路。供给侧看内容生产者规模和生产频率核心指标是“每周发布笔记的用户数”和“人均发布篇数”消费侧看内容消费深度核心指标是“日活跃用户人均有效阅读时长”和“收藏/点赞/评论率”。两条链路中间是匹配效率也就是推荐系统的曝光到点击率、搜索的点击率、关注页的打开率。批改卷子时我最怕看到的一句话是“北极星指标我选DAU因为DAU代表产品活跃度”。DAU当然重要但它是结果指标不是过程指标。它会受买量、外部事件、季节波动影响你很难只靠它判断推荐策略改得对不对。一个好的北极星指标应该是能反映用户核心价值被满足程度的指标并且在它变化时你能顺着指标拆解树找到原因。另外指标定义一定要清晰。比如“互动率”分母是曝光量还是阅读量分子是点赞收藏评论还是只算评论不同的口径算出来的数值可能差好几倍。笔试里把这个口径写清楚本身就是得分点。4.2 指标异动归因用排除法缩小范围卷三里有一道比较典型的场景题某社区App的笔记互动率连续一周下降从5.2%降到4.6%请分析可能原因并给出验证方案。这道题我建议用结构化框架来答而不是想到什么写什么。大致思路是第一步先确认数据真实性。检查埋点是否正常、版本升级是否导致口径变化、数据是否回刷。没有这一步直接冲进去分析归因很容易白忙一场。第二步做维度拆解。把互动率按时间维度每天、每个时段、设备维度iOS/Android、App版本、渠道维度自然流量/广告/搜索、内容维度笔记类目、图文/视频、发布时间、用户维度新老用户、活跃度分层逐一切开看。这里的关键技巧是“对比”找出下降最集中的子群体。比如发现视频笔记的互动率没变图文笔记的互动率大幅下降那问题就大概率出在图文内容的供给或展现上。第三步分内外因。内因包括推荐策略调整、内容审核规则收紧、推荐池供给结构变化、产品交互改版外因包括节假日影响、竞品活动分流、自然流量波动。内因可以用内部数据验证外因往往要通过竞品情报和行业数据交叉验证。第四步形成结论和下一步动作而不是停在“数据下降”。比如如果定位到是推荐池引入了一批低质笔记导致点击率下降那可以建议提高质量分门槛、上线新的低质内容过滤策略并设置AB实验验证。这道题的本质是在考察你的拆解逻辑是不是树状的、可穷举的、能落地的。很多同学答得不好不是因为分析能力弱而是因为思维太跳跃想到一个原因就写一个原因没有层次。4.3 博主流失预警用数据识别“将要流失的人”卷三还有一道题是关于博主流失预警的场景是平台发现一部分原本高产的博主近几周发布频率明显下降如何定义流失、如何建模预测、如何干预。这类题在内容平台非常典型答题的关键是先把“流失”定义清楚。不能等到用户彻底不来了才叫流失那就晚了。我一般建议定义成“连续30天未发布笔记且未发生互动行为”同时在预测特征里加入“早期流失信号”比如发布频率下降、登录频次下降、互动数据下滑、反馈工单增多、使用竞品时长增加。特征选择上可以分成三类用户静态属性注册时间、身份认证、粉丝量级、行为特征近7天/14天/30天发布数、登录天数、互动次数、搜索次数、内容特征近一个月笔记平均互动率、笔记类型分布。预测模型不需要太复杂逻辑回归或XGBoost就够用笔试里重点是要讲清楚样本怎么标注、特征怎么构造、模型效果怎么评估。评估指标也有讲究。对于流失预警只看准确率没有意义因为没流失的用户占了大多数全预测成“不流失”准确率也有90%以上。更重要的是召回率——在真正流失的用户里我们提前捞出了多少。同时还要看干预ROI比如运营给预警用户发push召回成本是多少、挽回的用户LTV是多少这才是一个闭环。我觉得这道题最能拉开差距的地方在于你是否能提出“干预后如何评估效果”。好一点的答题思路是把用户随机分为干预组和对照组干预组发召回策略对照组不发观察后续发布回归率是否有显著差异。能想到这一步说明你真做过增长分析而不只是背了一遍建模流程。5. 综合开放题没有标准答案但得分点完全可以设计5.1 一个典型开放题综合开放题通常是压轴题不一定考具体技能而是给你一个模糊的业务问题看你能不能给出严谨的分析思路。卷三里有一道让我印象很深的题平台收到大量用户反馈说“推荐流内容越来越同质化”请定义并量化这个问题并给出解决思路。这题一上来就会让很多人懵。因为“同质化”不是现成指标你得先定义它。我当时的思路是同质化可以从两个维度量化。一是单一用户侧单位时间窗口内推荐流里相似内容的比例比如同一博主连续出现次数、同一话题标签的曝光占比、内容低相似度embeding相似度指标二是供给侧top内容在总曝光中的集中度比如按笔记聚合的曝光基尼系数如果越高说明头部内容垄断越严重用户当然会觉得翻来翻去都是差不多的东西。定义完之后还要设计实验验证“同质化是否真的导致体验下降”。可以把用户按同质化指数分为高、中、低三组看他们的次日留存、使用时长、搜索行为是否有显著差异。如果高同质化组的留存确实更差那就说明这个现象值得解决。解决思路可以分产品和算法两个方向。产品侧可以增加“不看此类内容”“减少相似推荐”等显式反馈入口算法侧可以在精排阶段加入多样性约束比如MMR算法或者DPP采样在相关性和多样性之间做平衡。5.2 一个能通吃的答题框架开放题的核心不是让你在15分钟内真正解决一个复杂问题而是看你的思考是否结构化。我总结了一个可以反复套用的框架目标-定义-度量-归因-行动-评估。目标先理解题目的诉求是提升体验、提升指标、还是找出原因。定义把模糊概念拆成可操作的定义比如“同质化”拆成用户侧相似度和供给侧集中度。度量给出具体指标、口径、数据来源。归因分析可能的成因并设计对比分析或实验来验证。行动基于归因设计产品和策略上的改进方案。评估说明如何衡量改进效果最好是AB实验。这套框架在笔试和面试里都非常好用。它最大的价值是让面试官觉得你有完整的分析思维而不是东一榔头西一棒子。5.3 数据敏感度是可以“表演”出来的开放题中除了答题框架还有一类隐性加分项主动提出数据需求。比如分析同质化问题时你可以说“我需要补充用户对推荐流的反馈数据包括点击不喜欢、举报、长按不感兴趣的次数”或者“我需要知道推荐池的供给来源分布才能判断同质化是算法问题还是供给问题”。这种能力就是数据敏感度它代表你对业务的关键变量有感知知道哪些数据能帮助判断。哪怕是临时想的补充需求也让你的答案显得更立体。我建议所有备考数据分析岗位的同学平时多看看业务后台的数据字典多想想“如果我要验证这个假设需要哪几张表”这个习惯比刷题更能提升面试表现。6. 结合这套卷子我建议你按这个顺序准备数据分析校招6.1 知识点优先级排除运气因素卷三基本划出了数据分析校招笔试的重点地图。按投入产出比排序我建议的复习顺序是SQL 统计概率 业务分析框架 开放题表达。SQL是硬通货笔试筛人的第一关窗口函数、留存去重、漏斗转化这几类题型必须练到条件反射。统计概率不用追求纯数学深度重点是贝叶斯、假设检验、常见分布、中心极限定理以及这些概念在业务场景里的应用。业务分析框架需要积累量平时多看一些指标异动归因、实验评估、用户分层分析的案例形成自己的分析模板。开放题则靠思维训练可以用上面提到的“目标-定义-度量-归因-行动-评估”框架刻意练习。6.2 备考节奏与工具我比较推荐三周冲刺方案。第一周刷SQL每天5道题打底重点刷留存、漏斗、连续行为、开窗函数排序刷完必须口头复述一遍每一步的业务含义。第二周攻克统计题把概率论和假设检验的经典题型全部过一遍尤其要理解基率谬误和显著性检验的直觉逻辑。第三周集中练业务题和开放题每天找一道真实的业务分析题按结构化框架写答案写完后自己复述一遍看能不能把逻辑讲圆。工具方面SQL用本地数据库或在线练习平台都行关键是最好在引擎里实际跑一遍确认自己写的查询能出结果。统计概率可以用Python的scipy做验证比如自己写个模拟AB测试的代码看重复抽样下p值的分布。练开放题的时候没条件找真人交流也可以把自己的答案写下来隔一天再看往往能发现逻辑跳跃的地方。6.3 常见失误清单结合批改模拟卷的经验我列一个高频错误清单考前过一遍很有用留存率计算用了INNER JOIN偷偷丢掉了没有后续行为的用户导致留存率高到离谱。多个字段计数时不用DISTINCT把重复记录算进去活跃天数、曝光量全被撑大。做指标异动归因时只拆了一个维度就下结论没有做多维度交叉验证。统计检验不看p值就直接说“显著提升”看到上涨曲线就强行归因。开放题只写结论不给推导过程没有把定义、数据口径、验证逻辑交代清楚。答题时不写“这个指标口径是……”留下一堆业务名词让面试官猜。每一条都是我实际看到过的丢分原因。尤其是第一条和第二条SQL题里最常见的死法就是没想清楚“到底要对什么去重”。这套卷子做完如果你能对每一道题都讲清楚“为什么这样做”那校招笔试这关基本就稳了。我自己在带实习生的时候经常说一句话面试官要的不是满分答案而是看到一个能独立思考、能落地干活的人。卷三的价值恰恰在于它帮你提前暴露问题——现在暴露的每一个短板都是正式面试前的宝贵提示。