2024年春招季小红书数据岗的笔试我前后一共参加了三批次的考核这一篇专门复盘第三批笔试的全过程。刷过小红书数据岗笔试题的人应该都有同感它的考察风格和互联网大厂通用的行测SQL套路不太一样更看重对业务场景的理解、对数据指标的拆解能力以及临场快速建模的思维纯背八股文和刷LeetCode在笔试环节是不太够用的。这篇文章我会从考题结构、各题型深度解析、时间分配心得、避坑记录几个维度展开把这次笔试的完整复盘写清楚给准备下场笔试的同学一份可以直接参考的实战手册。1. 笔试前的准备工作与考点预判1.1 小红书数据岗笔试的独特风格先说一个基本判断小红书的数据岗笔试整体上属于业务导向型不是代码竞赛型。如果你拿大厂技术岗笔试那种40分钟2道算法题的心态去应对大概率会在业务分析题上栽跟头。第三批笔试的题型分布大概是这样的——SQL题占一块Python编程占一块统计概率占一块然后是两到三道业务分析问答题。前后加起来一共四个大类考试时间120分钟题量不算特别大但每道题都需要组织语言、写清楚分析逻辑时间其实挺紧凑的。为什么小红书会这么设计这和它的业务属性直接相关。小红书是一个典型的UGC内容社区同时正在加速商业化这就决定了数据岗要处理的场景不仅是DAU涨跌、留存率分析还有内容推荐效果、搜索转化、电商交易、广告投放、创作者生态等等。笔试考业务分析题本质上就是在模拟入职之后你接到一个模糊需求、要自己理清逻辑、给结论的过程。所以光会写SQL是不行的你还得讲清楚为什么用这个口径这个指标能说明什么结论的局限在哪。1.2 备考资料怎么选才高效我在第三批笔试之前把复习重点压在这几个方向上SQL窗口函数的熟练运用、Python的pandas与基本统计建模、贝叶斯公式与假设检验、业务指标体系拆解。这里有一个很关键的备考心得——不要贪多。小红书笔试的SQL题不会涉及太冷门的语法窗口函数、日期处理、join与去重逻辑是绝对高频考点Python题也是以数据处理和简单分析为主基本不会考复杂的算法。所以复习的时候把基础打牢远比你刷一百道LeetCode Hard题有用。另外一个容易被忽视的点是笔试平台的IDE环境。小红书用的是牛客或者赛码这类在线平台代码补全和自动保存功能都比较弱SQL和Python题的运行环境也可能和你本地不一样。我建议备考阶段就直接在平台上刷题适应它那个没有语法高亮补全的裸环境不然正式考试的时候连缩进都要反复检查非常影响心态。1.3 考前一周的时间分配方案如果你现在离笔试还有一周我个人建议的节奏是这样前三天主攻SQL每天至少手写10道综合题重点练窗口函数rank/dense_rank/row_number的区别、date函数处理、多表关联去重第四天和第五天攻Python数据处理用pandas完成分组聚合、透视表、缺失值处理这类实操同时把假设检验、置信区间、贝叶斯公式这几个统计基础过一遍最后两天专门练业务分析问答题拿到一道题先不动笔强迫自己按明确问题→拆解指标→数据来源→结论验证这个框架把思路写下来写多了之后考场上会形成肌肉记忆。2. 核心题型深度拆解与解题思路2.1 SQL题窗口函数和去重逻辑是绝对主角第三批的SQL题一共出了三道难度梯度非常明显。第一题是基础题考察多表join和group by聚合先按用户维度汇总消费金额再筛选出消费次数大于等于3次的用户。这类题没什么好说的注意join时防止数据膨胀、聚合前先理解表关系就行。第二题开始上难度了考的是取每个分类下销量排名前N的商品。这个就是窗口函数rank()和row_number()的经典应用场景。我当时写的是-- 按分类分组按销量倒序排名取前3 SELECT category_id, item_id, sales_amount FROM ( SELECT category_id, item_id, sales_amount, ROW_NUMBER() OVER(PARTITION BY category_id ORDER BY sales_amount DESC) AS rn FROM sales_table WHERE stat_date 2024-03-01 ) t WHERE rn 3;这里有个很多人会踩的坑排名用rank()、dense_rank()还是row_number()这三者的区别要说清楚——row_number()会为每一行分配唯一序号即使是并列第一名也会分出1和2rank()会跳过并列名次比如两个并列第一之后下一个名次是3dense_rank()则不会跳跃两个并列第一之后下一个名次是2。题目问的是取销量前3的商品如果存在并列业务上更合理的选择往往是dense_rank()因为并列的商品应该被同时展示出来。我后来复盘时觉得第二题应该用dense_rank()而非row_number()这个细节可能就会拉开差距。第三题稍微复杂一些考的是连续N天活跃的用户。这类题的通用解法是利用日期减行号的差值来构造连续分组。核心逻辑是每个用户的活跃日期区间内如果按日期排序后日期减去行号得到的基准日期相同说明这些日期在时间上是连续的。SELECT user_id FROM ( SELECT user_id, active_date, DATE_SUB(active_date, INTERVAL ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY active_date) DAY) AS grp_date FROM user_active_log WHERE active_date BETWEEN 2024-02-01 AND 2024-02-29 ) t GROUP BY user_id, grp_date HAVING COUNT(*) 3;这一招叫连续问题转分组问题基本上是所有互联网公司笔试的高频考点。备考阶段建议把连续登录天数这一类SQL题练到闭着眼能写出来的程度它不复杂但考场上临时推导很容易出错。2.2 Python题pandas数据处理是重头戏Python部分考了两道题。第一题是纯pandas数据处理给了一张订单表要求按城市、按月份计算复购率。复购率的定义在笔试里必须自己先确认清楚一般理解是在某个时间窗口内购买过两次及以上的用户数除以该窗口内的总购买用户数但也可以定义为第二次购买行为发生在窗口内的用户数占比这两个口径算出来的数字差异不小。笔试时如果题目没给明确口径我的习惯是在答题区先写清楚我采用的口径是……理由是……这样即使和出题人的标准答案有偏差至少能展示你有定义意识。第二道Python题考的是AB实验的显著性判断给定实验组和对照组的转化率数据要求用Python实现两样本比例检验。这里其实就是在考察scipy.stats库的proportions_ztest或者卡方检验。我的做法是直接调用statsmodels库import statsmodels.api as sm from statsmodels.stats.proportion import proportions_ztest # 实验组: 5000人中转化420人; 对照组: 5000人中转化360人 count [420, 360] nobs [5000, 5000] z_stat, p_value proportions_ztest(count, nobs, alternativelarger) print(fz统计量: {z_stat:.4f}) print(fp值: {p_value:.4f}) # 显著性水平取0.05 if p_value 0.05: print(实验组转化率显著高于对照组可以推全量) else: print(实验组与对照组差异不显著不建议推全量)这里要注意一个细节如果平台没有预装statsmodels库手写z检验也不难直接用公式z (p1 - p2) / sqrt(p(1-p)(1/n1 1/n2))就能算。我建议备考时顺手把z检验的手算公式也写一遍万一线上环境缺库你还能用scipy的norm函数算出p值兜底。2.3 统计概率题贝叶斯和假设检验轮番上阵统计概率题出了两道。第一道是经典的生产线产品缺陷率问题——工厂有A、B两条生产线A线产量占60%次品率是2%B线产量占40%次品率是5%随机抽到一个次品问它来自A线的概率是多少。这就是贝叶斯公式的直接应用P(A|次品) P(次品|A) * P(A) / P(次品) 0.02 * 0.6 / (0.02 * 0.6 0.05 * 0.4) 0.012 / 0.032 0.37537.5%也就是抽到次品时它更可能来自B线。这类题属于送分题但笔试题经常会包装成内容平台上某条违规内容来自A策略审核通道还是B人工通道之类的业务场景本质还是同一个公式。备考时把贝叶斯公式的推导逻辑吃透比死记硬背答案有效得多。第二道统计题是假设检验给了一组数据要求判断某个策略上线后点击率是否有显著提升。题目没有直接给出p值需要自己先判断用Z检验还是T检验、单尾还是双尾。如果样本量比较大n30用Z检验即可如果样本量小且总体方差未知就要用T检验。笔试里为了简化通常会暗示样本量足够大直接算Z统计量对比1.96双尾95%置信水平来判断。2.4 业务分析题社区与电商场景的指标拆解业务分析题是小红书笔试的重头戏也是拉开分差的地方。第三批出了三道这里挑最有代表性的两道详细说说。第一道题的大意是某社区内容流的高点击内容占比环比下降了3个百分点要求分析可能原因。这类题考的是指标异动归因分析最忌讳一上来就猜原因正确姿势是搭建一个拆解框架。我当时是从量、质、场三个维度展开的——量指的是供给侧优质内容的发布量是否下降、低质内容是否混入质指的是内容本身标题封面平均质量、视频完播率、互动率有没有变场指的是分发侧推荐策略有没有调整、新用户占比变化、特定内容类目的分发占比是否改变。如果时间充裕还应该把数据验证方案写进去。比如要验证优质内容供给下降这个假说可以查看近30天发布内容中被标记为优质的比例是否出现趋势性下降要验证推荐策略调整可以对比新旧策略下的流量倾斜差异。把这些验证思路写具体会让阅卷人觉得你有完整的分析闭环能力。第二道业务题是电商方向某个大促活动期间新客首单转化率低于预期要求设计一个分析方案。我的回答框架是漏斗拆解人群分层竞品洞察三步走。漏斗拆解就是把新客从进入活动页到完成首单的每一步转化率拉出来找到掉点最严重的那一环人群分层就是看不同渠道来源、不同年龄段、不同兴趣标签的新客转化差异找出哪些人群是拖后腿的竞品洞察就是对比往期同类活动、对比其他品类的新客转化数据判断是活动本身力度不够还是流量质量变差了。每一层都要给出对应的数据表和指标口径这样才显得方案可落地。3. 笔试题型结构全览与应对策略3.1 整体题型分布与时间分配参考把第三批笔试的题型汇总成一张表方便你直观感受各个板块的分量题型板块题量建议用时核心考点难度SQL题3题35分钟窗口函数、多表关联、连续问题中高Python题2题30分钟pandas处理、假设检验中统计概率题2题20分钟贝叶斯公式、显著性检验低中业务分析题3题35分钟指标拆解、场景分析、方案设计高总计120分钟的笔试留出60%的时间给SQL和业务分析题是比较合理的。因为SQL题是代码题写错了就是错了踩中一个坑全题没分业务分析题虽然主观但只要能写出条理清晰的框架大部分分值都能拿到。我的策略是先做统计概率题热身20分钟再集中火力攻SQL35分钟接着写Python题30分钟最后留出35分钟全力写业务分析题。这个顺序能保证你在状态最好的时候先吃掉确定的分数再处理需要表达和逻辑的开放题。3.2 不同题型背后的考察逻辑小红书数据岗笔试的核心目的是筛掉两类人一类是只会写代码但不理解业务的工具人另一类是只会讲概念但上手做不到的口嗨选手。所以你会发现它的每个题型之间其实是有逻辑关联的——SQL题考的连续登录、留存计算就是业务分析题里做用户运营分析要用到的基础能力Python题考的假设检验就是在业务分析题中判断策略是否有用的核心方法统计概率题的贝叶斯公式对应的是社区内容甄别、推荐算法中的置信度计算。理解了这一层逻辑之后备考方向就非常清晰了不要割裂地去刷题而是把SQL取数→Python分析→统计验证→业务解读这条完整链路串起来。你可以找一个小红书实际的业务问题比如笔记搜索的点击率下降了从写SQL拉数据开始到用Python做趋势检验再到梳理可能原因写一份分析报告全程自己走一遍。这个过程做完之后任何形式的笔试都难不倒你。3.3 笔试平台与答题环境注意事项第三批笔试使用的在线平台有几个细节必须提前适应。第一代码编辑器没有自动补全函数名写错不会高亮提示所以平时练习就别依赖IDE提示尽量在记事本或者平台的空白编辑器里写代码第二SQL题的运行环境大概率是MySQL 8.0支持窗口函数但不排除部分题目需要手动指定ORDER BY的默认排序方向第三业务分析题是在一个多行文本框里作答没有格式化工具最好用一、二、三或1.1、1.2这种层级写清楚避免大段文字堆砌让阅卷人找不到重点。还有一个很现实的建议正式考试前用平台自带的模拟题练一次重点不是做题本身而是测试浏览器兼容性、网络稳定性、代码运行速度。我见过有同学在正式考试时因为浏览器不兼容代码编译不通过整整浪费了十分钟这种非技术因素导致的丢分真的非常冤。4. 模拟题实战演练与核心代码解析4.1 SQL实战连续登录问题的最优解法单独把连续登录这道题拎出来因为它值得深入讲一讲。题目是这样的给定一张用户登录日志表user_login字段有user_id、login_date要求统计2024年2月连续登录3天及以上的用户数。我在考场上的第一步是先做数据预处理——把每个用户的登录日期去重因为同一天可能有多条登录记录如果不先去重日期减行号的逻辑就会出错。-- 第一步对每个用户按日期去重 WITH tmp AS ( SELECT DISTINCT user_id, login_date FROM user_login WHERE login_date BETWEEN 2024-02-01 AND 2024-02-29 ), -- 第二步按用户分组按日期排序生成行号 tmp2 AS ( SELECT user_id, login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) AS rn FROM tmp ), -- 第三步日期减行号连续的日期会得到同一个基准日期 tmp3 AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL rn DAY) AS grp_date FROM tmp2 ) -- 第四步按用户基准日期分组统计数量 SELECT COUNT(DISTINCT user_id) AS continuous_user_cnt FROM tmp3 GROUP BY user_id, grp_date HAVING COUNT(*) 3;这个解法的精妙之处在于它把判断日期是否连续转换成了分组后统计数量绕开了逐行比较的复杂逻辑而且执行效率很高。如果题目要求输出连续登录的具体天数只需要在SELECT里加上COUNT(*)如果想输出满足条件的用户明细就把最后的分组结果和原表join一下即可。4.2 Python实战AB实验显著性检验完整流程Python的第二道题我完整地把AB实验显著性检验的流程写了一遍这里也分享出来。题目场景是内容平台改版了推荐算法随机分配了一部分用户进入实验组另一部分用户保持旧算法作为对照组观察一周后两组的次日留存率是否有显著差异。import numpy as np from scipy import stats # 实验组和对照组数据 exp_n 8000 exp_retained 3560 ctrl_n 8000 ctrl_retained 3400 exp_rate exp_retained / exp_n ctrl_rate ctrl_retained / ctrl_n # 计算合并比例 p_pool (exp_retained ctrl_retained) / (exp_n ctrl_n) # 计算Z统计量 se np.sqrt(p_pool * (1 - p_pool) * (1/exp_n 1/ctrl_n)) z_stat (exp_rate - ctrl_rate) / se # 计算p值双尾检验 p_value 2 * (1 - stats.norm.cdf(abs(z_stat))) print(f实验组留存率: {exp_rate:.4f}) print(f对照组留存率: {ctrl_rate:.4f}) print(fZ统计量: {z_stat:.4f}) print(fP值: {p_value:.4f}) if p_value 0.05: print(结论: 差异显著新算法有效果) else: print(结论: 差异不显著无法证明新算法有效)这道题还有一个容易忽略的点——假设检验中的第一类错误和第二类错误。如果样本量不够大即使真实有效果也可能检验不出来所以在真实的AB实验里我们通常会在实验开始前用功效分析计算最小样本量。笔试时把这一点写进答案里会显得你对统计方法论有完整的理解而不仅仅是会调库。4.3 业务分析实战从问题到数据验证方案业务分析题要拿高分关键是把自己代入数据分析师的角色而不是考生的角色。以高点击内容占比下降3个百分点为例我给出的分析方案分几个层次。第一个层次是先定义问题——高点击是指点击率超过某个阈值的内容占比是指这类内容在总内容池中的比例。这个定义一定要在答题开头写清楚因为很多业务问题看似清晰实际上口径模糊不同口径下结论完全不一样。第二个层次是拆可能原因我用的是MECE原则分类内容供给端高潜力内容发布量减少、低质内容大量涌入内容质量端推荐池里高点击内容的点击率本身下降可能因为标题封面质量退化分发策略端推荐算法调整导致流量向其他类型倾斜、新用户占比升高导致冷启动内容变多外部环境端节假日用户浏览习惯变化、竞品分流第三个层次是每个原因对应的验证方法。比如低质内容大量涌入可以通过监测新发布内容的平均点击率趋势来验证推荐算法调整可以通过对比新旧策略下的流量分层数据来判断。把这三个层次完整写下来一道业务分析题就拿下了。5. 实战踩坑记录与笔试必备清单5.1 我自己踩过的三个坑第一坑是SQL题没有先检查表之间的关联关系。有一道题涉及订单表和商品表商品表的商品ID在订单表中是外键但订单表里存在部分商品ID在商品表中找不到的情况。我一开始直接用INNER JOIN结果数据量少了一大截后来才发现要用LEFT JOIN并单独处理NULL值。这个教训是拿到SQL题先花30秒理解每张表的粒度确认主外键关系和可能的孤儿数据再动手写代码。第二坑是Python题吃了缩进的亏。在线平台的代码编辑器不会自动把tab转成空格我有一段代码混用了tab和空格导致编译报错花了五分钟才排查出来。现在我的习惯是写Python一律只用四个空格缩进不碰tab键。这个习惯建议你在平时练习时就养成。第三坑是业务分析题时间分配失衡。第三批笔试时我在第一道业务分析题上花的时间太长了写了很多冗余的细节导致后面两道业务题只能草草收尾。复盘时我意识到业务分析题是按点给分的把框架搭完整、每个方向写2到3个验证方案比盯着某一个方向写一堆详细步骤划算得多。尽量控制每道业务题在10到12分钟之内。5.2 笔试中的时间管理技巧和小抄清单考场上时间管理我总结了一句话先易后难留好buffer绝不死磕。遇到卡壳超过5分钟的题先跳过去做后面的等全部题目过完一遍再回头补。另外提醒一点业务分析题最好在草稿纸上先列提纲明确要写哪几个维度再动笔不然写一半发现逻辑不连贯删了重写更浪费时间。最后分享一个备考阶段的小抄清单——不是考场作弊那种而是考前10分钟可以快速过一遍的要点row_number()、rank()、dense_rank()的区别与适用场景连续问题的固定解法DATE_SUB(日期, INTERVAL 行号 DAY)复购率、留存率、ARPU的口径定义常见变体贝叶斯公式P(A|B)P(B|A)P(A)/P(B)Z检验与T检验的选择标准指标异动分析的MECE分类框架这套东西不用背很多遍考前扫一眼就能把知识框架唤醒。5.3 对下一批笔试朋友的建议汇总根据这次第三批笔试的完整经历我给接下来要参加笔试的朋友几条中肯建议。第一条重视业务分析题的练习不要只刷SQL题。你可以在网上找一些真实业务场景的分析题比如某APP卸载率上升怎么分析某品类GMV下降归因分析用明确问题→拆解指标→数据来源→验证方案的框架写答题稿。写个七八道自然就摸到套路了。第二条代码题一定要在笔试平台上练不要只在本地IDE写。笔试平台的运行环境、编辑器体验、代码提交方式都和本地不一样提前适应能少踩很多非技术坑。第三条保持好心态。小红书数据岗笔试的题量确实不小有一部分人根本做不完你只要保证会做的题全部拿分不会做的题搭好框架写上思路排名就不会差。说到底笔试只是筛选的起点真正决定录用与否的是后续的业务面试和综合面。我在考完第三批笔试之后的感受是数据岗笔试其实不太可能通过短期突击来骗过阅卷人它能反映出一个人的真实数据思维积累。如果你发现自己在业务分析题上完全没有思路与其焦虑不如多去分析小红书或者其他内容产品里的真实功能逻辑从用户视角理解一个推荐流、一个搜索页、一个活动会场背后涉及的数据问题。积累够多之后笔试就只是一次顺理成章的输出罢了。