小红书数据岗笔试真题复盘：SQL、概率统计与业务分析

1. 2023秋招小红书数据岗第三批笔试整体情况与题型概览先交代一下背景。我是2023年秋招投的小红书数据岗第三批笔试岗位方向偏数据分析base北京。当时投完简历大概过了一周收到笔试通知邮件里没有给太多信息就说“在线笔试请预留2小时”进了系统才知道是分模块限时作答。那批笔试一共四个部分第一部分是行测类的逻辑推理和数字推理大概15道题第二部分是SQL和Python编程题第三部分是概率统计和业务案例分析第四部分是主观题给一个业务场景让你写分析思路。难度整体中等偏上比字节的笔试题量少比美团的题目更偏业务和快手的笔试风格有点像。有一点值得先说清楚小红书的笔试不是所有批次都一样的题。第一批和第二批我听说过一些反馈第二批的SQL题偏难重点是窗口函数和复杂join第三批反而更重业务思维。这也在意料之中数据岗笔试向来是这样——考察的是候选人能不能用数据和业务对话而不只是写代码。所以我建议后面要投小红书数据岗的同学别只闷头刷LeetCode和SQL题业务题的分析框架才是拉开差距的地方。2. 六道核心真题复盘SQL、Python与概率统计2.1 SQL题围绕内容社区的互动数据出题窗口函数跑了三连问第三批笔试的SQL题我记得很清楚是围绕小红书的“笔记-用户-互动”数据模型出的。题目大概是这样的有三张表一张是笔记维度表笔记id、作者id、发布时间、类目一张是互动行为表用户id、笔记id、行为类型、时间戳一张是用户维度表用户id、注册时间、手机品牌。三道小题分别是第一问统计每个类目下近30天有互动行为的笔记数以及这些笔记的人均互动次数。第二问找出每个类目下互动次数排名前10的笔记并输出对应的作者id。第三问统计发布后24小时内互动次数超过100的笔记中作者的手机品牌分布。这三问其实是层层递进的。第一问是基础聚合用count(distinct)和sum配合case when就能解第二问是典型的窗口函数row_number()或者rank()按类目分区、按互动次数排序第三问要先把时间差算出来再关联用户表取手机品牌。我当时的解法是第一问用left join把笔记表和互动表关联起来注意要限定互动时间在发布后30天内避免把发布前的记录也算进去。这里其实有个坑互动行为发生在笔记发布前是不可能的但数据清洗不到位时会有脏数据所以建议加一个where条件把时间差为负的记录过滤掉。第二问的SQL写起来也很常规但要注意“互动次数前10”在并列情况下怎么处理——如果用row_number()并列时会随机截断如果用rank()可能出现超过10条的情况。我选了rank()然后在评论区标注了并列处理的逻辑后来复盘觉得这个细节应该是加分项。第三问是我做得最纠结的一道。它要求“发布后24小时内互动次数超过100”我当时写的是先按笔记id做聚合只保留count(行为) 100的笔记再left join用户表取手机品牌。但是我当时犹豫的是要不要限定行为时间戳在发布后24小时内需求描述里写的是“发布后24小时内互动次数超过100”那当然应该限定。所以我又加了一个case when表达式让时间差小于86400秒才计入互动次数否则记为0。这题的考察点其实是审题而不是SQL本身的难度。提示小红书的笔试SQL题都在他们自己的在线编辑器里跑不提供真实数据只校验结果集。所以练习的时候不要再依赖本地数据库环境多用Hive或Spark SQL的语法练习因为他们的编辑器对标准SQL的支持比较有限特别是limit语法的位置和substring函数的下标和MySQL有差异。2.2 Python编程题数据清洗和外呼触达模拟幂等设计是隐藏考点Python题有两道。第一道是给了用户行为日志要求写一个函数输入是原始日志列表输出是清洗后的结构化数据。具体清洗规则包括去掉时间戳为空的记录、去重同一用户在同一秒内的重复行为只保留一条、并把行为类型里的英文标签映射成中文。这道题本身不难就是常规的pandas处理但题目要求用纯Python实现不能用pandas几个候选人出来之后对这题的反馈都差不多——不让你用pandas这件事本身才是真正的考点。我当时的思路是先用defaultdict按用户id把日志分组再对每个分组内部做时间排序和去重。去重逻辑用了一个set来存“用户id时间戳行为类型”的复合key这个方案在哈希冲突率上表现还可以但有个问题是内存占用偏高。后来想了一下其实数据量是可控的这种简单方案完全够用。需要注意的一点是题目里的时间戳是带时区的ISO格式字符串直接用字典去重时如果时区不统一会有问题所以我在解析时统一转成了UTC时间再格式化。第二道Python题更有意思模拟的是外呼触达。场景是平台需要对一些低活跃用户做push触达触达策略是按用户活跃度分为A、B、C三档不同档位有不同的触达次数上限和间隔要求。要求写一个调度函数输入是所有需要触达的用户列表和他们的活跃度档位输出是一份可执行的触达计划表约束是同一用户两次触达之间的间隔必须超过规定值。这道题的本质是一个资源调度约束问题。我一开始用贪心算法写按用户分组然后每个用户的触达时间点按档位间隔均匀排开。写成代码之后发现边界条件很多比如用户可触达的时间窗口是早上8点到晚上10点跨天之后间隔怎么算C档用户隔了3天之后如果落在周末要不要跳过。我当时的方案是引入了一个next_available_time字典每次排完一次触达就更新用户的下次可触达时间按时间线循环扫描。这样做能通过基本用例但时间复杂度偏高如果用户量再翻十倍可能会卡。后来复盘的时候我想到了幂等设计这个隐藏考点。题目虽然只要求输出触达计划但如果触达链路里出现了重复调用你把同一用户在同一个时间点排了两次生产上就是一次资损事故。所以我在答案结尾加了一个去重断言保证输出计划表里不存在同一个用户同一个时间戳的两条记录。这是真实业务里必须考虑的问题笔试考这个比单纯考算法要贴近实战得多。2.3 概率统计题三门问题变体和置信区间计算笔算是最大障碍概率统计部分一共三题我印象比较深的是两道。第一道是经典的三门问题变体有三个盒子一个盒子里面有两个红球一个盒子里面有两个蓝球一个盒子里面是一红一蓝。随机摸出一个盒子再从中摸出一个球发现是红球问这个盒子是“两个红球”的概率。这题不是标准三门问题而是贝叶斯推断。标准的解法是设事件A为选中双红盒事件B为摸出红球。P(A) 1/3P(B) (2/3) * 1 (1/3) * 1/2 5/6。其实仔细算一下是对的——双红盒摸出红球概率为1双蓝盒为0一红一蓝盒为1/2。然后P(A|B) P(A) * 1 / P(B) (1/3) / (5/6) 2/5。按这个思路把实际数字代进去P(A|B) (1/3) * 1 / 5/6 2/5所以答案是0.4。这个结果如果只背公式不看条件很容易算成1/2我估计很多候选人就栽在这里。当时我在草稿纸上验算了一遍这个条件概率才填的答案后来跟一起笔试的同学对答案有人就直接写了0.5这就是典型的没有理解“摸出红球”这个证据对先验概率的修正作用。第二道题是给了一组用户次日留存率数据共30天均值为40%样本标准差是5%要求计算总体均值的95%置信区间。这个直接用t分布或者正态近似算就行n30可以用t分布的临界值2.045也可以用z分布的1.96近似题目没有给t分布表直接用1.96也不会被算错。算出来区间大概是[38.21%, 41.79%]。我在这道题上花的时间比预期多因为要在网页表单里手算没有一个像样的计算器一个小数点错了就全错。我的经验是这种题先把标准误算出来样本标准差除以根号n再乘临界值最后再跟均值做加减分步写在草稿纸上可以明显减少计算失误。3. 业务案例分析题答题框架、我的答卷与复盘反思3.1 “笔记搜索无结果”问题怎么拆解归因怎么设计漏斗这部分有一道题是小红书App内搜索一个关键词发现搜索无结果的比例连续三天上升从3%涨到5%如果你是负责搜索业务的数据分析师你会怎么分析这个问题要求给出分析框架和落地步骤。这道题没有标准答案但踩分点非常明确。我当时是有意识地把归因分成两个方向去写的一个方向是供给问题另外一个方向是匹配问题。这两个方向的差别是供给问题是指搜索词对应的笔记确实不存在或者数量太少无法展示匹配问题是指站内明明有相关内容但因为召回或者排序的链路出了问题导致结果集为空或者被过滤掉。在供给方向上我写了三个子假设第一是搜索词本身是长尾词笔记库中匹配文本内容的笔记确实很少第二是搜索词背后对应的品类近期有供给流失比如某个头部创作者停更导致该关键词下的笔记密度显著下降第三是搜索词的热度骤增比如某条热点新闻带火了一个生僻词用户集中搜索但站内供给没跟上。在匹配方向上我的子假设包括搜索引擎的Recall阶段如果最近上线了新模型或者改了词权重可能导致部分词匹配不上索引平台策略上如果近期调整了审核过滤规则一些带有特定词汇的笔记被过滤进入不了搜索结果也会表现为无结果率上升还有一个容易被忽略的点是query分词的问题同一个词在不同版本上的分词策略如果发生变化结果集会完全不同。然后我补了一个验证顺序的思路先看变化是平台整体性的还是场景局部性的。如果整体上升优先查引擎配置和策略变更如果只是部分渠道或者部分版本上升优先查版本差异和用户画像差异。同时在验证时区分新老用户因为老用户的历史搜索行为会给个性化排序提供更多信息新用户搜索无结果中的“无”很可能是真的供给不足。3.2 我当时的分析框架拆解拆到策略层再往技术层收下面把我当时写到答卷上的内容整理一下给出一个可以直接套用的分析框架。这个框架不仅适用于搜索无结果任何指标异动分析都可以用类似的思路。第一定义问题口径。无结果率的分母到底是总搜索次数还是去重后的搜索词数还是只统计有结果的搜索词这三种口径下数据可能差两三倍。如果这个指标是最近才接的新口径可能根本不是业务变动而是数据口径变了。我在笔试里写了“先检查指标口径是否一致”这既是表态度也是给后续的所有分析步骤做铺垫。第二趋势分层拆解。把无结果率分成新词首次搜索无结果和存量词搜索无结果。存量词无结果是更严重的问题因为它代表原本能搜到的东西现在搜不到了。如果只有新词无结果率上升大概率是热点事件带来的新词供给缺失处理优先级较低如果存量词也在上升就要马上排查引擎链路。第三归因交叉验证。用维度拆解和假设验证结合维度包括版本客户端版本、搜索引擎版本、渠道首页搜索、顶部搜索、搜索联想词跳转、类目视频类、图文类、用户层级新老用户、活跃度。每个维度上对应上面的子假设做验证比如“策略变更”假设可以通过对比上线前后的数据变化来验证。第四和产品、算法、运营的对齐动作。数据侧先产出归因结论再把建议同步给搜索策略团队做case抽取给内容运营团队看是否需要补充供给。我在复盘后发现这类题目考官真正想看的不是你能排查得多深而是你有没有从数据结论走到业务动作的意识。很多候选人写了十几条分析维度但就是没有“找谁去落地”的部分分数就上不去。3.3 主观题里隐藏的商业sense考察不是数据分析题是产品运营题笔试最后还有一道大主观题题目大概意思是小红书最近发现收藏量很高但点赞量偏低的笔记类型让你分析背后的用户动机并提出运营策略。这道题猛一看像内容分析题其实是一道产品运营题。我当时写了三层理解。第一层是数据表现上的原因收藏是一个“高成本、高意图”的行为用户收藏笔记往往是为了之后回看比如攻略类、教程类、清单类的内容天然具备高收藏低点赞的属性这是内容品类属性导致的。第二层是用户状态的差异点赞是即时的情绪反馈收藏是延迟的需求沉淀。如果一类笔记的收藏远高于点赞说明用户需要它但不是现在马上需要它可能非常实用但不那么“上头”。第三层是可以引导的产品策略在收藏后的回访路径里加一个轻量互动引导比如“这篇笔记帮到你了吗”或者分享一个整理好的收藏夹给关注者让收藏行为之后能够自然转化为点赞和关注。这道题我在复盘时意识到自己答得中规中矩虽然思路完整但缺少一个亮点——运营策略里没有提到创作者侧的正反馈闭环。正确的做法应该强调收藏率高的笔记创作者得到的反馈是“延时的、不明显的”所以他们可能并不知道自己发的内容到底有没有用应该把收藏回访率、收藏转赞率这类数据指标也返还给创作者让创作者感知到内容价值。这个角度如果能在笔试里写出来会明显区别于其他人。4. 从笔试看秋招数据岗的准备逻辑踩坑与建议4.1 时间分配失误我在概率统计题上超时导致主观题仓促我这次笔试最大的失误是时间分配。全程120分钟我大概用了35分钟做行测45分钟做SQL和Python这个节奏本来是适应的。但概率统计的那三道题我花了差不多25分钟尤其是那个贝叶斯和置信区间笔算的时候特别容易卡顿写写划划就过了二十多分钟。等到最后看到那道大主观题时只剩不到15分钟我几乎是用了最快的速度在打字但答完回头看论述的深度和层次感明显不如前面做得从容的那些题。现在复盘正确的时间分配应该这样行测控制在25分钟内不会的题直接蒙一个别再回头SQL和Python控制在40分钟内因为这部分只要会写基本就能过耗时间的点主要在于调试概率统计控制在20分钟内实在算不出来的先跳过别恋战主观题至少留30分钟因为这部分分值是最重的而且阅卷的差别感往往体现在这里。笔试的时候时间进度条是在页面上方的我建议每做完一个模块就低头看一眼时间比在心里估算要准得多。4.2 常见备考误区和取舍建议SQL刷题之外业务sense才是分水岭我见过很多人准备数据岗笔试就只刷SQL题和Python题算法题刷得不亦乐乎结果一到业务案例题就懵住。小红书的数据岗笔试其实传递了一个很明确的信号SQL和Python只是基本功这些题大家都能拿分真正区分度高的题目永远是业务分析题和主观题。2023年秋招小红书数据岗笔试整体比前一年更偏业务我认为这个趋势在未来一两年内不会改变。我建议备考时分三个阶段来准备。第一阶段是扎实SQL基本功特别是窗口函数、多表关联、去重逻辑和子查询不用追求太难的优化但凡是笔试出现的SQL题都能第一眼看出思路。第二阶段是搞懂概率统计的基础概念贝叶斯公式、置信区间、假设检验、常见分布这些都能用自己的话解释清楚并且能做手算练习。第三阶段是业务案例积累去把真实产品里可能出现的指标异动、实验评估、画像分析、策略归因这四类场景各准备一套分析框架每种场景自己动手在纸上写一遍答题结构然后找一个朋友互相批改或者拿小红书的真题来演练。我个人不太推荐为了笔试去背大而全的面经那些整理出来的两百道题里至少有一半是不常考的。更有效的做法是准备一个自己的“分析模板库”每个模板包含“问题拆解方法”“分析维度枚举”“验证步骤”“落地动作建议”这四个板块遇到任何业务题都往这个框架里套再根据具体场景做调整。这个方法我在后续其他公司的面试里也用了效果比临时起意的答题方式好很多。4.3 关于小红书数据岗投递我自己踩过的一些真实细节有几个笔试之外的细节也值得拿出来说一下。第一是笔试链接的邮箱一定要检查垃圾箱我当时就是在垃圾箱里翻到的笔试通知差点错过48小时内的考试窗口。第二是笔试过程是全程录屏监控的浏览器不能切换页面最好提前把本地代码编辑器关掉只留一个浏览器窗口。第三是小红书笔试题目可以往回翻但每个模块的倒计时在进入时就开始走了我当时不知道这一点在模块一的行测上浪费了不少时间导致后续模块的节奏全乱。还有一个细节是关于简历的。因为小红书数据岗的简历筛选比很多公司要严格我当时是等了一个多星期才收到笔试邮件一度以为简历挂了。如果你的简历里有一段和内容社区相关的项目经验被捞起来的概率会大很多。我在项目一栏写了一个关于内容消费行为分析的小项目用的是爬虫获取的公开数据但这里我不建议任何人去绕过平台限制采集数据更好的方式是用平台提供的开放数据接口或者用公开数据集做分析。GitHub上确实有很多数据岗笔试的复盘仓库去翻一翻小红书的真题回忆贴再对照自己的薄弱点做针对性训练比闷头刷题效率高很多。4.4 这类笔试背后的考察逻辑数据岗不只找“写SQL的人”最后再聊一个复盘时才想通的点。小红书数据岗笔试考了那么多代码和统计但打分权重最高的其实是那两道主观题和业务案例题原因在于数据岗在业务团队里的角色是“用数据推动决策”而不只是“把数据取出来给产品看”。秋招进来的应届生SQL写得再快业务sense不够在团队里其实是跑不动的。所以如果你问我第三批笔试到底难不难我的回答是SQL和Python的部分任何一个认真刷过题的人都能过概率统计的部分学过概率论但基础不牢的人会丢分真正把分数拉开的是业务案例和主观题这个没办法靠刷题速成需要在平时就有意识地训练自己看数据的角度——看到一个指标波动先问自己三个问题这个数字是怎么算出来的这个数字变了说明什么这个数字变了之后应该谁来做什么。能把这三个问题想明白笔试的主观题基本就能稳稳过线了。我当时在主观题部分写了收藏和点赞的分析思路但写得并不算好。如果让我重来一次我会把回答的结构改成先判断数据可信度再拆解内容品类特征和用户动机最后落到创作者激励策略和产品功能优化上每一步都用一小段话说清楚背后逻辑。这种结构化的答题方式远比堆砌各种分析维度更能让阅卷人看出你的思路。