2023秋招小红书数据岗笔试复盘三种题型两套解法一份完整破题思路每年秋招数据岗笔试都是刷人最狠的一关。尤其是大厂的数据分析、数据科学类岗位投递人数多、岗位名额少笔试题目往往不是单纯考“会不会”而是考“在有限时间内能不能做对、能不能做成”。小红书2023年秋招数据岗第三批笔试整体给我的感觉是题型不算偏但覆盖范围很广从SQL到概率统计从业务case到机器学习基础都有涉及而且部分题目很考验业务sense和临场反应。这篇文章我以自己的复盘为主线结合同批次同学的反馈把这场笔试的题型结构、考察重点、解题思路、踩坑点以及针对性的备考方法一次性整理清楚。如果你正在准备互联网大厂数据分析/数据科学岗位的秋招、春招或者打算投小红书的数据岗这篇内容可以直接当成模拟练习的参考。1. 笔试整体结构与考察方向拆解先说结论小红书数据岗第三批笔试整体分为三个模块——SQL与数据处理、概率统计与机器学习基础、业务案例分析。三个模块之间的分值占比并不是平均分配从我所在批次和同批同学反馈来看业务案例分析占比最高其次是SQL概率统计和机器学习基础相对少一些但容错率低错了很伤。这个结构很符合小红书这类内容社区产品对数据岗的要求不只要会写SQL取数更要能结合业务场景看懂数据背后的逻辑能通过数据判断产品问题和机会点。笔试本质上就是在模拟“入职后日常要做的三件事”取数、分析、做决策建议。每个模块的考察形式和核心能力指标可以看下面这个表模块主要题型考察核心建议用时SQL与数据处理2~3道SQL编程题取数逻辑、多表关联、窗口函数、数据清洗30~40分钟概率统计与ML基础选择题简答概率计算、假设检验、常见机器学习概念20~30分钟业务案例分析1~2道综合case指标体系、异动分析、AB实验设计、策略建议40~50分钟从整体时间安排来看笔试总时长大约在90~120分钟题量不算巨大但每道题都需要深入思考。很多同学觉得时间不够其实是卡在SQL题上——为了追求“最优解”反复修改导致后面业务case时间被压缩这是最不划算的。后面我会专门讲时间分配的策略。1.1 为什么小红书会这样设计笔试拆解笔试结构之前先理解“为什么这么考”比“考什么”更重要。小红书的数据岗属于典型的“业务型数据岗”日常工作大量涉及内容推荐、用户增长、商业化变现、社区治理这几个方向。这就决定了笔试必须重点考察三个能力第一是数据处理能力。社区产品每天产生海量用户行为数据包括笔记浏览、点赞收藏、评论、关注、搜索、下单等。数据岗的第一课就是能高效准确地拿到数据SQL写不熟后面的分析全是空中楼阁。第二是量化分析能力。无论是评估一次推荐策略改版的效果还是判断某个增长活动的ROI都需要扎实的概率统计和AB实验知识。这部分题目往往以业务场景为外壳考的是能否把业务问题转化为统计问题。第三是业务理解能力。数据岗不是纯技术岗尤其在内容平台数据结果必须转译成可执行的业务建议才有价值。笔试最后的大case就是在模拟这个场景给你一堆数据背景和业务现象让你发现问题、拆解原因、提出下一步动作。理解了这层逻辑你就明白备考的重点不是“刷很多题”而是“带着业务视角去练每个知识点”。1.2 三个模块的评分权重与通过门槛关于评分权重官方不会公布具体比例但从笔试结果和面试邀请情况可以反向推断三个模块不是简单加总排名而是有基本门槛的。SQL模块如果出现严重错误比如表关联逻辑搞错、结果完全不对大概率直接挂业务case如果有分析框架但结论不落地可能还能进面但如果case完全没思路或者答非所问基本也没戏。换句话说SQL是你的底线业务case是你的上限概率统计和机器学习是区分度所在。这三块缺一不可但投入产出比不一样。时间有限的情况下优先拿稳SQL和业务case的大头分再在统计ML部分争取少丢分是性价比最高的策略。2. SQL与数据处理模块不止考语法更考取数思路小红书数据岗笔试的SQL题整体难度属于中上。和牛客网上常见的纯语法题不同这里的SQL题往往嵌套在一个具体业务场景里需要你先理解业务需求再转化成取数逻辑。比如“统计近30天发布笔记的用户中有多少人同时产生了搜索行为”“计算每个笔记分类下的互动率中位数”这类题目看似简单实则包含了很多隐含条件需要处理。2.1 三类必考的SQL题型结合我和同批同学的回忆小红书这批笔试的SQL题主要集中在三类第一类是常规取数与多表关联。比如给笔记表、用户表、互动表要求统计某时间窗口内每个分类下的发布量Top10用户。这类题不难但很考验对表结构的理解能力和关联条件的准确性。我见过不少同学在这里犯低级错误join条件少了字段或者在where里过滤了本该在on里过滤的条件导致数据结果偏差。第二类是窗口函数与排名计算。比如计算每个用户最近一次发布笔记的日期、按时间顺序给用户行为打标、计算滞留率/复购率等。这类题要求熟练使用row_number()、rank()、lag()、lead()等窗口函数。这里有个关键技巧窗口函数是在where和group by之后执行的所以如果你想先过滤再排名顺序一定要写对否则结果会完全错误。第三类是数据清洗与格式处理。比如处理时间戳格式、解析JSON字段、正则匹配提取文本特征等。这类题在笔试中不一定单独出现但会嵌入到前面两类题中作为前置步骤。小红书这类内容平台行为日志大多有丰富的属性字段清洗能力是基本功。2.2 一道典型的SQL真题与完整解法为了让大家更直观感受题目难度我复现一道当时印象比较深的题题目细节做了脱敏处理但考察逻辑是一样的给定一张笔记互动表note_interact和一张用户关注表user_follownote_interact包含字段note_id笔记ID、user_id用户ID、interact_type互动类型view/like/comment/favorite/share、interact_time互动时间。要求统计2023年9月1日到9月30日期间每个用户对“未关注作者发布的笔记”产生的“已读互动”like/comment/favorite/share次数并按次数降序输出Top100用户。这道题的难点在于“未关注作者”这个条件。正确思路是先找到互动行为发生之前用户是否关注了笔记作者。如果直接用user_follow表去left join再过滤null值会有一个隐患——用户可能在互动之后才关注作者这样会被误判为“未关注”导致统计不准确。我当时采用的解法是先按用户和笔记作者建立关注关系时间表然后关联互动表时用互动时间与关注时间做比较只有关注时间为null或关注时间晚于互动时间的情况才计入“未关注”。这个逻辑写起来稍复杂但业务语义是准确的。笔试中不一定要求到这个精细度但如果你能在答案里体现这层思考面试官会看到你的业务敏感度。SQL写法大致如下with follow_rel as ( select user_id, author_id, min(follow_time) as first_follow_time from user_follow group by user_id, author_id ) select t.user_id, count(*) as interacted_cnt from ( select n.user_id, n.note_id, n.interact_type, n.interact_time, f.first_follow_time from note_interact n left join follow_rel f on n.user_id f.user_id and n.author_id f.author_id where n.interact_time between 2023-09-01 and 2023-09-30 and n.interact_type in (like, comment, favorite, share) ) t where t.first_follow_time is null or t.first_follow_time t.interact_time group by t.user_id order by interacted_cnt desc limit 100;理解这段SQL的关键在于子查询里同时保留了互动时间和首次关注时间然后在外层统一过滤。这样就能精确计算出“互动时还没关注”的行为。我在笔试里甚至会在注释里加一句说明解释为什么要用first_follow_time而不是直接join这个细节是可以加分的。2.3 SQL题的高频失分点从我自己和身边人的教训来看SQL题失分通常不是因为不会写语法而是因为没想清楚业务语义。常见的有三类关联条件少写了导致数据膨胀、时间窗口边界没处理导致多算或少算一天、去重逻辑没考虑导致用户或笔记重复计数。时间边界问题尤其容易忽略。比如题目说“9月份的数据”到底是包括9月1日00:00:00到9月30日23:59:59还是到9月30日00:00:00如果表里的时间字段精确到时分秒这个边界必须处理干净。行吧你在笔试环境里没法验证数据对错但可以在写SQL时明确写出边界条件让阅卷人看到你有这个意识。另外我建议写SQL的时候一定要先想清楚“结果的粒度是什么”。粒度就是每一行代表什么是“每个用户一行”还是“每个用户-每个分类一行”还是“每一天一行”。想清楚粒度再去写group by和select的字段正确率会大幅提升。这个习惯不只在笔试中有用实际工作中写取数SQL一样受益。3. 概率统计与机器学习基础高频考点与速算方法这一模块是很多人的痛点。说实话小红书这批笔试的概率统计和机器学习题目难度上并没有特别为难人但覆盖面很广选择题尤其考验概念理解的准确性。如果你复习时只是死记硬背公式遇到题目换个说法就会懵。这部分的备考策略应该是核心概念理解透经典题型练到熟公式不必全背但常用的一定要会推导。3.1 概率统计重点看条件概率、贝叶斯和假设检验概率统计的考察重点非常稳定绕不开三类条件概率与贝叶斯公式、期望与方差计算、假设检验与置信区间。小红书作为内容平台推荐系统的AB实验极其依赖假设检验所以假设检验是重中之重。我记得当时有一道题是某个推荐策略改版后点击率从10%提升到了10.5%样本量为每组10万用户问这个提升是否统计显著并解释p值的含义。这种题表面上是在考计算实际上在考你对“统计显著”和“实际显著”的理解。很多人算出z值后直接判断“显著”却忽略了业务上0.5个百分点的提升是否值得全量上线这其实才是出题人想要区分的点。条件概率类的题也常考而且通常会包装成“垃圾内容识别”“用户流失预测”等业务场景。解题关键是画清晰的事件关系图用贝叶斯公式展开时不要漏掉先验概率。这里有一个实用的速算技巧遇到“已知A条件下B发生的概率”这类问题先列表格把样本空间划分清楚再代入公式不容易出错。3.2 机器学习基础重点看评估指标和常见模型原理机器学习基础部分的考察深度大概在“校招笔试平均水平”左右不会让你手推复杂的梯度公式但常见模型的原理、适用场景、优劣势必须清楚。尤其是分类模型的评估指标几乎是必考的。准确率、精确率、召回率、F1、AUC、ROC曲线这些基本概念要烂熟于心并且要能结合具体场景说清楚该用哪个指标。比如在小红书的笔记推荐场景里用户看过的笔记中真正感兴趣的其实很少正负样本极不平衡这时候准确率就没什么参考价值应该关注召回率和AUC。题目如果问“某场景下应该优化哪个指标”你需要结合业务背景去回答而不是机械地背定义。常见模型方面线性回归、逻辑回归、决策树、随机森林、XGBoost、K-Means、PCA这些是高频考点。要能说清楚逻辑回归和线性回归的区别、决策树的分裂依据、K-Means的K值选择、PCA降维的原理。我当时遇到的一道选择题是关于XGBoost和随机森林的区别选项里混杂了“bagging vs boosting”“样本采样方式”“特征采样方式”几个维度如果你对集成学习的基本框架不够熟很容易混淆。这里可以记住一句话随机森林是bagging思路并行训练多个独立树XGBoost是boosting思路串行训练每棵树学习前一棵的残差。3.3 这部分题目的做题策略概率统计和机器学习的题目我个人的建议是“不要恋战”。选择题如果30秒内没有明确思路先标记跳过最后有时间再回来算。因为这类题往往是一道一道独立计分不会因为前面的题没做就影响后面的评分与其卡在一道计算量很大的概率题上不如把时间留给后面分值更高的业务case。但有一个例外如果是简答题哪怕不会完整解答也一定要写思路。把你已知的公式、假设、推理过程写出来让阅卷人看到你的分析框架。在实际工作中数据岗遇到不确定的问题是很常见的能不能“在不确定性中推进”本身就是考察能力的一部分。笔试答卷也一样展示你的思考过程比给出一个完美的最终答案更重要。4. 业务案例分析模块真正的区分度所在业务案例分析是小红书数据岗笔试的重头戏也是最难临时抱佛脚的部分。它的考察形式通常是给你一段业务背景描述再附上一些数据表现然后要求你回答“指标异动的原因有哪些”“如何评估某次改版的效果”“你会怎么设计一个增长策略”之类的问题。4.1 业务case的常见出题方向结合小红书自身业务特点这批笔试的业务case主要集中在三个方向第一个是内容生态方向。比如“社区某垂类笔记的日均发布量连续两周下降请分析可能原因”或者“互动率上升但人均观看时长下降说明什么”。这些问题看似在考数据分析实则在考你对内容平台运转逻辑的理解。第二个是用户增长方向。比如“新用户次留从45%下降到40%请拆解可能的影响因素并给出验证方法”。增长类case是互联网公司笔试的常客因为增长是每个产品都关心的话题而且增长指标的波动可以拆解出很多维度非常适合考察结构性思维。第三个是商业变现方向。比如“广告收入下降如何区分是流量问题还是变现效率问题”。这类题对业务sense的要求更高如果你对广告计费模式、CPM/eCPM这些基本概念不了解很容易答偏。4.2 搭建一套通用的case分析框架面对业务case题目最怕的就是没有框架想到哪写到哪。在笔试这种高压场景下一套通用的分析框架能帮你快速组织思路也能让阅卷人清楚地看到你的逻辑层次。我当时采用的是“定义问题—拆解指标—排查原因—给出建议”四步法。第一步明确要分析的核心指标是什么什么波动算异常第二步把核心指标按维度拆解通常有“用户维度、场景维度、时间维度、产品维度”几个方向第三步针对拆解出的异常模块逐一排查可能原因并结合数据或常识判断哪些原因最可能是主因第四步针对确认的主因给出可落地的建议注意建议一定要有具体动作和预期效果。举个例子如果题目说“笔记搜索点击率下降”可以这样拆按用户类型拆新用户/老用户、活跃/沉默、按内容类型拆不同垂类、按搜索词类型拆热门词/长尾词、按场景拆不同入口、不同端。然后看哪个细分维度的下降最明显再针对这个细分去排查是供给问题搜索结果变差了还是需求问题用户搜的词变了还是产品问题排序策略出bug了。这个框架的好处是结构化不管题目背景怎么变都能套进去。4.3 如何在case题中展现业务sense框架是骨架真正让答案出彩的是框架里填充的业务洞察。这个很难短期速成但有几个技巧可以快速提升答案的“业务味”。多使用业务指标而不是泛泛描述。比如回答“用户活跃度下降”时不要只停留在“日活降了”而要说“DAU降了但具体是新用户首日留存降了还是老用户7日活跃降了”把指标落实到具体口径上阅卷人会立刻觉得你有数据思维。多给出验证方法而不是只看表象。笔试case题里你提出的每个原因都最好带上一句“这个可以通过XX数据来验证”。比如你说“可能是推荐内容质量下降导致互动率降低”后面补一句“可以对比改版前后推荐笔记的完播率、收藏率来判断内容质量是否有变化”这样就形成了从假设到验证的闭环这是数据岗最核心的工作方式。多给出分层的解决方案。业务建议不能只有一句话要能区分“立刻能做的”和“需要长期建设的”。比如面对搜索点击率下降短期可以做的有“排查排序策略是否有bug、紧急回滚”等中期可以做的有“优化搜索词的召回策略、调整排序特征权重”长期可以做的有“建设搜索质量监控体系、完善badcase反馈机制”。这种分层回答会让你的答案显得成熟、可落地而不是纸上谈兵。4.4 一道典型的业务case模拟为了更直观地展示完整解题流程这里放一道模拟题题目风格和笔试接近大家可以拿来自测。背景某内容社区App的“关注页”用户查看已关注作者更新内容的页面的次日留存率在过去一个月内下降了3个百分点而同期“推荐页”个性化推荐信息流的次日留存率保持稳定。请分析可能的原因并设计你的验证方案。第一步先定义问题。关注页次日留存下降本质上是用户回访关注页的动力减弱了。关注页的PV和用户数分别是多少次日留存率的口径是什么这些背景条件题目可能没给全但你的分析里要指出“需要先确认数据口径和下降的时间拐点”这本身就是数据分析的起点。第二步拆解指标。关注页次日留存可以按用户维度拆新关注用户vs老关注用户、不同活跃等级、按内容供给拆关注作者更新量、更新作者占比、按产品功能拆是否有点击进详情、是否有互动。其中最关键的是一个特殊比值关注页的“有更新用户占比”——即用户关注的作者中当天有更新内容的比例。如果很多用户关注的作者停更了关注页没有新内容可刷留存率自然会下降。第三步排查原因。可能的假设包括头部作者产出下降或流失、关注关系在弱化用户关注了很多内容创作者但质量不高、产品入口调整导致关注页曝光减少、关注页的内容排序策略变化等。针对每个假设给出验证方法头部作者产出下降可以通过统计头部作者近30天的发布量变化来验证关注关系弱化可以通过计算人均关注作者数和关注页人均曝光量来判断产品入口问题可以通过对比调整前后的入口点击率来分析。第四步给出建议。如果验证后发现是“关注作者更新量下降”导致的短期内可以做的包括对近30天未登录的创作者做召回push、在关注页增加“最近更新作者”的排序权重、引导用户关注更多活跃作者长期则需要建设作者激励体系和内容供给预警机制。这个答案既有数据假设和验证逻辑又有可执行的业务动作就比较接近高分答案的状态了。5. 备考路径与资料清单一个月内如何高效准备笔试经验讲完再聊聊备考。秋招期间时间宝贵大部分人都是边投简历边刷题不可能像考研一样拿出几个月专门准备。但数据岗笔试的题型相对稳定用一个月时间集中突破是完全可以做到有效提升的。关键是路径要对、资料要精、刷题要有方法。5.1 分阶段备考安排第一个阶段第1周以打基础为主。SQL把窗口函数、多表join、group by聚合、时间处理函数等核心语法过一遍做到看到题目能快速反应出用哪些函数概率统计重点复习条件概率、贝叶斯、期望方差、常见分布、假设检验机器学习重点过分类评估指标、常见模型原理和适用场景。这个阶段不用大量刷题以理解和记忆为主。第二个阶段第2~3周进入刷题模式。SQL每天刷3~5道题重点刷牛客网的SQL实战题和互联网大厂历年真题题目做完一定要复盘——不要只看对不对要看有没有更优的写法、有没有漏掉边界条件。概率统计和机器学习选择题每周集中刷2~3套错题整理成笔记搞清楚每个错误选项错在哪里。业务case每天精练1道按照前面说的“定义问题—拆解指标—排查原因—给出建议”四步法写答案。第三个阶段第4周模拟练兵。找2~3套完整的大厂数据岗笔试真题严格限制时间从头到尾做一遍模拟真实考场节奏。这一步非常重要因为平时刷题是“单项训练”完整模考才能暴露时间分配、做题顺序、心态管理这些综合问题。模考完认真复盘哪类题耗时过长哪个知识点还薄弱答题格式是否清晰然后针对性地做最后冲刺。5.2 推荐的备考资料市面上的笔试资料很多但真正高效的是这几类第一类是SQL题目平台牛客网SQL题库和LeetCode数据库题覆盖了大部分笔试SQL题型第二类是统计和机器学习的基础教材和笔记重点看假设检验、AB实验、常见模型对比这几块第三类是业务case的题目集这个比较稀缺可以找大厂数据岗面经和笔经整理也可以找一些专门讲业务分析的课程和公众号文章。特别推荐大家养成整理错题笔记的习惯。笔试备考最怕“一错再错”同一个知识点换个马甲又错了。错题笔记不需要多精美关键是记录三件事错在哪里、为什么错、正确思路是什么。考前快速过一遍错题本比盲目刷10套新题都有用。5.3 针对小红书数据岗的特别准备如果你目标是小红书有几个额外建议。第一多刷小红书App从用户视角理解产品。你发的每一条笔记、每一次搜索、每一个点赞收藏背后都是数据。多观察不同模块的产品形态和内容推荐逻辑对回答业务case非常有帮助。第二关注内容社区领域常见的数据分析思路比如内容分发效率分析、创作者留存分析、社区治理指标建设等。第三面试前了解小红书的业务动态比如社区商业化进展、搜索流量变化、电商布局等这些都可能成为笔试case的背景。我当时在准备阶段每天会花半小时在小红书上浏览“数据分析”相关的博主分享既积累了行业认知也顺带了解了目标公司的内容风格一举两得。6. 常见问题与考场避坑实录最后把笔试中容易踩的坑集中整理一下。这些坑不少是我亲身踩过的也有一些是身边同学的惨痛教训每一条都配了建议希望能帮学弟学妹们少走弯路。6.1 时间分配不当导致case题写不完这是一个非常普遍的问题。很多人拿到卷子从第一题开始按顺序做结果在SQL题上死磕太久最后留个20分钟给业务case只能草草写几句。要知道业务case分值占比最高写得再仓促也比SQL题多抢几分来得划算。我建议拿到卷子先用1~2分钟浏览全卷对每道题的难度和预估用时有个初步判断。然后按“先易后难、先大分值后小分值”的顺序做题。这里的“易”不一定是题目简单而是对你个人来说更顺手、更能拿分的题。如果你SQL很熟先写SQL没问题如果你业务sense很强先写case也未尝不可。关键是不要因为怕“没按顺序做”而影响心态。6.2 SQL题写完不检查低级错误直接丢分SQL题是最容易检查的题型但很多人写完就急着做下一题。我建议写完每道SQL题都花30秒做三个检查一看结果粒度确认group by后的粒度是否符合题意二看过滤条件确认时间窗口、状态过滤是否完整准确三看关联条件确认join的字段是否遗漏、是否会因为一对多关系产生数据膨胀。这三个检查能帮你避免大部分低级错误。6.3 选择题不会就蒙缺乏策略数据岗笔试的选择题往往有“不确定哪个是错项”的情况如果时间充裕可以用排除法。先把明显错误的选项排掉再在剩余选项中做对比——很多选项的错误点在于“概念张冠李戴”或“适用范围绝对化”这两类是最容易识别的。另外遇到不会的题不要连续浪费太多时间标记后先跳过等有空余时间再回头思考。6.4 业务case只给结论不给依据很多同学业务case写得太干瘪结论倒是写了不少但完全没有推导过程和验证建议。阅卷人看到的是一堆断言而不是一个有逻辑的分析报告。建议养成“结论依据数据/假设验证方法”的写作习惯。哪怕你的结论不一定完全正确但思路完整、逻辑清晰分数也不会低。6.5 笔试环境不熟悉导致操作失误线上笔试平台的操作细节也很容易翻车。有的平台代码编辑器不支持自动保存有的平台SQL运行环境版本和本地不一样有的平台复制粘贴会丢格式。建议在正式笔试前用目标平台提供的模拟题或历年真题做一次完整模考至少把平台的编辑器操作、代码运行方式、提交流程摸清楚。别小看这些细节真遇到运行环境Bug时心态很容易崩。6.6 心态管理专注在自己的节奏上笔试现场信息很多同批竞争者可能来自名校可能已经拿了offer但这些都和你没有关系。你唯一要做的事情就是在规定时间内把会做的题做到最好把不会做的题写出思路。我经历过考场上被前面的大神提前交卷干扰的情况后来发现提前交卷的人未必考得好真正决定结果的是答题质量不是交卷速度。保持自己的节奏把注意力放在题目上这是最好的心态策略。写在最后回头看2023年秋招小红书数据岗第三批笔试它并不是一场“刷题就能碾压”的考试更像是一次对综合能力的基本盘检验。SQL基础、统计知识、业务sense、逻辑表达任何一块有短板都会在某个题目上暴露出来。我个人最大的体会是笔试不是你求职路上的“终点关卡”而是一次提前预演——它模拟的就是你入职后每天要面对的工作内容。用准备笔试的心态去理解业务、用分析case的思路去看产品备考的过程本身就比结果更有价值。如果你正在准备下一批笔试或者面临其他大厂的数据岗校招希望你读完这篇文章后能做两件事第一找一道SQL真题和一道业务case用这篇文章里的框架模拟写一遍答案第二整理自己的错题笔记把薄弱点列出来逐个击破。这两件事做完你对数据岗笔试的把握感会明显不同。