最近后台一直有人问校招笔试的事尤其数据分析岗很多人拿着小红书2020校招数据分析笔试题卷三来找我对答案。这套题虽然那年考过但里面的考点到现在依然是主流甚至可以说它把“数据人到底该会什么”这件事讲得很清楚。今天我就按这套卷子的实际结构把考察重点、解题思路、失分点一条条拆开讲顺便聊聊这类笔试题背后的出题逻辑给正在准备校招、跳槽或者自学数据分析想检验水平的朋友一份可以直接参考的复盘笔记。小红书是内容社区产品它的数据分析师每天面对的问题核心就是三件事内容怎么分发、用户怎么增长、社区怎么变现。围绕这三个业务方向数据岗位的笔试题非常务实不考偏题怪题但考得很细。卷三里几乎没有纯背诵类题目全是给你一张表、一个指标、一个业务问题让你用数据和逻辑去回答。这种风格代表了互联网公司数据分析笔试的主流方向SQL是基本功统计学是底层逻辑业务分析是最终落点。1. 试卷整体结构与考点分布拿到一套笔试题我建议大家先别急着做题先花五分钟扫一遍整体结构看看每个题在考什么能力。这比埋头刷题重要得多因为看懂出题结构你才能判断自己哪块是短板。1.1 题型构成与考察能力对照根据对这套卷子的综合复盘卷三的题型大致可以分为四类SQL题目、统计学基础题、业务分析题、开放型产品分析题。整体时长通常在90到120分钟题量不大但每道题都需要写清楚过程时间其实是偏紧的。第一类是SQL题一般占比在30%左右核心考察取数能力。社区产品常用的表无非就是用户表、内容表、互动表、关注关系表题目通常会让你统计日活、留存、内容发布量、互动率这类指标。注意这里考的绝不是简单select而是多表关联、去重计数、窗口函数、时间维度对比这些实战中天天用的操作。第二类是统计学基础题核心考察概率论和假设检验。比如AB测试怎么做、显著性怎么看、置信区间怎么理解还有常见的贝叶斯公式题目。这类题看起来偏理论但对做数据的人来说这是最基本的判断依据。第三类是业务分析题这类题是整张卷子最核心的部分。通常会给你一个业务现象比如“小红书的收藏量上升但点赞量下降”让你分析可能的原因、给出验证方法、提出解决方案。这种题没有标准答案考的是分析框架和业务敏感度。第四类是开放型产品分析题比如估算类问题或者让你设计一个指标体系。这部分重点看思路不要求你答得完美但要求你答得有逻辑层次。1.2 和小红书业务场景的对应关系这张卷子最大的特点是大量题目都围绕内容社区的核心场景展开。你不需要知道小红书的任何内部数据但你必须理解内容产品的运行逻辑。举几个典型的业务场景内容发布与审核链路、推荐系统的曝光与点击、用户关注与取关、搜索关键词与结果页点击、电商笔记的商品转化。这些场景在数据分析日常工作中会反复出现所以笔试题实际上是在模拟未来的工作场景。比如有一类高频题是“一个指标下降了你怎么排查”这类题在小红书场景下就非常典型。社区产品指标众多浏览量、人均时长、互动率、留存率相互影响指标波动的原因可能来自推荐策略调整、内容供给变化、用户结构变化、节假日效应、甚至客户端bug。这种题目拿到卷面上你光知道“我要分析原因”是不够的必须给出具体的拆解路径。很多非社区产品背景的考生做此类题会觉得无从下手本质原因是缺少对内容产品运行机制的直观理解。我的建议是准备这类题之前先去把小红书、抖音、B站这类产品的核心链路完整梳理一遍从用户打开App到发布内容、浏览内容、产生互动每一步会产生哪些数据哪些指标可以衡量这个环节的健康度把这套逻辑想清楚再做业务题会顺手很多。2. 高频题型拆解与答题框架一套题做得顺不顺取决于你对高频题型是否有稳定的答题套路。这里说的套路不是死记硬背而是遇到这类题时知道从哪些维度下手。下面我把卷三里出现频率最高的几类题逐一拆解。2.1 SQL题不要只会写还要写出效率SQL题在数据分析笔试中几乎是必考项卷三也不例外。但需要注意由于笔试环境通常只给你表结构和题目描述没有真正的执行环境去验证所以你写的每一句代码都要逻辑严密不能靠“大概是对的”来蒙混。常见的SQL考察点包括多表join时如何处理重复数据统计去重活跃用户数时是count(distinct user_id)还是先group by再count用窗口函数计算每个用户的连续登录天数或内容发布间隔用date_diff或timestampdiff做日期计算case when做多条件分组统计。有一个容易被忽略的考点是null值的处理。很多人在写left join之后不关注右表的空值情况导致统计出的结果偏差很大。笔试题里如果出现“统计用户发布内容数量”这种看似简单的题一定要想到有的用户没有任何发布记录left join之后发布数会是null需要用ifnull或coalesce函数转成0否则平均数会被算错。另外窗口函数的写法在笔试题里特别容易暴露水平。比如“计算每个用户最近一次发布内容距今天数”你先要用row_number() over(partition by user_id order by publish_time desc)给每条内容排序然后取rn1。这种题刷多了就能形成条件反射但如果你只会group by这类题就很难做出来。2.2 统计学题从公式记忆到推导能力的转变统计学部分的题量和难度在不同年份有差异但卷三明显更注重对统计思维的考查而不是单纯套公式。AB测试的题目是重点。比如给你一组实验数据实验组转化率3.2%对照组转化率2.8%问你结论是否显著。这时候你不仅要会算p值还要能解释为什么不能直接看数值就下结论样本量多大、方差波动如何、置信区间是多少、是否存在多重比较问题这些都是面试官想看到的分析深度。还有一类概率题比如用贝叶斯公式计算用户是高质量内容作者的概率。一开始看到这种题我也有点懵但后来想明白了社区产品做内容质量识别时本质上就是在做分类任务根据用户行为特征计算其属于优质创作者的条件概率。理解这个应用背景再去看公式就没有那么抽象了。统计学这块的复习我建议大家把重心放在假设检验的流程上先明确原假设和备择假设再计算检验统计量得到p值结合业务阈值下结论。这套流程看似简单但很多人到面试现场一紧张就忘了说原假设直接报结果这在笔试和面试中都会严重扣分。2.3 业务分析题拿分关键是结构不是答案如果说SQL和统计靠硬功夫业务分析题则靠结构化思维。小红书这类公司的业务分析题往往没有唯一答案阅卷人看的是你的逻辑线是否完整。比如一道典型的业务分析题“某天小红书笔记的收藏量显著增长但点赞量没有变化请分析原因并验证你的假设。”这类题你如果上来就说“可能是因为收藏按钮改版了”就废了。正确的打开方式是从内部因素和外部因素两个维度做拆解。内部因素包括功能改版、推荐策略变化、内容供给结构变化、文案引导变化等。外部因素包括竞品动态、热点事件、节假日、舆论环境等。每个因素下面你还要说清楚用什么数据来验证。比如说“如果是推荐策略导致更多长尾内容曝光那么收藏率上涨的同时笔记曝光结构应该发生变化可以通过内容分层的曝光数据来验证”。在答题结构上我习惯用MECE原则把原因分尽然后对每种原因给出数据验证方案。这样写出来的答案即使结论不是面试官心里的那个也能拿到大部分分数。2.4 开放题估算与指标设计的思路展示开放题在笔试中占比不大但属于区分度很高的题目。卷三里的开放题主要集中在两类一类是费米估算题比如估算小红书上一天的笔记发布量另一类是设计类题目比如给内容社区设计一套创作者健康度指标体系。做估算题关键不是答案的精确度而是逻辑链条的合理性。初看这类题感觉没法下手但你先从人口总数出发拆出小红书目标用户规模再乘渗透率再乘发布频率逐步细化每一步的假设都说明理由。即便最终数字和真实情况有偏差但你的推演过程是完整的这就能拿到分。设计指标体系这种题重点在于展现你对业务的理解。创作者健康度不能只写“活跃度”一个指标你要围绕发布、互动、涨粉、变现几个环节分别设计。发布环节看发布频次和内容质量分互动环节看赞藏评转数据涨粉环节看粉丝增长率和粉丝粘性变现环节看笔记带货转化率和商单接洽率。最后还要提一下北极星指标是什么以及各指标之间的优先级怎么排。这样回答就给面试官一个完整的业务视角。3. 几类典型真题的解题复盘这一节我们直接走进题目本身用具体例子还原做题时的思考过程。虽然2020年的原题原文我手里已经找不全了但根据当年考生的集中反馈和网上流传的讨论帖核心题型的风格是稳定的我按同类型真题来复盘思路是一样的。3.1 SQL真题统计社区活跃作者的留存情况有一道SQL题大概是这样的有用户信息表user_info和内容发布表content_info求每个用户首月发布内容后的次月留存情况。这道题综合性很强既考去重又考时间计算还考留存定义。我的推导步骤是先找出每个用户第一次发布内容的月份作为其“首月”再统计该用户次月是否发布内容如果发布了记1否则记0最后按首月分组计算整体留存率。with first_month as ( select user_id, date_format(min(publish_date), %Y-%m) as first_month from content_info group by user_id ), next_month_act as ( select distinct user_id, date_format(publish_date, %Y-%m) as act_month from content_info where date_format(publish_date, %Y-%m) date_format(date_add(min(publish_date), interval 1 month), %Y-%m) ) select first_month.first_month, count(distinct first_month.user_id) as new_author_cnt, count(distinct next_month_act.user_id) as retained_author_cnt, count(distinct next_month_act.user_id) / count(distinct first_month.user_id) as retention_rate from first_month left join next_month_act on first_month.user_id next_month_act.user_id group by first_month.first_month;这里有一个很关键的细节next_month_act子查询中的min(publish_date)是每个用户的全局首次发布时间不能直接在where中使用聚合函数我的写法只是帮你理解逻辑在真正可执行的SQL里你需要用子查询先求出全局首次发布月份再关联。这个细节如果笔试时没注意很容易写出语法错误。另外date_add在跨年时是安全的所以你可以放心用它计算“次月”。这道题的失分点主要在两个地方一是没有对user_id去重导致用户多个月发布记录被重复计数二是在where子句中直接使用聚合函数。大家平时写代码如果有条件一定要多跑一跑语法错误是最亏的丢分。3.2 业务分析真题内容feed流人均时长下降这道题是典型的“指标异动分析”。题目给了背景最近一周App的人均使用时长持续下降尤其feed流模块下降明显让你定位原因并提出建议。这种题我非常推荐用“三层拆解法”来组织答案。第一层拆用户是哪些用户群的使用时长下降了是新用户还是老用户是安卓端还是iOS端是不同城市等级之间有差异吗用维度下钻的方式找到下降群体。第二层拆场景是打开App的次数变少了还是每次使用时长变短了如果是每次用完就退出那大概率是内容匹配问题如果是打开频次掉了可能是推送、入口或者外部竞争。第三层拆供给最近内容供给是否有变化比如优质内容发布量下降、审核策略调整导致内容池变窄、推荐算法更新导致兴趣匹配度下降。这三层并非孤立分析而是层层递进先确定下降发生在谁身上再判断发生在哪个使用环节最后追溯供给和策略的变化。在笔试题里拿出这样的框架再配上对应的数据表和监控报表已经算是高分回答了。3.3 指标设计真题为搜索功能设计指标体系搜索功能是小红书这类社区产品的核心流量入口之一卷三也有围绕搜索的分析题。题目会让你设计一套搜索功能的数据指标体系。初级答案会写搜索次数、搜索用户数、搜索结果点击量但这是远远不够的。完整的搜索指标体系至少要覆盖搜索前、搜索中、搜索后三个环节。搜索前重点是需求侧指标比如搜索渗透率搜索用户/活跃用户、人均搜索次数。搜索中重点是效率指标比如搜索无结果率、搜索点击率、首屏点击率、搜索后跳出率。搜索后重点看转化和满意度比如搜索结果页到笔记详情页的转化率以及搜索后的长期行为如关注、收藏、关注作者等深度行为。再加上搜索词分类的分析想看用户到底在找什么也可以做搜索词意图分布。这套指标体系的背后逻辑是搜索功能的价值不只是让用户搜到内容更在于让用户更高效地找到好内容并引导用户产生深度互动。答题时如果你能多写一句“我还会关注搜索无结果率因为无结果率太高说明内容供给覆盖不足直接影响用户对搜索的信任度”这道题就明显有差异化优势了。4. 卷三常见失分点与避坑指南我自己也做过不少模拟题再结合大家反馈的丢分情况发现几个问题特别普遍。这里专门列出来你复习的时候应该主动避开。4.1 一上来就写代码不审视数据口径很多人在SQL题上失分不是不会写而是数据口径没搞清。比如“活跃用户”定义是“当日有登录行为”还是“当日有浏览行为”“发布内容数”是“审核通过的”还是“所有提交的”题目没写清楚你就应该说明自己默认的口径甚至作答时标明“我在此假设是xx口径”。这不仅是笔试技巧也是实际工作中数据人的职业素养。真实的业务分析中口径不统一是最大的坑同一份数据两个部门能算出两种结果。所以答题时主动说明数据口径会显得你经验丰富。4.2 业务题只讲原因不给验证方法这类失分最可惜。很多同学在分析类题目上能列举很多原因比如“推荐策略变了”“内容质量下降了”“竞争对手抢流量了”但就是不写怎么验证这些原因。阅卷人看到这样的答案只能认为你只有猜测能力没有分析能力。要扭转这个局面建议形成“假设—验证”闭环。每提出一个原因后面跟一句“可以用哪个数据、哪张表、哪个实验来验证”。比如你怀疑是推荐策略导致的那就写拉取策略上线前后同口径的指标对比或进行小流量ab实验。这样一来答案的完整度立刻上了一个档次。4.3 统计题只算数值不解释业务含义统计学题里p值小于0.05并不等于业务上一定值得上线这是因为“统计显著”和“业务显著”是两回事。如果实验组转化率只比对照组高0.1个点p值再小可能也覆盖不了开发成本。所以答题时要综合评估效果大小、成本、长期影响而不是只盯显著性。我见过很多人在笔试里把AB测试结果算完就结束了完全不提置信区间、最小样本量、功效分析也完全不说这个结果意味着什么业务决策。这样丢分是很亏的。你只要多写一句“虽然p值显著但提升幅度仅为0.1个百分点考虑到开发成本建议延长实验时间或优化方案后再做决策”就能把这道题的分数拿稳。4.4 时间分配失衡在小题上死磕笔试时间有限这是老生常谈但每次都有很多人栽跟头。卷三的题量虽然不大但每道题都需要你写步骤、写说明20分的业务题往往需要比10分的SQL题花更多时间。我建议按分值配比时间拿到卷子先花2分钟把所有题目扫一遍标记每道题的预估时间遇到卡壳超过5分钟的题先跳过把能拿的分全部拿到手再回头啃难点。现实中的笔试场景很容易让人焦虑尤其是看到前面题目有不确定的地方就忍不住反复修改。我的习惯是哪怕答案不够完美也要先写完整因为阅卷是按点给分的你把框架搭起来每一步逻辑写清楚分数就不会太差。5. 从这套题反推校招数据分析复习重点这套小红书2020校招数据分析笔试题卷三能反映出的东西远比题目本身多。它最大的价值是帮你对标大厂数据分析岗的能力要求让你知道往哪个方向使劲。5.1 SQL、统计、业务三块能力缺一不可如果你正在准备数据分析校招对照这套卷子就能看到自己短板的来源。SQL不行你连取数都费劲统计不行你做AB测试分析和实验结果判断会没有底气业务不行你分析出的结论只会停留在表面。三块能力的关系我用一个理科生的类比来解释SQL是手帮你拿到数据统计是眼睛帮你看懂数据的随机性和误差业务是大脑帮你判断数据背后的原因和行动方案。三者配合才能真正发挥数据分析师的价值。只专精其中一块大概率只能做一个“偏科”的数据人而大厂业务侧的数据分析岗要的是能独立搞定分析闭环的人。5.2 结合热门的分析工具做实战练习校招面试官不会只问你会不会SQL和Excel他们会关注你是否了解并会使用更高效的工具。近几年热度很高的数据分析清洗工具比如dify这类能快速搭建数据清洗流程的开源工具在简历和面试中已经越来越常见。我在自己的项目里也尝试过用dify做数据分析前的清洗环节效果很直观原来要写一堆python脚本处理的缺失值、异常值、格式统一问题在dify里可以通过可视化流程编排快速完成。对校招同学来说如果你有类似基于python数据分析与可视化的项目经验或者用过dbeaver这类工具做过图表可视化都可以在面试中拿出来讲这比单纯说“我会pandas”更有说服力。从商业数据分析的角度看面试官更关心的是给你一堆乱数据你能不能把它清洗成可用数据给你一个业务问题你能不能把数据变成洞察和结论。这个能力比工具本身更值钱。5.3 多做贴近业务场景的数据分析案例很多同学刷题只刷leetcode型SQL不刷业务场景题这是本末倒置。笔试中真正拉开差距的恰恰是业务分析部分。我建议大家花时间去了解几个主流内容产品的核心业务模式做几个完整的数据分析案例把数据清洗、指标搭建、异动分析、ab测试、归因分析这五个环节完整走一遍。比如你可以自己选一个公开数据集模拟一个业务问题“某社区应用近30天用户留存下降5%分析原因并给出建议”。然后从数据清洗开始一步步做到可视化、归因分析、结论输出。这个过程做下来你对数据分析面试题的理解会从“背答案”变成“真的会做”。我还建议大家准备一些数据分析项目最好能体现你对业务闭环的理解比如你做了一个内容推荐相关的分析就要说清楚分析结果如何影响推荐策略而不只是“我用python画了几张图”。这种闭环的表述才是商业数据分析师和纯技术人员的核心区别。6. 我的实操体会这套卷子刷下来我的最大感受是互联网公司数据分析笔试越来越不考“死知识”越来越考“活思维”。你背得住中心极限定理的公式但如果你不知道它在AB测试里怎么用这个知识就等于零你写得出多表join的SQL但如果你不知道业务表之间的关联关系代表什么业务含义你取出来的数也没人敢信。我在实际做数据分析时深深体会到拿数据说话是最有力的说服方式但前提是你的数据口径正确、分析框架完整、结论可落地。准备校招笔试本质上就是在训练这套思维方式。每一次做题都想象自己真的坐在业务会上对面是产品和运营的同事你不仅要告诉他们数据是什么还要告诉他们数据意味着什么、该做什么。最后再分享一个小建议笔试刷题不能只刷一遍至少要复习两遍。第一遍按完整模拟来做检验速度和自己真实的水平第二遍专门整理错题把每道错题背后暴露的能力短板补齐。错题整理比盲目刷题有用得多。卷三这套题哪怕放到现在依然是很好的训练素材把它吃透再去面其他互联网公司的数据分析岗你会发现很多题目都是相通的。