小红书数据分析校招笔试复盘：从SQL到业务案例的完整拆解

如果你正在准备互联网公司的数据分析岗位校招又恰好对小红书这类内容社区的笔试风格好奇那这篇复盘应该对你有用。2019年小红书校园招聘数据分析岗位在线笔试第一批我亲身经历过考完之后最大的感受是它和大厂通用的数据分析笔试不太一样更偏业务、更看重你对“内容社区”的理解力而不是单纯考察你SQL写得有多快、公式背得有多熟。这篇内容打算分几块来讲先拆解这场笔试背后的岗位能力模型再还原整套卷子的题型结构和答题节奏然后把每个核心考点掰开揉碎讲清楚最后把在线笔试环境下容易踩的坑和复盘经验一起整理出来。无论你是正准备数据分析校招还是想转行做数据相关岗位这篇复盘都能帮你少走一些弯路。1. 笔试到底在考什么先搞懂岗位能力模型1.1 内容社区的数据分析师在做什么很多人在准备笔试的时候第一反应是刷SQL题、背统计公式、看机器学习算法这个方向本身没错但如果你只做这些很容易在业务题上栽跟头。小红书当时对自己的数据分析岗位定位不是“写数取数的工具人”而是要能理解内容生态、理解用户行为、理解社区氛围的分析师。我当时的理解是内容社区的数据分析师核心任务其实是三件事。第一看懂内容的生产和消费链路比如用户发了笔记、笔记被推荐、被浏览、被互动、被收藏这条链路上每一步都有数据可以拆第二看懂用户分层和生命周期新用户怎么变成活跃用户活跃用户为什么会流失哪些行为信号出现在流失之前第三看懂商业和社区的平衡广告植入会不会伤害社区氛围电商转化和内容消费之间的关系是什么。所以笔试里的业务题不是凭空编出来的基本都围绕这些真实场景。比如给你一张笔记发布表、一张用户浏览表让你分析某个指标为什么下降或者给你一个新功能的上线计划让你设计评估方案。这些都要求你具备“数据感知力”也就是看到一个业务问题时能快速判断应该看什么数据、怎么拆解、用什么方法得出结论。1.2 我考前做的三件事说实话我准备这场笔试的时间不算长大概两周左右但效率还可以。我做了三件事这三件事对后面做题帮助很大。第一件梳理SQL的窗口函数和常用聚合逻辑。内容社区的数据分析大量场景是“每个用户最近一次行为”“每个笔记的累计互动数”“按天去重用户数”这类问题窗口函数几乎是必考的。我当时把row_number、rank、dense_rank、lag、lead、sum over partition by这些全部在纸上推演了一遍确保自己手写也不会乱。第二件把统计学基础过了一遍。重点不是推导公式而是理解每个概念在AB实验里的含义比如P值到底在说什么、统计显著和实际显著的区别、样本量估算受哪些因素影响、辛普森悖论为什么会出现在分层分析里。这些在笔试选择题里出现频率很高而且经常结合业务场景出题。第三件把常见的业务指标体系整理了一遍。我看了很多公开的资料把内容社区的指标分成几层供给端指标发布量、审核通过率、有效内容率、消费端指标DAU、人均浏览时长、人均浏览笔记数、互动端指标点赞、收藏、评论、转发率、互动率、质量端指标举报率、负反馈率、低质内容占比。做完这套整理之后我发现笔试里不管题怎么变底层都是这些指标的组合和拆解。2. 题型结构与在线笔试的答题节奏2.1 整套卷子的结构长什么样2019年这批在线笔试用的是第三方在线笔试系统整个流程是进入系统、调试摄像头、确认信息、开始答题、到点自动交卷。整套卷子我记得大致由四部分组成每一部分的考察重点都不同。第一部分是单选题大概十来道覆盖统计学、概率论、SQL基础、机器学习基础。这里面混合了很多基础概念题比如置信区间的理解、Type I error和Type II error的关系、过拟合的处理方式、什么是梯度下降、常见分类模型的适用场景。整体难度不算大但时间有限不能在一道题上耗太久。第二部分是SQL编程题一般会给两三张业务表要求写SQL查出指定结果。这个部分很考验临场手写能力因为在线笔试的SQL编辑器没有补全也不能调试写错了只能硬着头皮继续。我当时最大的感触是平时用IDE写SQL习惯了到了纯手写环境连select的拼写都要小心。第三部分是业务案例分析题一般会给你一个具体业务场景和一段数据描述让你分析原因、给出建议。这个部分是整场笔试的区分度所在也是小红书这类业务导向型公司最看重的部分。第四部分是开放题通常是一道或者两道没有标准答案考察的是你的产品感、逻辑思维和表达方式。比如让你设计一个指标来衡量某个新功能的效果或者让你估算某个城市的某种商品市场容量。2.2 时间分配和做题顺序在线笔试的时间一般控制在90分钟到120分钟之间小红书这批我记得是90分钟。90分钟要做完选择题、SQL题、案例题和开放题时间其实很紧。我的策略是先把所有选择题快速过一遍会的立刻选拿不准的先标记不犹豫控制在30分钟以内。然后把SQL题放在第二位做因为这类题只要你思路对了答案就是确定的拿分比较稳。接着做业务案例分析题这道题需要写比较多文字至少留出20分钟。最后做开放题不要追求完美把框架搭清楚、逻辑写明白就可以。如果你做题顺序反过来先啃开放题很容易导致选择题没时间做而选择题恰恰是相对容易拿分的部分。在线笔试不光是考你会不会还考你在有限时间内的取舍能力。2.3 在线笔试系统需要注意的细节在线笔试和纸质笔试最大的区别就是你的一举一动都可能被记录下来。我那次笔试要求开摄像头系统会监测切屏行为如果你切到别的页面超过一定次数可能会被标记为作弊。所以考前一定要把其他应用关干净尤其是微信、QQ、浏览器那种可能自动弹窗的软件。还有一个小细节输入法。如果笔试系统里的输入框不支持某些字符或者你的输入法处于中文状态写SQL的时候分号、括号、引号就可能变成全角字符导致编译错误。我当时特意把输入法切成英文模式并且写代码的时候留意标点符号。这种低级错误一旦出现整道题可能一分都拿不到非常可惜。3. 核心考点逐项拆解不只是SQL3.1 SQL与取数从“会写”到“写得对”SQL在数据分析笔试里的地位不需要我多说。但很多人忽略了一个问题笔试里的SQL题考的不只是你能不能写出来而是你能不能写得对、写得严谨。举个例子我当时遇到的场景大致是这样的有两张表一张是用户注册表记录用户ID和注册日期一张是用户浏览记录表记录用户ID、浏览日期和浏览内容ID。题目要求统计每个注册日期的用户在注册后7天内的活跃率。看起来很简单但里面有三个坑。第一个坑是“7天内”怎么定义。如果用户注册日期是第0天那第7天算不算是按日期差小于等于7还是按自然周题目通常会用文字说明但如果你没注意默认取数口径就会错。第二个坑是去重问题。一个用户一天可能有多条浏览记录计算活跃用户数时必须对用户ID和日期去重否则活跃率会偏高。第三个坑是关联方式。如果你用内连接就会把没有活跃行为的注册用户丢掉算出来的活跃率虚高正确做法是先取注册用户集合再用左连接把浏览行为匹配上去最后统计有行为的人数占比。我当时写完之后又检查了一遍这三件事去重条件、时间边界、连接方式。这也是我想提醒大家的笔试里的SQL题真正拉开差距的不是会不会用窗口函数而是能不能考虑到边界情况。再分享一个我后来总结的SQL自查清单第一是否清楚表之间的关联键和关联方式第二是否有需要去重的字段第三时间过滤条件是否和题目口径一致第四聚合函数和group by字段是否完全对应第五结果列的命名是否清晰。这份清单在后来的面试里也帮了我很多次。3.2 统计学与AB实验最容易丢分的地方选择题里统计学占了很大比重而且很多题不是直白地问公式而是包装在业务场景里。比如给你一个实验数据对照组转化率是2%实验组转化率是2.3%样本量各是10万问你这个提升是否显著应该用什么方法检验。这种题考察的是你对假设检验流程的完整理解。首先你需要判断这是比率类指标应该用两比例Z检验其次要注意样本量是否足够大检验的前提条件是否满足再次P值小于0.05只是说明“统计显著”但你还要看提升幅度在业务上有没有实际意义。还有一个高频考点是辛普森悖论。它通常出现在案例题里描述方式是整体上看A组转化率比B组高但按性别分层后每个层里都是B组更高问你为什么会出现这种现象。核心原因是两个组的性别分布差异很大A组女性占比高而女性整体转化率更高所以整体指标被拉高了。这个考点既考统计学知识也考业务分析思维我建议你备考时一定要理解透。我当时在复习统计学的时候没有死记硬背公式而是针对每个概念问自己三个问题这个概念解决的是什么问题、它的使用前提是什么、如果业务场景变了结论会怎么变。这种方式虽然慢一点但应对场景化选择题非常有效。3.3 业务案例分析体现分析思路的主战场业务案例题是我觉得整场笔试里最有含金量的部分。它的典型出题方式是给你一个业务背景比如“最近一个月笔记的日均发布量下降了10%请你分析可能的原因”然后要求你写出完整的分析思路。这种题没有标准答案但阅卷人能从你的回答里看出你是不是一个有分析框架的人。我当时把回答拆成了四个层次数据确认、维度拆解、原因假设、验证方案。数据确认是第一层也是最容易被忽略的一层。很多同学一上来就分析原因但发布量下降这个问题首先应该做的是确认数据口径是否变化比如是不是统计逻辑出了bug、是不是有渠道来源的异常波动。这个步骤在真实工作中非常重要因为很多时候所谓的“指标异动”其实是数据口径不一致造成的乌龙。维度拆解是第二层。发布量下降可以从内容类型维度拆看图文、视频、不同品类是否都下降了可以从用户维度拆看是新用户发布减少还是老用户发布减少可以从时间维度拆看是持续下降还是某一天突然下降。拆完之后问题的方向会变得更加清晰。原因假设是第三层。基于拆解结果提出几个最可能的原因假设比如某个流量入口调整导致新用户减少、某个创作活动结束导致老用户积极性下降、竞品分流导致用户时间被抢占等。每个假设都要对应到可验证的数据指标。验证方案是第四层。针对每个假设写出你会看什么数据、用什么方法验证。比如验证流量入口的影响可以看各渠道新增发布用户数的变化验证活动影响可以看活动参与用户的发布量变化趋势。这一层最加分因为它体现了你“能用数据解决问题”的能力而不是停留在空谈。4. 开放题与产品Sense拉开差距的部分4.1 开放题的回答框架开放题往往是最后一两道题也是最让考生头疼的部分因为完全没有标准答案。我当时的经验是开放题考察的不是“正确答案”而是你的思维框架和表达能力。比如一道典型的开放题如果小红书要推一个新的创作者激励功能你会如何评估这个功能的效果拿到这种题千万不要直接写“看DAU”那太初级了。你需要搭建一个完整的评估体系。我一般会这样展开先明确功能的核心目标是激发创作、提升优质内容供给然后拆解成结果指标、过程指标和护栏指标。结果指标包括优质笔记发布量、有效创作者数量、内容消费时长等过程指标包括创作者参与率、激励任务完成率、素材使用率等护栏指标包括低质内容占比、用户举报率、社区氛围评分等。接着写评估方法可以用AB实验将创作者随机分成实验组和对照组对比核心指标同时要注意实验周期要覆盖一个完整的创作周期。最后还要给出数据回收和决策标准比如“实验组优质笔记发布量提升5%以上且低质内容占比不增加就认为功能有效”。这样的回答展示的是你完整的分析思维链而不是零散的灵感。4.2 数据敏感度和量级估算开放题里还会出现一类估算题比如估算一个城市有多少家咖啡馆、某个平台一天的笔记浏览量是多少。这类题考察的是数据敏感度和逻辑推理能力。做估算题的方法是先设定清晰的假设再逐层拆解。以估算某城市咖啡馆数量为例我会先估算城市常住人口然后按人口分层估算咖啡消费人群占比再估算日均咖啡消费频次接着按单店日均接待能力算出所需门店数最后用行业常识校验结果是否在合理区间。这类题目的关键不在于结果准不准而在于你的推导过程是否合理、假设是否明确。我当时在回答里会刻意把每步假设都写出来比如“假设该城市常住人口500万”“假设白领和大学生是咖啡消费主力占比30%”让阅卷人看到我的思考路径。即使最终结果和实际误差很大但只要逻辑自洽也能得高分。5. 复盘与避坑我踩过的坑和别人的教训5.1 在线笔试常见意外我在准备这篇复盘的时候特意回忆了那次笔试前后的一些小插曲也问了当时一起笔试的几个朋友大家踩过的坑还真不少。第一个坑是设备问题。在线笔试对浏览器版本和摄像头有要求有人因为用的浏览器不兼容进入系统之后一直黑屏最后不得不临时换机器白白浪费了十几分钟。建议提前一天做设备测试把摄像头、麦克风、浏览器、网络都检查一遍。第二个坑是网络不稳定。笔试过程中如果断网系统可能会自动交卷或者丢失已答内容。我当时特意选了一个网络稳定的地方并且把手机热点作为备用。当然用手机热点的时候要注意如果电脑和手机连着同一个Wi-Fi断网之后热点也不一定有用最好用不同的网络来源。第三个坑是时间管理失控。我有个朋友在业务案例题上写得特别投入洋洋洒洒写了一大篇结果最后开放题只写了一行。这就是典型的“捡了芝麻丢了西瓜”。笔试的时间分配不要靠临场感觉提前就要做好规划选择题要控制时间简答题不要过度展开。5.2 常见扣分点和自查清单根据我后来的复盘和自己给别人做模拟面试的经验我总结了一份数据分析笔试自查清单主要在交卷之前对照着检查一遍检查项常见扣分点解决方案SQL题未考虑去重、时间边界理解错、内连接误用按自查清单逐项核对表间关联、去重字段、时间口径统计题P值理解错误、忽略检验前提条件复习假设检验流程理解逻辑而非背结论案例题没有数据确认、未拆维度、只给原因不给验证方法套用“数据确认-维度拆解-原因假设-验证方案”框架开放题只写结论不写推导、无假设、无分层明确假设逐步推导给出可量化的决策标准整体卷面回答格式混乱、字段命名不清统一格式公式和变量命名保持前后一致扣分往往发生在细节上。比如SQL题里很多人会忘记题目问的是“日均”而不是“总量”少写了一个除以天数整道题的结果就错了。再比如统计题里很多人会把“统计显著”和“业务显著”混为一谈看到P值小于0.05就开始说效果好忘记看提升幅度。还有一点我想特别提醒在线笔试里的文字题一定要分点作答不要写成一大段。阅卷人扫一眼能不能看到你的逻辑框架直接决定了你的得分上限。我自己的习惯是每个关键结论都单独成行用“结论原因验证方法”这种三段式结构尽量让思路一目了然。5.3 考后复盘比分数更重要笔试结束之后不管感觉好不好我都建议做一次完整复盘。把每一道题的类型、当时的思路、卡住的位置记录下来然后对照答案或者找朋友讨论找到自己的薄弱点。我当时复盘完之后发现自己最大的问题其实不是SQL也不是统计学而是业务敏感度不够。很多业务场景题我能写出分析框架但假设的部分比较空说明我对内容社区的业务逻辑理解还不够深。后来我专门去研究了内容平台的推荐逻辑、创作者生态、用户分层策略这对我后续面试帮助非常大。如果你也想转行做数据分析或者正在准备校招笔试我建议把每一次笔试都当作一次学习机会笔试的分数只能说明这一次的表现但复盘之后沉淀下来的分析框架才是真正属于你的东西。最后分享一个小技巧准备数据分析笔试不要只看面经一定要自己动手写。SQL要动手敲案例题要动手写出来开放题最好限时模拟一遍。很多时候脑子觉得“我会了”但真正落到笔尖才会发现很多细节经不起推敲。只有亲手写出来的答案才是真正掌握了的。