2024春招小红书数据岗笔试复盘题型拆解、思路还原与避坑实录每年三月底到四月初是互联网大厂数据岗春招笔试最密集的时候。我今年参加了小红书2024年春招数据岗的第一批笔试从投递简历到收到笔试通知中间隔了大概一周整体节奏属于常规操作。这里先把结论放在前面小红书的笔试风格和我之前刷题刷惯了的牛客网SQL题库很不一样它更侧重业务理解和数据敏感度的考察SQL只是基础门槛真正拉开差距的是案例分析题。如果你是冲着数据研发岗去的可能觉得卷子偏业务但如果目标是数据运营或者偏策略的数据分析这套题出得很有水平。这篇内容我会把当时的笔试流程、四类题型的答题思路、我在现场的真实做题记录以及考完之后复盘发现的坑全部整理出来。无论你正在准备互联网数据岗位的春招补录还是打算在秋招提前批试水都可以拿这份复盘当参考。特别是那些平时只刷LeetCode和SQL题的考生我建议认真看看笔试里业务题的部分——那才是小红书筛人的核心分水岭。1. 笔试整体设计与考查逻辑1.1 考试形式与基本信息先说客观情况。我收到的是线上笔试用的牛客系统全程双机位监控手机支架放在侧后方电脑摄像头正对脸部。总时长90分钟题目量是4道大题的组合其中有3道SQL编程题、1道综合案例题案例题内部又嵌套了概率计算和Python小问。整张卷子没有选择题和填空题全部需要手写代码或手打分析文本。时间分配是很多人会踩的坑。90分钟看起来不算紧张但实际题目本身并不少尤其是第4道综合题光读题材料就有两页多。我按照自己的习惯拿到卷子先花2分钟做了个全局浏览心里给4道题排了个优先级最后的时间分配大概是SQL系列35分钟、概率小问10分钟、Python数据操作15分钟、综合案例25分钟、余下5分钟检查。有个细节要提醒牛客系统的在线SQL编辑器和本地IDE不一样它不会给你表结构提示字段名全靠自己从题目描述里提炼。平时如果只在本地数据库环境里刷题建议提前去牛客或者赛码的在线题库适应一下这种“裸写”状态。1.2 四类题目的比例和背后逻辑从题目占比看SQL仍然是重头但已经不是绝对主导。整场笔试的赋分权重大概是SQL占40%业务案例分析占30%Python数据处理占15%概率统计占15%。这个结构其实很能说明问题小红书的分析团队对SQL能力的要求是“够用就行”不需要你写多复杂的递归或正则但业务问题上需要你能快速理清分析框架并且给出可以落地的策略方向。这和岗位本身的特点有关系。小红书的业务形态是“内容社区电商”它下面所有数据分析场景都建立在内容推荐、用户增长、商业变现这三驾马车上。数据分析师日常做的工作更多是对业务指标的异常波动做归因、对策略上线效果做评估、对用户分层运营提出建议。这些工作能力很难用一道复杂的SQL题来招聘筛选反而是“给你一个业务场景你自己拆解关键指标”这种开放性问题更容易看出候选人是否具备数据思维。我当时在草稿纸上记了一句话“SQL决定你能不能进门业务思维决定你能不能坐下。”考完回头看这句话基本准确。1.3 小红书数据岗笔试的选人偏好从题目设计能明显感受到小红书数据团队的一些偏好其中最突出的一点是对指标的定义敏感度要求很高。同一个概念比如“互动率”不同公司的口径可能完全不同。小红书语境下互动一般指点赞、收藏、评论、分享四类行为的总和互动率的分子是这四类行为去重用户数或行为总数分母通常是笔记的曝光量或阅读量。笔试题目里给出的语境是什么答的时候就要按它的语境来不能机械地套用自己公司的老口径。第二点是强调对内容生态的理解。小红书是个双端内容平台供给侧是创作者需求侧是普通用户。数据岗面向的业务方可能是内容运营团队也可能是社区治理团队也可能是商业化团队。笔试案例题虽然没有直接问“如果你是内容运营你会怎么分析”但题目里埋了很多关于内容分发、内容竞争、长尾笔记的引子本质上还是在考察你是否理解内容平台的运转逻辑。第三点是文字表达能力。综合案例题的最后一个小问明确要求“写出你的分析思路和落地建议300字以内”。这300字实际上是在看你能否把数据结论翻译成业务语言。我身边有不少朋友技术能力很强但在这个小问上只写了干巴巴的几句“用XX模型看XX指标”没有给出具体的策略方向最后拿到面试通知的比例确实不高。2. 核心题型详细拆解与实操要点2.1 SQL题从表结构到解题步骤SQL题一共三道难度递进。第一道是基础聚合题第二道是留存计算题第三道是排名的变体。题目设置的原始表结构我大概还原一下笔试现场实际也是三张表。用户表 user字段: user_id, reg_date, device_tag, city_level笔记表 note字段: note_id, author_id, publish_date, topic_id互动行为表 interaction字段: note_id, user_id, action_type, action_time。其中action_type包括 click、like、collect、comment、shareclick在小红书的业务语境里可以理解为曝光后的点击阅读行为。第一道题要求统计2024年1月1日到1月31日期间每天发布笔记的活跃作者数以及人均发布笔记数按日期升序输出。这题考的是date和聚合的基本功难点在于需要先筛选作者范围。我当时写的是SELECT publish_date, COUNT(DISTINCT author_id) AS active_author_cnt, COUNT(note_id) * 1.0 / COUNT(DISTINCT author_id) AS avg_note_per_author FROM note WHERE publish_date BETWEEN 2024-01-01 AND 2024-01-31 GROUP BY publish_date ORDER BY publish_date;这里有个细节值得说就是人均笔记数为什么不直接写成COUNT()因为如果note表里note_id是主键COUNT()和COUNT(note_id)等价但写成COUNT(note_id)语义更清晰。另外COUNT(DISTINCT author_id)除以它自己这种写法在有些数据库里整数相除会得到整数所以我在分子上乘了1.0保证结果是小数避免0/1这种尴尬。这种小细节面试官其实是能看到的。第二道题是典型的留存计算统计2024年2月注册的新用户中各渠道device_tag的次周留存率留存定义是注册后第8天到第14天内只要有任意互动行为就算留存。这题我当时花了比较多的时间因为它要求有两层筛选先找到2月注册用户再判断他们在2月8日到2月21日之间有没有互动记录。核心SQL是这样的WITH register_users AS ( SELECT user_id, device_tag, reg_date FROM user WHERE reg_date BETWEEN 2024-02-01 AND 2024-02-29 ), retained_users AS ( SELECT DISTINCT ru.user_id, ru.device_tag FROM register_users ru INNER JOIN interaction i ON ru.user_id i.user_id WHERE i.action_time DATE_ADD(ru.reg_date, INTERVAL 7 DAY) AND i.action_time DATE_ADD(ru.reg_date, INTERVAL 14 DAY) ), weekly_reg AS ( SELECT DATE_FORMAT(reg_date, %Y-%u) AS week_num, device_tag, COUNT(DISTINCT user_id) AS reg_cnt FROM register_users GROUP BY DATE_FORMAT(reg_date, %Y-%u), device_tag ) SELECT r.week_num, r.device_tag, r.reg_cnt, COUNT(DISTINCT t.user_id) AS retained_cnt, ROUND(COUNT(DISTINCT t.user_id) * 1.0 / r.reg_cnt, 4) AS retention_rate FROM weekly_reg r LEFT JOIN ( SELECT ru.user_id, ru.device_tag, DATE_FORMAT(ru.reg_date, %Y-%u) AS week_num FROM register_users ru WHERE EXISTS ( SELECT 1 FROM interaction i WHERE i.user_id ru.user_id AND i.action_time DATE_ADD(ru.reg_date, INTERVAL 7 DAY) AND i.action_time DATE_ADD(ru.reg_date, INTERVAL 14 DAY) ) ) t ON r.week_num t.week_num AND r.device_tag t.device_tag GROUP BY r.week_num, r.device_tag, r.reg_cnt ORDER BY r.week_num, r.device_tag DESC;实际上笔试题没有要求按自然周分桶它只要求按device_tag维度输出。我当时写这个SQL时CTE写得有点冗余但核心逻辑是对的用DATE_ADD在行级别判断每个注册用户自己的次周窗口而不是全局硬编码一个日期范围这很重要。很多考生容易犯的错误是看到“第8天到第14天”就直接写一个固定区间比如2024-02-08到2024-02-21但这样会把2月底注册用户的窗口期算错。正确的姿势一定是行级别的相对日期比较。第三道题是排名的变体找出2024年3月每个话题topic_id下互动量最高的Top 3笔记互动量点赞数收藏量评论数展示topic_id、note_id、互动量和排名。这题我用了窗口函数ROW_NUMBER()因为要的是“每个话题下排名前三”所以PARTITION BY topic_idORDER BY interaction_cnt DESC。要注意的是并列问题如果两个笔记互动量相同ROW_NUMBER()会随机给一个排名这可能导致结果不稳定。稳妥的写法是WITH daily_note_stats AS ( SELECT n.topic_id, n.note_id, COUNT(CASE WHEN i.action_type IN (like,collect,comment) THEN 1 END) AS interaction_cnt FROM note n LEFT JOIN interaction i ON n.note_id i.note_id WHERE n.publish_date BETWEEN 2024-03-01 AND 2024-03-31 GROUP BY n.topic_id, n.note_id ), ranked AS ( SELECT topic_id, note_id, interaction_cnt, ROW_NUMBER() OVER (PARTITION BY topic_id ORDER BY interaction_cnt DESC) AS rn FROM daily_note_stats ) SELECT topic_id, note_id, interaction_cnt FROM ranked WHERE rn 3;2.2 概率统计贝叶斯和幂律分布的应用概率统计这部分是嵌在案例题里的小问但出得非常接地气。题目大意是平台有90%的笔记是普通内容10%的笔记是优质内容。优质内容被系统推荐的概率是60%普通内容被推荐的概率是20%。现在有一条笔记被推荐了问它属于优质内容的概率是多少。这就是一个标准的贝叶斯公式题设真率P(优质)0.1P(推荐|优质)0.6P(推荐|普通)0.2被推荐条件下是优质内容的概率为(0.60.1)/(0.60.10.2*0.9)0.06/0.240.25。很多备考的同学问我笔试里的概率题到底要怎么准备跟学校里的概率论有什么区别。说实话原理层面没什么区别就是条件概率和贝叶斯公式的灵活运用但小红书的概率题喜欢把场景包装成“推荐、曝光、热门、冷启动”这类内容平台术语。所以大家在复习时重点不是抠偏题怪题而是把常见的互联网业务场景比如点击率预估、留存率计算、AB实验显著性判断用概率语言表达出来。另一道相关的概率小问是某品类笔记的互动量近似服从幂律分布8%的头部笔记占据了平台互动总量的65%如果随机抽取100篇笔记求其中头部笔记数量的期望值。这个其实是个二项分布头部笔记占比8%样本量100期望就是8篇。题目本身不复杂但如果你不了解幂律分布里“头部效应”这个概念光看题目可能就会懵住。针对这类题我建议在备考时把以下概念过一遍贝叶斯公式、二项分布与泊松分布的期望方差、极大似然估计思想、AB测试里显著性和样本量计算。小红书笔试的概率题不会考到推导证明的层面能算对数字就算达标。2.3 Python数据处理基于pandas的长尾聚合Python题部分给了一段模拟的笔记曝光数据CSV格式大约几千行要求完成三件事第一读入数据第二按话题计算笔记的平均曝光量并按降序输出前10个话题第三筛选出曝光量超过均值两倍的“爆文”笔记并输出这些爆文在各话题的分布数量。这就是日常工作中很常见的长尾数据分析场景。我在笔试里用了pandas整体代码大约20行import pandas as pd df pd.read_csv(data.csv) topic_avg df.groupby(topic_id)[exposure_count].mean().reset_index() topic_avg.columns [topic_id, avg_exposure] topic_avg topic_avg.sort_values(avg_exposure, ascendingFalse).head(10) mean_exp df[exposure_count].mean() df[is_hit] df[exposure_count] 2 * mean_exp hit_count df[df[is_hit]].groupby(topic_id)[note_id].count().reset_index() hit_count.columns [topic_id, hit_note_cnt] hit_count hit_count.sort_values(hit_note_cnt, ascendingFalse)这一部分有几个容易踩的细节。第一读取CSV时要注意编码笔试平台提供的数据文件通常是UTF-8但有的机考系统默认会用GBK去读导致中文列名乱码。稳妥做法是pd.read_csv(data.csv, encodingutf-8)出错再换encodinggbk。第二“曝光量超过均值两倍”这里的均值是全量笔记的均值不是话题内的均值题目很容易读岔。我在考场就专门把这句话圈了出来确保没有理解错。第三点是代码洁癖问题。笔试阅卷通常不会真的去跑你的代码而是人工看思路所以变量命名是否清晰、注释是否到位、中间结果有没有打印这些都会影响评委对你的印象。我用reset_index()重命名列就是为了让输出的结构清晰可读。2.4 综合案例分析指标异动归因和策略建议最后是整张卷子的重头戏一道关于“收藏率下降”的综合案例题。题目给了两段背景材料大意是2月中旬开始平台整体笔记的收藏率收藏次数除以阅读次数连续三周环比下降降幅从第一周的3%扩大到第三周的8%。同期点赞率基本稳定评论率略有上升分享率小幅波动。请依次回答三个问题第一请列出你怀疑的可能原因至少给出三个方面第二假设你在分析时发现收藏率的下降集中在“低粉作者”粉丝数低于500的内容上且这些内容的曝光结构发生了变化请继续归因第三基于以上分析给出你的数据监控方案和业务策略建议300字以内。这道题几乎没有标准答案但它的评分重点在于分析框架是否系统、归因思路是否落地、策略建议是否可执行。我的回答框架大致是先拆指标收藏率收藏次数/阅读次数分子下降或分母上升都会导致比率降低。从外部环境看可能是季节性因素比如春节后用户行为习惯变化从内容供给看可能是内容类型结构发生了变化比如低价值生活记录类笔记占比提高从分发机制看可能是推荐算法调整导致收藏率低的笔记获得了更多曝光从产品机制看可能是收藏功能或收藏夹产品改版用户收藏行为路径变长。第二个小问给了一个非常重要的线索说“收藏率的下降集中在低粉作者内容上且曝光结构发生了变化”。这其实是在提示你不要停留在泛泛而谈要关注“曝光结构变化”和“收藏率下降”之间的因果关系。我的判断是平台可能在2月中旬调整了低粉作者内容的流量分配策略给低粉作者增加了曝光尤其是推荐页信息流里的曝光。低粉作者的粉丝基数小收藏动机天然弱于高粉作者当这些内容的曝光占比扩大时整体收藏率被稀释这是典型的辛普森悖论——每一个细分人群的收藏率都可能没怎么变但整体比率变了因为人群占比变了。为了验证这个假设我给出的方案是把收藏率的拆解维度细化不只是看整体而是分别计算“高粉作者内容收藏率”和“低粉作者内容收藏率”再看看低粉内容曝光占比从1月到2月的变化。如果高粉内容收藏率稳定、低粉内容收藏率稳定但整体下降那几乎可以锁定是曝光结构变化导致的。策略建议方面我写了三点第一建立收藏率健康度的分层监控看板按作者粉丝量和内容话题两个维度拆分监控曝光占比和收藏率的联合变化第二对低粉作者的流量扶持策略做一次复盘结合收藏率、阅读时长、点赞率综合评估内容质量避免单一指标牵引导致收藏率下滑第三在推荐算法中引入“收藏预期”作为辅助排序信号对收藏倾向高的内容给予适当加权同时关注评论率的变化避免过度优化收藏率伤害用户体验。这种题说到底是考察你“会不会做分析”而不只是“会不会计算”。我的心得是回答时一定要把“数据表现—假设拆解—验证方案—业务落地”这条链走完哪怕每一个环节都写得相对简短也比只堆砌一个华丽但不落地的假设强。3. 实操过程与核心环节实现3.1 考前一周的准备工作坦白说我并不是在收到笔试邮件之后才开始准备的。春招的考验期是年前年后就开始了从1月份我就陆续在刷SQL题和业务分析框架。收到小红书笔试通知后我花了大概三天时间做了针对性准备这三天做的事情基本可以给后来人直接抄作业。第一把SQL窗口函数和CTE语法完整过了一遍。小红书笔试里SQL题出现排名、留存的可能性很高所以我把ROW_NUMBER()、RANK()、DENSE_RANK()的区别理清楚了顺便把LAG/LEAD在时间序列题里的用法也复习了一遍。第二整理了两个分析框架一个是“指标异常波动归因框架”套路是先拆指标公式再按外部环境、内容供给、用户需求、产品机制、技术bug五个维度做假设排查另一个是“内容平台分析框架”核心包括内容生产—分发—消费—互动这个闭环上的所有关键指标。第三把小红书的核心功能过了一遍尤其是关注页、发现页信息流、搜索页三条内容分发场景的区别以及收藏夹、薯条推广这类特色功能在产品生态里的位置。这些准备工作不是临时背题而是为了在笔试现场省下“理解题干业务背景”的时间。事实证明因为提前了解了收藏夹功能是小红书内容消费的重要场景我在做综合案例题时对“收藏率”这个指标的业务含义理解得更到位答起来思路也更顺。3.2 现场答题时间线和决策过程笔试当天我提前半小时进了系统测试了摄像头、麦克风、屏幕共享是否正常把手机监控的支架调好位置。这里提醒一下牛客笔试系统要求从点击开始答题到交卷全程保持手机监控在线中途切断可能会被判违规所以手机电量一定要提前充满最好同时插着充电宝。进场后我按照之前说的流程先花2分钟扫了全部4道题的题干在草稿纸上快速标注了每道题的考点和预估耗时。扫完题的那一刻我做了两个判断第一SQL第一题和第三题比较常规可以快速做掉第二SQL第二题需要CTE逻辑相对复杂放在最后做比较稳妥。综合案例题虽然篇幅最长但因为它不需要精确的代码对错只要框架合理、文字通顺就能拿分所以我把它排在所有人机交互题目之后。实际答题顺序是SQL第一题8分钟→ SQL第三题10分钟→ Python数据操作15分钟→ 综合案例25分钟→ 概率小问10分钟→ SQL第二题15分钟→ 检查7分钟。这个顺序是刻意设计的核心逻辑是先把容易拿分的题拿到手再回头啃硬骨头。很多同学喜欢按题目顺序一路做下去结果卡在第二题留存计算上等做到后面的Python题时时间已经不够了。这是笔试的大忌。3.3 一道经典“留存计算”的完整解构这里重点讲讲SQL第二题因为它是笔试题里最可能区分高分和低分的一道题。题目要求统计各渠道的次周留存率口径是注册后第7天到第14天内有互动行为。很多考生第一反应是做一个“注册用户表LEFT JOIN互动表”然后统一判断“action_time大于注册时间7天且小于注册时间14天”但实际操作中会发现互动行为可能有多条直接JOIN会产生数据膨胀导致留存人数被高估。正确姿势是要么在JOIN前先用EXISTS去重要么在JOIN结果上再COUNT(DISTINCT user_id)。我当时用了EXISTS子查询的方式因为EXISTS在每个用户遇到第一条满足条件的记录后就停止扫描性能上通常优于先JOIN再DISTINCT。笔试环境下数据量不算大两种写法在运行时间上没有明显区别但EXISTS写法语义更严谨也能避免潜在的行重复。还有一个容易忽略的细节是留存窗口到底怎么算。注册当天是第0天还是第1天题目里说“注册后第8天到第14天内”按照常见口径注册当天应该算第1天所以第8天到第14天对应的是注册后经过7天到13天的时间段。我在SQL里写的INTERVAL 7 DAY到INTERVAL 14 DAY实际上是把注册当天当作第1天后再顺延了7天。但如果题目自身有严格定义一定要以题目为准我只是在这里说明我自己的理解方式。3.4 综合案例题的答案组织技巧综合案例题对很多理工科背景的同学来说最容易出现的问题是“有思路但写出来很散、很跳跃”。我个人的经验是在动手写答案之前先在草稿纸上把回答框架简单列出来用“1.1 指标拆解→1.2 假设列表→1.3 验证方案→1.4 策略建议”这样的结构组织。落笔时按顺序写不要想到哪写到哪。字数限制是300字以内所以每一条都得直击要害。我的策略是第一句话点明“收藏率收藏次数/阅读次数收藏次数的下降或阅读次数的上升都可能导致该比率下滑”让阅卷人一眼看出我的分析起点。然后每个假设只用一句话描述最后一小段集中给策略建议。这种高度结构化的回答不一定是最有创意的但一定是阅卷成本最低、最容易拿分的。4. 常见问题与排查技巧实录4.1 我看过的“翻车现场”和低级失误先说一个发生在我身边比较常见的失误有同学考前的SQL刷题基本在LeetCode上用的执行环境是MySQL 8.0但笔试平台用的是Hive SQL两者在字符串函数、日期函数上有很多差异。Hive里日期加减用的是DATE_ADD(reg_date, 7)而MySQL 8.0里既支持DATE_ADD(reg_date, INTERVAL 7 DAY)也支持DATE_ADD(reg_date, 7)的简写。如果平时没接触过Hive考场上遇到时间处理题会花很多时间去试语法这非常浪费考试时间。第二个常见问题是Python环境的库缺失。我记得笔试系统里Python环境是预装pandas和numpy的但不能安装新包。如果你平时习惯了pandas.read_excel()但笔试数据文件格式是CSV就需要现场调整代码。最好的办法是考前在牛客真题里做一两次模拟确认环境里有哪些库、数据文件是怎么挂载的、输出需要什么格式。第三个问题是综合案例题没有写结论。有些同学在问题上洋洋洒洒写了三个假设、四种验证方法但到最后都没有给出一个“所以呢”的结论也没有业务建议。这类答案在技术面可以及格但在数据岗笔试里很容易被扣分因为数据分析的最终输出是帮助决策不是罗列可能性。4.2 考后复盘哪些题最值得深挖考完笔试后的第一时间我没有急着对答案而是把整张卷子的题目和我的答题思路记录下来然后做了两轮复盘。第一轮复盘是看技术题。SQL第三题我当时用的是ROW_NUMBER()但复盘时我意识到如果题目要求“展示所有进入Top 3的笔记包括并列”那么ROW_NUMBER()就不能满足需求应该换成RANK()或DENSE_RANK()。当时题目原文用的是“互动量Top 3笔记”没有明确说明并列怎么处理我选了ROW_NUMBER()确实存在风险。如果下次遇到类似题目我建议在答案里加上一行注释比如“当互动量并列时仅保留系统随机返回的一条”如果并列都要展示就改用RANK()。这样阅卷人会觉得你想得周全而不是机械地套函数。第二轮复盘是看业务题。我当时对“收藏率下降”的归因主要集中在曝光结构变化和低粉作者内容供给增加上没有谈到季节性因素。但2月中旬正好是春节假期到节后返工的过渡期用户活跃时段和内容消费类型都会有明显变化这一块完全可以作为外部环境因素补充进去。业务分析题的回答没有满分只有在复盘时不断补全假设空间才能在下一场笔试里答得更好。4.3 给准备春招/秋招的读者几个实用建议根据这次小红书笔试的体验结合我之前参加过其他大厂数据岗笔试的经验我整理了几条实操性的建议。第一笔试前一定要做一次“信息侦查”。去牛客、小红书本身、社交平台上查一下这家公司这个岗位近半年的笔试面经尤其是今年的题型是否发生了变化。比如小红书2023年秋招的笔试还主要是SQL基础统计2024年春招明显加重了业务案例的比重如果你还按照去年的题型去准备就会吃大亏。第二SQL题要准备“窗口函数CTE”组合拳。我在三场互联网公司数据岗笔试里都碰到了窗口函数相关题目。这不只是说考点热门而是窗口函数在处理“排名”“同环比”“分组TopK”“连续时间问题”上确实比普通GROUP BY高效很多。熟练掌握ROW_NUMBER()、RANK()、LAG()、LEAD()、SUM() OVER()这五个窗口函数基本可以覆盖90%以上的笔试题目。第三概率统计不要只看书上的公式要多联系业务场景。刷题时把“推荐”“曝光”“点击”“转化”“留存”这些词和随机变量、分布、条件概率联系起来形成条件反射。比如看到“曝光量”就联想起流量、样本量、显著性看到“转化率”就联想起二项分布和置信区间看到“留存”就联想起似然函数和生存分析。这种“场景—公式”的映射关系越熟练在考场上解题速度就越快。第四案例题的练习要“开口写而不是只在脑子里想”。我强烈建议在练习时把每个业务分析题的答案控制在300字左右模拟笔试的字数限制训练自己用最精炼的语言说清楚分析框架。不要觉得写字麻烦这一步非常值得。我身边一个朋友笔试前一周专门做了这种限时练笔笔试时业务题写得又快又齐整顺利拿到了面试机会。最后再分享一个小技巧机考交卷前如果时间允许把每道题的代码或答案都在系统里跑一遍至少确认没有语法错误。如果某个小问没有做出来也千万别让答题区空着写上思路或伪代码例如“这里应该在JOIN前先去重用EXISTS子查询避免数据膨胀”阅卷人大概率会给你步骤分。数据岗笔试和数学考试一样过程分很重要空着就一定没分写了至少还有机会。我个人在这次笔试里最深的体会是小红书这批笔试的难度不在于题目本身有多深而在于它对你“数据思维”的考察是全方位、多角度的。SQL能练、概率能背、Python能刷但业务案例题能不能答到点子上真的取决于你对内容平台的理解深度。如果你现在还在准备阶段建议从今天开始多拆解一些内容型产品的业务指标体系多想想每个指标波动背后可能的原因而不是只刷题。等到笔试那天你会发现这些思考真的能帮到你。