2024年春招小红书数据岗第二批笔试我是在4月中旬收到的通知。如果你也投了这家应该知道第一批在3月底已经考过一轮第二批的试卷结构和第一批有明显差异尤其是业务案例分析题的占比加重了不少。这篇复盘我拖了一段时间才动笔主要是想把题目、解题思路、踩坑点都整理透而不是简单报个流水账。当时和我一起笔试的几个朋友考完对了一遍题发现我记的版本和他们的回忆版本有出入我尽量把两种情况都写出来方便你对照。1. 2024春招小红书数据岗笔试整体布局与考察逻辑1.1 笔试整体结构与时间分配第二批笔试依然是牛客网在线答题时间统一90分钟题量比第一批略少总共四大部分选择题单选多选、SQL编程题、Python/算法题、业务案例分析题。总分100分其中业务案例分析占比最高达到35分这在互联网大厂数据岗笔试里算是相当高的比例了。时间分配上如果你按顺序硬刚到底大概率会挂在后面的案例分析上。我当时先快速扫了一遍全部题目发现最后的业务案例是一道关于内容社区笔记推荐场景的留存分析题需要写比较完整的分析思路和SQL伪代码这就决定了我必须给最后留出至少30分钟。实际我的时间分配是选择题20分钟SQL题20分钟Python/算法题15分钟业务案例分析30分钟最后留5分钟检查。这里必须强调一个经验不要在前面的选择题上过多恋战。第二批选择题里有些概率统计题计算量不小如果每道题都死磕后面的大题时间一定不够。我亲眼见过考场上有同学前面的题答得特别仔细到业务案例题只剩10分钟最后只能随便写两句话交上去这种基本就告别面试了。1.2 题型分布与考察重点分析整体来看第二批笔试的考察重心很明确数据基础能力 业务分析思维。选择题覆盖了概率论与数理统计、机器学习基础、SQL语法细节、数据分析方法论SQL编程题两道一道是留存计算一道是用户行为路径统计Python/算法题是一道简单的数据处理题但加了点变化业务案例题则是围绕小红书典型的社区场景展开。对比第一批的题目回忆第二批明显减少了纯机器学习理论题增加了对业务指标体系和实验评估的考察。这其实是小红书数据岗一贯的风格因为他们的数据团队非常贴近业务不怎么招纯算法调包侠更看重你拿到一个业务问题时能不能拆解成清晰的数据分析路径以及能不能用SQL/代码把数据取出来。2. 选择题与基础题解析记忆中的考点复盘2.1 概率统计题从二项分布到贝叶斯公式第二批选择题里概率统计至少有5道而且不是那种送分的基础题。记忆比较深的一道是已知某事件A发生概率为P(A)0.3事件B发生概率为P(B)0.4A和B独立求P(A∪B)。这题本身不难套公式P(A∪B)P(A)P(B)-P(A)P(B)0.30.4-0.120.58。但后面紧跟着一道变体如果A和B是互斥事件再求P(A∪B)答案是0.7。这两种情况对比着考就是看你对独立和互斥的概念有没有真正吃透而不是背公式。还有一道考贝叶斯公式的题背景是社区的垃圾评论识别某分类器判断一条评论为垃圾评论的准确率为95%误报率为8%社区垃圾评论实际占比为5%问一条被判为垃圾评论的内容真正是垃圾评论的概率是多少。这道题一上来很容易被95%带偏但其实就是标准贝叶斯题。设G为真实垃圾评论P(G)0.05P(判G|G)0.95P(判G|非G)0.08要求P(G|判G)。计算过程是0.05×0.95 / (0.05×0.95 0.95×0.08)算出来大概是38.5%。这个数字很多人会觉得反直觉明明分类器准确率95%为什么真正垃圾的概率才不到四成根源在于垃圾评论本身的先验概率太低导致大量误报淹没了正确判断。这其实是工作中很常见的现象比如在反作弊、推荐过滤场景精确率和召回率永远要结合base rate来看单纯看模型报告的准确率毫无意义。还有一道多元选择题考的是置信区间和假设检验给出一个样本均值的95%置信区间[12.5, 15.3]问下列选项哪些说法正确。这里埋伏了三个常见错误选项比如“总体均值有95%的概率落在该区间内”这个说法是错的正确表述应该是“如果重复抽样多次构建大量置信区间大约95%的区间会包含总体均值”。还有选项说“样本均值落在该区间的概率为95%”也是错的因为样本均值是固定的点不存在概率问题。这种题目考的是统计推断的严谨表述很多教科书讲得不细做题很容易踩坑。2.2 机器学习基础偏应用场景而非纯理论推导第二批的机器学习选择题没有让手推公式更多是结合业务场景判断该用什么模型。有一道题印象深刻给定一个内容推荐场景用户对笔记的点击行为数据非常稀疏正样本占比不到1%问以下哪种评估指标最不适合用于衡量模型效果。选项包括AUC、准确率、F1、召回率。这里标准答案是准确率因为在正负样本极度不平衡时把所有样本都预测为负类的模型的准确率也会很高完全不能反映模型好坏。AUC和F1在这种情况下相对更可靠。另一道多选题问了防止过拟合的手段选项包括增加训练数据量、正则化、Dropout、增加模型深度、交叉验证。这里有个容易漏选的选项“交叉验证”它本身不直接防止过拟合但通过交叉验证可以更准确地评估模型泛化能力从而辅助选择超参间接缓解过拟合所以这个选项要根据题干问的是“直接手段”还是“有效手段”来判断。我印象中这道题问的是“下列哪些方法可以有效缓解过拟合”那就应该选上交叉验证。还有一道题关于特征工程给出用户年龄、最近30天登录天数、笔记收藏数、用户ID四个字段问哪些适合直接作为逻辑回归的数值型特征。用户ID肯定不能直接用因为它是类别型的标识符且基数极大直接丢进模型等于引入了巨大的噪声。这一点我觉得是故意设置的陷阱因为做数据的人如果没处理过真实业务数据很容易忽略ID类的字段不能直接进模型。2.3 SQL语法细节窗口函数是重头戏选择题里有好几道SQL题其中至少三道和窗口函数相关包括ROW_NUMBER()、RANK()、DENSE_RANK()的区别以及SUM() OVER(PARTITION BY ... ORDER BY ...)的累计求和逻辑。有一道题我记得特别清楚给定一张订单表要求计算每个用户截至该订单日期的累计消费金额问下列SQL哪个正确。正确选项是SUM(amount) OVER(PARTITION BY user_id ORDER BY order_date)强调这个窗口函数默认的窗口范围是从分区第一行到当前行所以不需要显式写ROWS BETWEEN。但也正是这个默认行为如果order_date不是唯一的窗口范围会包含所有同日期行导致结果和预期不符这是一个很微妙的细节。另一道题考了WHERE和HAVING的区别筛选出订单数大于3的用户给出的四个SQL片段里有两个是把聚合条件写在WHERE里这是错的因为WHERE在分组聚合之前执行此时还看不到COUNT(*)的结果。HAVING在分组之后执行才是正确的筛选时机。这种题属于基础但高频的送分题如果这都能错后面SQL大题基本也没戏了。2.4 数据分析方法论对比实验与辛普森悖论有一道综合题给了个业务场景某推荐策略改版后整体点击率上升但是分品类看每个品类的点击率都下降问最可能的原因。答案是辛普森悖论即整体数据被不同品类样本量的占比变化所混淆。这题不难但它考的是你在真实业务中会不会被整体指标欺骗。小红书这种内容平台笔记的品类分布变化很快如果某个大品类突然爆发即使每个品类的策略效果都变差整体指标也可能被拉高这时候就要做分层拆解。还有一道多选题关于AB实验的注意事项选项包括实验组对照组样本量是否需要保持完全一致、实验周期是否需要包含完整的时间周期以排除星期效应、实验前是否需要做AA验证、是否可以提前看数据并停止实验。这里比较有争议的是第一个选项AB实验其实不要求样本量严格一致只要满足统计功效的前提下样本量不同也可以通过分层抽样或加权处理来校正。但实验周期要覆盖完整业务周期排除星期效应这个是对的。做AA验证也是对的可以检验分流系统是否存在偏差。提前看数据并停止实验则坚决不对会引入p-hacking的问题。3. 两道SQL编程题从留存到行为路径3.1 用户留存计算经典中的经典但有个陷阱第二道SQL编程题是求用户次日留存率。表结构大致是user_login表字段有user_id、login_date。需要计算每个首次登录日的用户次日留存率。这题常规做法是找出每个用户的最小登录日期作为首登日再左连接login表看首登日第二天的登录记录是否存在。比较温和的版本是这样。但第二批笔试有一个更刁钻的变体表中可能一天有多条登录记录需要做去重后再计算而且有一个用户的首次登录日期出现了多次这时候要小心LEFT JOIN会把同一用户的记录放大成笛卡尔积导致留存率算错。我用的去重写法是用DISTINCT对(user_id, login_date)先做一遍去重再算首登日和次日是否存在这样就不会出问题。如果你在自测时发现留存率超过100%大概率就是没做去重。SQL给出来大概是这样的思路WITH user_first AS ( SELECT user_id, MIN(login_date) AS first_date FROM ( SELECT DISTINCT user_id, login_date FROM user_login ) t GROUP BY user_id ), user_retained AS ( SELECT DISTINCT a.user_id, a.first_date FROM user_first a JOIN user_login b ON a.user_id b.user_id AND b.login_date DATE_ADD(a.first_date, INTERVAL 1 DAY) ) SELECT first_date AS login_date, COUNT(DISTINCT user_id) AS new_users, COUNT(DISTINCT IF(retained.user_id IS NOT NULL, user_id, NULL)) AS retained_users, COUNT(DISTINCT IF(retained.user_id IS NOT NULL, user_id, NULL)) / COUNT(DISTINCT user_id) AS retention_rate FROM user_first LEFT JOIN user_retained retained USING(user_id, first_date) GROUP BY first_date ORDER BY first_date;这个写法的思路是先对登录记录去重避免同一天多次登录导致后续JOIN时数据膨胀找出每个用户的最早登录日期把首登日和次日配对最后计算留存率。实际上我在笔试时没有用WITH子句因为牛客网的SQL环境不支持WITH的话会很被动我用的是嵌套子查询。这里建议平时练习时两种写法都掌握考试时根据环境灵活切换。你在本地MySQL或Hive环境做练习时用WITH更易读但如果考试环境明确说MySQL 5.7及以下就不要冒险。3.2 用户行为路径统计考验窗口函数的综合运用第二道SQL题给了一个用户行为日志表包含user_id、action如view、like、collect、comment、action_time、note_id等字段。要求统计每个用户按时间顺序进行的行为路径中出现“浏览笔记后点赞”这一行为组合的次数并输出次数前十的用户。这题考察的是如何把时间序列转换成可分析的滑动窗口。我当时采用的是LEAD()窗口函数将同一用户的行为按action_time排序后把每个行为的下一个行为取出来然后过滤看当前行为是view、下一个行为是like的配对数量。这里要小心同一秒内多个行为的状态如果有完全相同的时间戳就需要额外排序字段。我笔试时写了类似这样的SQLWITH user_action_seq AS ( SELECT user_id, action, LEAD(action) OVER(PARTITION BY user_id ORDER BY action_time) AS next_action FROM user_action_log ) SELECT user_id, COUNT(*) AS view_like_cnt FROM user_action_seq WHERE action view AND next_action like GROUP BY user_id ORDER BY view_like_cnt DESC LIMIT 10;这题容易掉进去的坑有两个。第一个坑是不考虑“用户在一次会话中连续浏览多篇笔记后再点赞”的场景只统计了“浏览后紧跟着点赞”的相邻行为会漏掉不少真实路径。笔试时间有限我按规则简单写了相邻配对但如果想答得更完善可以在思路补充里写上先按时间间隔把用户行为划分成会话再统计会话内的view→like序列。第二个坑是对用户行为日志的分析忘记按时间排序LEAD()函数如果不显式指定ORDER BY结果就是随机顺序如果被样例数据碰巧看起来正确很难发现自己错了。4. 业务案例分析题社区笔记推荐的留存分析4.1 案例背景与问题拆解业务案例题的大意是小红书内容社区近期对推荐策略做了一轮调整新策略上线一周后整体笔记点击率上升了5%但次日留存率反而下降了0.8个百分点。作为数据岗需要分析留存率下降的可能原因并给出进一步验证的方案。这个题目基本是数据岗面试的经典题业务指标涨跌归因分析。很多人的第一反应是直接开始列可能原因但作为笔试更重要的是展示结构化思维。我当时的整体思路是先确认指标定义和统计口径是否有变化是不是改了留存率的定义、没有过滤异常用户等做维度下钻分析从用户维度新老用户、不同活跃度、不同注册渠道和内容维度不同笔记品类、不同作者类型拆解留存率变化结合实验机制判断推荐策略调整是否影响了对用户的内容供给结构比如推荐了更高点击率但低质量的内容导致用户疲倦提出数据验证方案包括对比实验设计、漏斗分析、行为序列分析等。这个拆解思路其实是数据岗分析师的通用框架先确认数据可靠性再从整体到细分逐步下钻最后结合业务场景做因果假设检验。这里有个笔试技巧值得单独说案例分析题阅卷时评卷人看的不是你列了多少点而是看你的逻辑层级是否清晰能不能从数据变化推导出业务结论。所以答题时我用了“可能原因假设 验证方法”的对应结构每个假设后面都跟了具体的取数逻辑和判断标准这样的答案比单纯罗列原因得分率高很多。4.2 假设拆解与验证方案的详细设计假设一指标统计口径变化导致“假性下降”这是所有归因分析的第一步也是最容易被忽略的一步。新策略上线前后如果数据上报逻辑有调整比如客户端埋点改了字段、新增了启动检查逻辑导致部分用户没被记录为“活跃用户”那么留存率下降就可能是统计口径改变带来的伪波动。验证方法很简单检查留存率计算口径是否与上线前一致对比新旧口径在相同时间段内算出的留存率差异或者干脆用下线期间的流量做一次数据质量校验。真实情况中我确实遇到过因为埋点SDK升级导致连续三天的活跃用户数骤降的案例排查了半天才定位到是埋点数据覆盖范围出了问题。假设二推荐策略把“高留存内容”挤出了首屏点击率上升但留存率下降最典型的原因是推荐系统优化目标偏向点击率导致具有高点击率但低互动深度、低长期价值的“标题党”类内容获得了更多曝光而真正能带来用户回访的“高价值内容”被挤出首屏。小红书这种以种草和搜索决策为核心的社区用户如果没有获得有效信息点击再热门的笔记也不会产生下一次打开的动力。验证方案是按笔记品类和内容特征拆解留存率变化比较新旧策略下各品类笔记的曝光占比变化以及曝光占比变化最大的品类其留存贡献度是否在下降。进一步可以用用户行为序列分析对比新旧策略下用户单次会话内的浏览深度、评论率、收藏率等深度行为指标是否也同步下降。如果点击率上升但深度互动行为下降基本坐实了“高点击低质量”内容挤占的思路。假设三新策略导致某些特定用户群体体验受损留存率是一个整体指标如果部分用户群体的留存下降明显但其他用户群体基本没变整体数据照样会被拖下去。我们当时按照新老用户、活跃度分层、内容偏好类型拆了一下发现如果新策略是根据实时点击行为做推荐可能会导致新用户被快速推入大量垂直细分的社区内容而新用户对社区的熟悉度不高反而觉得内容“太窄”从而不再回访。验证方法是做用户分层留存分析算出不同用户分层在新旧策略下的留存率差异找到下降最明显的用户人群。然后针对这部分人群做行为路径分析看他们在首次会话中的内容消费结构是否与留存用户有明显差异。最后可以提出一个定向优化方案比如对新用户采用更多元化的内容推荐把冷启动策略和活跃用户策略分开设计。假设四实验机制本身存在偏差如果新策略的流量分配不是严格的随机分组比如把一部分新增用户或低活跃用户划到了实验组对照组和实验组在用户构成上就不一致了留存率对比自然失真。这也是AB实验的基本前提笔试时写上去能体现你对实验设计的理解。验证方案就是做AA实验或者对实验组和对照组做用户特征分布检验确认两组在年龄、性别、活跃度、品类偏好等维度上没有显著性差异。4.3 案例分析题的高分答题范式如果你是第一次参加数据岗笔试可能不太清楚案例分析题应该怎么答才能拿高分。根据我的经验需要注意三个要点第一先定性再定量。先把总体方向、分析框架写清楚再聚焦到具体假设和取数逻辑。这样阅卷人能快速看出你的思维框架就算具体细节有疏漏大方向不出错也能拿基础分。第二每个假设都要写验证方法。只列假设不写验证等于只做了分析的一半。验证方法不要求写SQL代码但至少要写明用什么数据、怎么判断。第三适当补充业务理解。小红书这类内容社区数据岗的案例分析题通常和社区生态有关如果你了解他们的业务逻辑可以在答题中适当融入对社区内容生态的理解。比如“点击率高但留存下降”这个问题如果放到小红书的业务语境下就可以提到“首页推荐流如果过度偏向某一个垂直品类会削弱用户对社区丰富性的感知影响长期留存”这种结合业务的洞察会比泛泛而谈“推荐质量下降”更有说服力。5. 备考方向与面试衔接建议5.1 针对小红书数据岗的系统性复习建议如果你准备投下一年的春招或秋招我在这次笔试经历后总结的复习重点可以给你一个参考SQL方面窗口函数、留存计算、行为路径统计是必修课尤其在内容和社交平台业务里这三类SQL题几乎是必考的。建议把窗口函数常用模板练到条件反射的程度。统计学方面贝叶斯公式、二项分布、假设检验、置信区间是选择题的高频考点。建议重点关注“反直觉”的概率题比如先验概率很低时的贝叶斯后验概率计算这类题很容易出成迷惑项。机器学习方面不需要深抠算法推导但要把评估指标、过拟合手段、特征工程的基本概念搞透尤其要理解它们在类别不平衡样本下的表现差异。业务分析方面留存率下降、点击率上升但转化率下降、AB实验评估、漏斗分析这四类题是最常见的case题类型。建议平时多拆解一些自己身边的App案例练习从数据现象反推业务问题的能力。5.2 从笔试到面试的衔接准备笔试通过后一般会进入面试环节笔试中的案例分析题经常成为后续面试的延伸话题。比如我当时笔试里写的推荐策略留存分析面试时被追问了“如果让你设计一个实验来验证你的假设你会怎么做”所以笔试时不要只背模板要真正理解自己写的内容能够在追问中展开细节。另外一个容易被忽视的点是笔试时要注意留痕和记录。我通常会在草稿纸上写下每道题的解题思路即使最后答案没写完也能在面试时回忆起当时的思考过程和面试官深入讨论。大数据岗的面试非常看重思维过程完全复制背诵的经验有时候反而不如自己独立思考的痕迹更有说服力。5.3 心态调整与应试策略最后聊点务实的。第二批笔试时间安排在4月中旬很多同学已经经历了多场笔试状态可能有些疲惫。我的建议是把每场笔试都当作一次真实的数据分析项目而不是单纯的考试。拿到题先通读一遍判断哪些题能拿分哪些题需要攻坚不要因为某道题卡住就乱了节奏。时间分配上我的经验是选择题每道不超过2分钟如果一道题超过3分钟还没思路就标记跳过最后有时间再回头。案例分析题如果你能提前半小时做到那么时间相对充裕可以写得更有条理。SQL题如果第一版写出来运行报错不要慌先检查是不是表名或字段名写错了这种低级错误最常见。我在实际参加小红书第二批笔试的过程中发现牛客网的环境整体比较稳定但SQL题的运行耗时有时候会波动如果SQL写得比较复杂跑批时间可能较长。建议大家提前在牛客网熟悉一下在线编程环境至少要知道编译报错时怎么看日志避免上了考场被环境问题干扰心态。总的来说2024年春招小红书数据岗第二批笔试的难度属于中上水平既考察基本功也考察业务理解。如果你能系统掌握SQL窗口函数、统计推断基础并且熟悉内容社区类产品的数据分析思路拿到面试资格并不难。难的是在有限时间内把案例分析题答到点子上这需要平时多积累、多拆解、多复盘。希望这篇复盘能给你提供一些参考祝你也顺利拿下心仪的offer。
2024年春招小红书数据岗第二批笔试我是在4月中旬收到的通知。如果你也投了这家应该知道第一批在3月底已经考过一轮第二批的试卷结构和第一批有明显差异尤其是业务案例分析题的占比加重了不少。这篇复盘我拖了一段时间才动笔主要是想把题目、解题思路、踩坑点都整理透而不是简单报个流水账。当时和我一起笔试的几个朋友考完对了一遍题发现我记的版本和他们的回忆版本有出入我尽量把两种情况都写出来方便你对照。1. 2024春招小红书数据岗笔试整体布局与考察逻辑1.1 笔试整体结构与时间分配第二批笔试依然是牛客网在线答题时间统一90分钟题量比第一批略少总共四大部分选择题单选多选、SQL编程题、Python/算法题、业务案例分析题。总分100分其中业务案例分析占比最高达到35分这在互联网大厂数据岗笔试里算是相当高的比例了。时间分配上如果你按顺序硬刚到底大概率会挂在后面的案例分析上。我当时先快速扫了一遍全部题目发现最后的业务案例是一道关于内容社区笔记推荐场景的留存分析题需要写比较完整的分析思路和SQL伪代码这就决定了我必须给最后留出至少30分钟。实际我的时间分配是选择题20分钟SQL题20分钟Python/算法题15分钟业务案例分析30分钟最后留5分钟检查。这里必须强调一个经验不要在前面的选择题上过多恋战。第二批选择题里有些概率统计题计算量不小如果每道题都死磕后面的大题时间一定不够。我亲眼见过考场上有同学前面的题答得特别仔细到业务案例题只剩10分钟最后只能随便写两句话交上去这种基本就告别面试了。1.2 题型分布与考察重点分析整体来看第二批笔试的考察重心很明确数据基础能力 业务分析思维。选择题覆盖了概率论与数理统计、机器学习基础、SQL语法细节、数据分析方法论SQL编程题两道一道是留存计算一道是用户行为路径统计Python/算法题是一道简单的数据处理题但加了点变化业务案例题则是围绕小红书典型的社区场景展开。对比第一批的题目回忆第二批明显减少了纯机器学习理论题增加了对业务指标体系和实验评估的考察。这其实是小红书数据岗一贯的风格因为他们的数据团队非常贴近业务不怎么招纯算法调包侠更看重你拿到一个业务问题时能不能拆解成清晰的数据分析路径以及能不能用SQL/代码把数据取出来。2. 选择题与基础题解析记忆中的考点复盘2.1 概率统计题从二项分布到贝叶斯公式第二批选择题里概率统计至少有5道而且不是那种送分的基础题。记忆比较深的一道是已知某事件A发生概率为P(A)0.3事件B发生概率为P(B)0.4A和B独立求P(A∪B)。这题本身不难套公式P(A∪B)P(A)P(B)-P(A)P(B)0.30.4-0.120.58。但后面紧跟着一道变体如果A和B是互斥事件再求P(A∪B)答案是0.7。这两种情况对比着考就是看你对独立和互斥的概念有没有真正吃透而不是背公式。还有一道考贝叶斯公式的题背景是社区的垃圾评论识别某分类器判断一条评论为垃圾评论的准确率为95%误报率为8%社区垃圾评论实际占比为5%问一条被判为垃圾评论的内容真正是垃圾评论的概率是多少。这道题一上来很容易被95%带偏但其实就是标准贝叶斯题。设G为真实垃圾评论P(G)0.05P(判G|G)0.95P(判G|非G)0.08要求P(G|判G)。计算过程是0.05×0.95 / (0.05×0.95 0.95×0.08)算出来大概是38.5%。这个数字很多人会觉得反直觉明明分类器准确率95%为什么真正垃圾的概率才不到四成根源在于垃圾评论本身的先验概率太低导致大量误报淹没了正确判断。这其实是工作中很常见的现象比如在反作弊、推荐过滤场景精确率和召回率永远要结合base rate来看单纯看模型报告的准确率毫无意义。还有一道多元选择题考的是置信区间和假设检验给出一个样本均值的95%置信区间[12.5, 15.3]问下列选项哪些说法正确。这里埋伏了三个常见错误选项比如“总体均值有95%的概率落在该区间内”这个说法是错的正确表述应该是“如果重复抽样多次构建大量置信区间大约95%的区间会包含总体均值”。还有选项说“样本均值落在该区间的概率为95%”也是错的因为样本均值是固定的点不存在概率问题。这种题目考的是统计推断的严谨表述很多教科书讲得不细做题很容易踩坑。2.2 机器学习基础偏应用场景而非纯理论推导第二批的机器学习选择题没有让手推公式更多是结合业务场景判断该用什么模型。有一道题印象深刻给定一个内容推荐场景用户对笔记的点击行为数据非常稀疏正样本占比不到1%问以下哪种评估指标最不适合用于衡量模型效果。选项包括AUC、准确率、F1、召回率。这里标准答案是准确率因为在正负样本极度不平衡时把所有样本都预测为负类的模型的准确率也会很高完全不能反映模型好坏。AUC和F1在这种情况下相对更可靠。另一道多选题问了防止过拟合的手段选项包括增加训练数据量、正则化、Dropout、增加模型深度、交叉验证。这里有个容易漏选的选项“交叉验证”它本身不直接防止过拟合但通过交叉验证可以更准确地评估模型泛化能力从而辅助选择超参间接缓解过拟合所以这个选项要根据题干问的是“直接手段”还是“有效手段”来判断。我印象中这道题问的是“下列哪些方法可以有效缓解过拟合”那就应该选上交叉验证。还有一道题关于特征工程给出用户年龄、最近30天登录天数、笔记收藏数、用户ID四个字段问哪些适合直接作为逻辑回归的数值型特征。用户ID肯定不能直接用因为它是类别型的标识符且基数极大直接丢进模型等于引入了巨大的噪声。这一点我觉得是故意设置的陷阱因为做数据的人如果没处理过真实业务数据很容易忽略ID类的字段不能直接进模型。2.3 SQL语法细节窗口函数是重头戏选择题里有好几道SQL题其中至少三道和窗口函数相关包括ROW_NUMBER()、RANK()、DENSE_RANK()的区别以及SUM() OVER(PARTITION BY ... ORDER BY ...)的累计求和逻辑。有一道题我记得特别清楚给定一张订单表要求计算每个用户截至该订单日期的累计消费金额问下列SQL哪个正确。正确选项是SUM(amount) OVER(PARTITION BY user_id ORDER BY order_date)强调这个窗口函数默认的窗口范围是从分区第一行到当前行所以不需要显式写ROWS BETWEEN。但也正是这个默认行为如果order_date不是唯一的窗口范围会包含所有同日期行导致结果和预期不符这是一个很微妙的细节。另一道题考了WHERE和HAVING的区别筛选出订单数大于3的用户给出的四个SQL片段里有两个是把聚合条件写在WHERE里这是错的因为WHERE在分组聚合之前执行此时还看不到COUNT(*)的结果。HAVING在分组之后执行才是正确的筛选时机。这种题属于基础但高频的送分题如果这都能错后面SQL大题基本也没戏了。2.4 数据分析方法论对比实验与辛普森悖论有一道综合题给了个业务场景某推荐策略改版后整体点击率上升但是分品类看每个品类的点击率都下降问最可能的原因。答案是辛普森悖论即整体数据被不同品类样本量的占比变化所混淆。这题不难但它考的是你在真实业务中会不会被整体指标欺骗。小红书这种内容平台笔记的品类分布变化很快如果某个大品类突然爆发即使每个品类的策略效果都变差整体指标也可能被拉高这时候就要做分层拆解。还有一道多选题关于AB实验的注意事项选项包括实验组对照组样本量是否需要保持完全一致、实验周期是否需要包含完整的时间周期以排除星期效应、实验前是否需要做AA验证、是否可以提前看数据并停止实验。这里比较有争议的是第一个选项AB实验其实不要求样本量严格一致只要满足统计功效的前提下样本量不同也可以通过分层抽样或加权处理来校正。但实验周期要覆盖完整业务周期排除星期效应这个是对的。做AA验证也是对的可以检验分流系统是否存在偏差。提前看数据并停止实验则坚决不对会引入p-hacking的问题。3. 两道SQL编程题从留存到行为路径3.1 用户留存计算经典中的经典但有个陷阱第二道SQL编程题是求用户次日留存率。表结构大致是user_login表字段有user_id、login_date。需要计算每个首次登录日的用户次日留存率。这题常规做法是找出每个用户的最小登录日期作为首登日再左连接login表看首登日第二天的登录记录是否存在。比较温和的版本是这样。但第二批笔试有一个更刁钻的变体表中可能一天有多条登录记录需要做去重后再计算而且有一个用户的首次登录日期出现了多次这时候要小心LEFT JOIN会把同一用户的记录放大成笛卡尔积导致留存率算错。我用的去重写法是用DISTINCT对(user_id, login_date)先做一遍去重再算首登日和次日是否存在这样就不会出问题。如果你在自测时发现留存率超过100%大概率就是没做去重。SQL给出来大概是这样的思路WITH user_first AS ( SELECT user_id, MIN(login_date) AS first_date FROM ( SELECT DISTINCT user_id, login_date FROM user_login ) t GROUP BY user_id ), user_retained AS ( SELECT DISTINCT a.user_id, a.first_date FROM user_first a JOIN user_login b ON a.user_id b.user_id AND b.login_date DATE_ADD(a.first_date, INTERVAL 1 DAY) ) SELECT first_date AS login_date, COUNT(DISTINCT user_id) AS new_users, COUNT(DISTINCT IF(retained.user_id IS NOT NULL, user_id, NULL)) AS retained_users, COUNT(DISTINCT IF(retained.user_id IS NOT NULL, user_id, NULL)) / COUNT(DISTINCT user_id) AS retention_rate FROM user_first LEFT JOIN user_retained retained USING(user_id, first_date) GROUP BY first_date ORDER BY first_date;这个写法的思路是先对登录记录去重避免同一天多次登录导致后续JOIN时数据膨胀找出每个用户的最早登录日期把首登日和次日配对最后计算留存率。实际上我在笔试时没有用WITH子句因为牛客网的SQL环境不支持WITH的话会很被动我用的是嵌套子查询。这里建议平时练习时两种写法都掌握考试时根据环境灵活切换。你在本地MySQL或Hive环境做练习时用WITH更易读但如果考试环境明确说MySQL 5.7及以下就不要冒险。3.2 用户行为路径统计考验窗口函数的综合运用第二道SQL题给了一个用户行为日志表包含user_id、action如view、like、collect、comment、action_time、note_id等字段。要求统计每个用户按时间顺序进行的行为路径中出现“浏览笔记后点赞”这一行为组合的次数并输出次数前十的用户。这题考察的是如何把时间序列转换成可分析的滑动窗口。我当时采用的是LEAD()窗口函数将同一用户的行为按action_time排序后把每个行为的下一个行为取出来然后过滤看当前行为是view、下一个行为是like的配对数量。这里要小心同一秒内多个行为的状态如果有完全相同的时间戳就需要额外排序字段。我笔试时写了类似这样的SQLWITH user_action_seq AS ( SELECT user_id, action, LEAD(action) OVER(PARTITION BY user_id ORDER BY action_time) AS next_action FROM user_action_log ) SELECT user_id, COUNT(*) AS view_like_cnt FROM user_action_seq WHERE action view AND next_action like GROUP BY user_id ORDER BY view_like_cnt DESC LIMIT 10;这题容易掉进去的坑有两个。第一个坑是不考虑“用户在一次会话中连续浏览多篇笔记后再点赞”的场景只统计了“浏览后紧跟着点赞”的相邻行为会漏掉不少真实路径。笔试时间有限我按规则简单写了相邻配对但如果想答得更完善可以在思路补充里写上先按时间间隔把用户行为划分成会话再统计会话内的view→like序列。第二个坑是对用户行为日志的分析忘记按时间排序LEAD()函数如果不显式指定ORDER BY结果就是随机顺序如果被样例数据碰巧看起来正确很难发现自己错了。4. 业务案例分析题社区笔记推荐的留存分析4.1 案例背景与问题拆解业务案例题的大意是小红书内容社区近期对推荐策略做了一轮调整新策略上线一周后整体笔记点击率上升了5%但次日留存率反而下降了0.8个百分点。作为数据岗需要分析留存率下降的可能原因并给出进一步验证的方案。这个题目基本是数据岗面试的经典题业务指标涨跌归因分析。很多人的第一反应是直接开始列可能原因但作为笔试更重要的是展示结构化思维。我当时的整体思路是先确认指标定义和统计口径是否有变化是不是改了留存率的定义、没有过滤异常用户等做维度下钻分析从用户维度新老用户、不同活跃度、不同注册渠道和内容维度不同笔记品类、不同作者类型拆解留存率变化结合实验机制判断推荐策略调整是否影响了对用户的内容供给结构比如推荐了更高点击率但低质量的内容导致用户疲倦提出数据验证方案包括对比实验设计、漏斗分析、行为序列分析等。这个拆解思路其实是数据岗分析师的通用框架先确认数据可靠性再从整体到细分逐步下钻最后结合业务场景做因果假设检验。这里有个笔试技巧值得单独说案例分析题阅卷时评卷人看的不是你列了多少点而是看你的逻辑层级是否清晰能不能从数据变化推导出业务结论。所以答题时我用了“可能原因假设 验证方法”的对应结构每个假设后面都跟了具体的取数逻辑和判断标准这样的答案比单纯罗列原因得分率高很多。4.2 假设拆解与验证方案的详细设计假设一指标统计口径变化导致“假性下降”这是所有归因分析的第一步也是最容易被忽略的一步。新策略上线前后如果数据上报逻辑有调整比如客户端埋点改了字段、新增了启动检查逻辑导致部分用户没被记录为“活跃用户”那么留存率下降就可能是统计口径改变带来的伪波动。验证方法很简单检查留存率计算口径是否与上线前一致对比新旧口径在相同时间段内算出的留存率差异或者干脆用下线期间的流量做一次数据质量校验。真实情况中我确实遇到过因为埋点SDK升级导致连续三天的活跃用户数骤降的案例排查了半天才定位到是埋点数据覆盖范围出了问题。假设二推荐策略把“高留存内容”挤出了首屏点击率上升但留存率下降最典型的原因是推荐系统优化目标偏向点击率导致具有高点击率但低互动深度、低长期价值的“标题党”类内容获得了更多曝光而真正能带来用户回访的“高价值内容”被挤出首屏。小红书这种以种草和搜索决策为核心的社区用户如果没有获得有效信息点击再热门的笔记也不会产生下一次打开的动力。验证方案是按笔记品类和内容特征拆解留存率变化比较新旧策略下各品类笔记的曝光占比变化以及曝光占比变化最大的品类其留存贡献度是否在下降。进一步可以用用户行为序列分析对比新旧策略下用户单次会话内的浏览深度、评论率、收藏率等深度行为指标是否也同步下降。如果点击率上升但深度互动行为下降基本坐实了“高点击低质量”内容挤占的思路。假设三新策略导致某些特定用户群体体验受损留存率是一个整体指标如果部分用户群体的留存下降明显但其他用户群体基本没变整体数据照样会被拖下去。我们当时按照新老用户、活跃度分层、内容偏好类型拆了一下发现如果新策略是根据实时点击行为做推荐可能会导致新用户被快速推入大量垂直细分的社区内容而新用户对社区的熟悉度不高反而觉得内容“太窄”从而不再回访。验证方法是做用户分层留存分析算出不同用户分层在新旧策略下的留存率差异找到下降最明显的用户人群。然后针对这部分人群做行为路径分析看他们在首次会话中的内容消费结构是否与留存用户有明显差异。最后可以提出一个定向优化方案比如对新用户采用更多元化的内容推荐把冷启动策略和活跃用户策略分开设计。假设四实验机制本身存在偏差如果新策略的流量分配不是严格的随机分组比如把一部分新增用户或低活跃用户划到了实验组对照组和实验组在用户构成上就不一致了留存率对比自然失真。这也是AB实验的基本前提笔试时写上去能体现你对实验设计的理解。验证方案就是做AA实验或者对实验组和对照组做用户特征分布检验确认两组在年龄、性别、活跃度、品类偏好等维度上没有显著性差异。4.3 案例分析题的高分答题范式如果你是第一次参加数据岗笔试可能不太清楚案例分析题应该怎么答才能拿高分。根据我的经验需要注意三个要点第一先定性再定量。先把总体方向、分析框架写清楚再聚焦到具体假设和取数逻辑。这样阅卷人能快速看出你的思维框架就算具体细节有疏漏大方向不出错也能拿基础分。第二每个假设都要写验证方法。只列假设不写验证等于只做了分析的一半。验证方法不要求写SQL代码但至少要写明用什么数据、怎么判断。第三适当补充业务理解。小红书这类内容社区数据岗的案例分析题通常和社区生态有关如果你了解他们的业务逻辑可以在答题中适当融入对社区内容生态的理解。比如“点击率高但留存下降”这个问题如果放到小红书的业务语境下就可以提到“首页推荐流如果过度偏向某一个垂直品类会削弱用户对社区丰富性的感知影响长期留存”这种结合业务的洞察会比泛泛而谈“推荐质量下降”更有说服力。5. 备考方向与面试衔接建议5.1 针对小红书数据岗的系统性复习建议如果你准备投下一年的春招或秋招我在这次笔试经历后总结的复习重点可以给你一个参考SQL方面窗口函数、留存计算、行为路径统计是必修课尤其在内容和社交平台业务里这三类SQL题几乎是必考的。建议把窗口函数常用模板练到条件反射的程度。统计学方面贝叶斯公式、二项分布、假设检验、置信区间是选择题的高频考点。建议重点关注“反直觉”的概率题比如先验概率很低时的贝叶斯后验概率计算这类题很容易出成迷惑项。机器学习方面不需要深抠算法推导但要把评估指标、过拟合手段、特征工程的基本概念搞透尤其要理解它们在类别不平衡样本下的表现差异。业务分析方面留存率下降、点击率上升但转化率下降、AB实验评估、漏斗分析这四类题是最常见的case题类型。建议平时多拆解一些自己身边的App案例练习从数据现象反推业务问题的能力。5.2 从笔试到面试的衔接准备笔试通过后一般会进入面试环节笔试中的案例分析题经常成为后续面试的延伸话题。比如我当时笔试里写的推荐策略留存分析面试时被追问了“如果让你设计一个实验来验证你的假设你会怎么做”所以笔试时不要只背模板要真正理解自己写的内容能够在追问中展开细节。另外一个容易被忽视的点是笔试时要注意留痕和记录。我通常会在草稿纸上写下每道题的解题思路即使最后答案没写完也能在面试时回忆起当时的思考过程和面试官深入讨论。大数据岗的面试非常看重思维过程完全复制背诵的经验有时候反而不如自己独立思考的痕迹更有说服力。5.3 心态调整与应试策略最后聊点务实的。第二批笔试时间安排在4月中旬很多同学已经经历了多场笔试状态可能有些疲惫。我的建议是把每场笔试都当作一次真实的数据分析项目而不是单纯的考试。拿到题先通读一遍判断哪些题能拿分哪些题需要攻坚不要因为某道题卡住就乱了节奏。时间分配上我的经验是选择题每道不超过2分钟如果一道题超过3分钟还没思路就标记跳过最后有时间再回头。案例分析题如果你能提前半小时做到那么时间相对充裕可以写得更有条理。SQL题如果第一版写出来运行报错不要慌先检查是不是表名或字段名写错了这种低级错误最常见。我在实际参加小红书第二批笔试的过程中发现牛客网的环境整体比较稳定但SQL题的运行耗时有时候会波动如果SQL写得比较复杂跑批时间可能较长。建议大家提前在牛客网熟悉一下在线编程环境至少要知道编译报错时怎么看日志避免上了考场被环境问题干扰心态。总的来说2024年春招小红书数据岗第二批笔试的难度属于中上水平既考察基本功也考察业务理解。如果你能系统掌握SQL窗口函数、统计推断基础并且熟悉内容社区类产品的数据分析思路拿到面试资格并不难。难的是在有限时间内把案例分析题答到点子上这需要平时多积累、多拆解、多复盘。希望这篇复盘能给你提供一些参考祝你也顺利拿下心仪的offer。
