2019小红书数据分析校招笔试复盘：SQL、业务思维与统计基本功

1. 一场笔试背后的筛选逻辑2019年那批题到底想考什么先说说我为什么到现在还在翻这份2019年小红书数据分析岗的笔试题。这几年帮学弟学妹做面试辅导发现一个很有意思的现象很多人刷了大量的SQL题、背了一堆机器学习公式结果一遇到校招笔试还是发懵。原因很简单——校招笔试和社招笔试的考察逻辑完全不同它不是在考你会不会写某个函数而是在考你有没有做数据分析的思维底子。小红书2019年校园招聘数据分析岗位在线笔试第二批这套题恰好是这种筛选逻辑的典型样本。这套题当时面向的是应届生岗位是数据分析笔试形式是在线答题分两批进行。第二批的题目整体给我的感觉是不偏、不怪、不炫技但非常吃基本功。它没有让你手推GBDT的公式也没有让你从零写一个TF-IDF而是把大量的分值压在三个维度上SQL取数的熟练度、业务指标的理解深度、统计概率的直觉判断。这三个维度恰好对应了数据分析师日常工作中最常打交道的三件事从数据库里拿数据、把数据变成业务结论、判断结论是否靠谱。如果你现在正准备校招笔试或者已经在面试流程中但心里没底这篇文章值得你花十分钟看完。我会把第二批这套题的结构拆开逐个题型讲清楚考察意图再给出具体的解题思路和答题模板最后聊聊那些笔试时感觉良好、出分却翻车的隐藏失分点。这不仅仅是复盘一套过去的真题更是一份可以直接套用的备考框架。这里先给一个总结论2019年小红书数据分析笔试二批的核心不是难而是全面。它覆盖了SQL、业务分析、统计学、数据敏感度四个板块每个板块的分值分配相对均匀任何一个板块出现明显短板都很难通过。所以备考的关键不是押题而是补短板。2. 题型总览与分值分布先知道战场长什么样在拆具体题目之前先把第二批这套题的整体框架拉出来。我当时做完的第一感觉是题量不算大但每一道题都需要认真思考不存在秒杀题。整张卷子大概分为四个部分下面我结合记忆和同类笔试的普遍情况做个还原。题型板块大致题量考察核心难度系数数据分析基础概念5-8题指标理解、业务场景判断中等偏易SQL编程题3-4题取数逻辑、表关联、聚合计算中等统计学与概率4-6题假设检验、分布、AB实验中等业务案例分析1-2大题指标体系搭建、异动归因较难这个结构在当时的主流互联网公司校招笔试中属于标准配置但注意几个细节。第一基础概念题占比不低。很多人备考时直接跳过概念题去刷SQL这是策略性失误。概念题虽然单题分值不高但胜在稳定属于送分题。如果在这里丢分后面的大题压力会非常大。我见过太多候选人SQL写得飞起结果被DAU和WAU的关系留存率的正确计算方式这类基础题绊倒。第二SQL题的考察方式是场景化取数不是单纯的语法测试。它通常会给一个简化的业务数据表结构然后让你写出满足某个业务需求的查询语句。这意味着你不仅要会写JOIN、GROUP BY还要能读懂题目背后的业务含义知道为什么要这样取数。第三业务案例题是真正的分水岭。这道大题没有标准答案考察的是你的分析框架和表达能力。很多理工科背景的同学在这道题上栽跟头不是因为不会分析而是因为分析思路太技术化没有站在业务方的角度思考问题。下面我们逐个板块来拆解。3. 数据分析基础题你以为会做其实一直在踩坑先聊基础概念题。这批笔试的基础题主要集中在以下几个方向指标定义、漏斗分析、留存计算、归因逻辑。这些概念听起来都耳熟能详但题目的问法往往藏着陷阱。举例来说有一类经典问题某App次日留存率下降了5个百分点请分析可能的原因。这看起来像个业务分析题但实际上笔试时它可能以选择题的形式出现给你四五个选项让你选出最不可能的原因。很多人会直接选竞品上线了同类功能——因为大家本能地觉得竞品是万能的背锅侠。但正确答案往往不是这个而是某个更隐蔽的逻辑漏洞比如统计口径发生了变化将iOS用户单独拆出或者版本更新后强制登录才能浏览内容。这类题背后考察的是你的指标敏感度。指标波动时第一步永远不是找外部原因而是确认内部统计逻辑是否一致。我在实际工作中吃过这个亏。有一次DAU突然掉了3%全组人分析了两天最后发现是埋点代码在某个版本被误删了。那次之后我总结了一条铁律任何指标异动先查口径再查数据质量最后才谈业务原因。这个顺序应该在笔试时就已经刻在骨子里。再来看留存率。留存率的基础计算公式大家都懂第N日留存率 第N日仍活跃的用户数 / 首日新增用户数。但笔试时它会变着法子考察你对用户数的理解。比如某日新增用户1000人其中300人在次日有登录行为但50人在次日凌晨被系统判定为异常用户并封禁请问次日留存率是多少这里就涉及一个细节被封禁的用户算不算在分母里统计口径不同答案完全不一样。笔试时遇到这种题目我的建议是不要急着算先把口径写清楚。哪怕题目没有要求你在草稿纸上写出分母当日新增总用户数分子次日有活跃行为的用户数剔除封禁用户然后再根据题目的业务场景做判断。这样即使最终答案错了阅卷时也能看到你的思考过程——虽然笔试是机器阅卷但这个习惯能帮你避免计算出错。第三个高频考点是漏斗分析。这里考察的不是漏斗怎么画而是如何定位漏斗中的关键流失环节。题目通常给出一组转化数据曝光→点击→加购→下单每一步的转化率分别是多少问你最应该优化哪一步。很多人一看转化率最低的环节就选它比如加购到下单只有30%就觉得这里流失最严重。但正确的分析逻辑是看绝对流失量和环节提升空间的乘积而不是单看转化率。举个例子曝光100万点击10万加购5万下单1万。点击率10%点击到加购50%加购到下单20%。如果只看转化率加购到下单20%是最低的应该优化这里。但如果你把加购率从50%提升到60%下单会变成1.2万而如果把点击到加购的转化率从50%提升到60%下单也是1.2万。两者提升效果一样。但如果考虑优化难度——电商场景下加购到下单的流失通常和价格、运费、支付方式有关优化空间有限而点击到加购的流失可能和商品详情页质量有关通过优化详情页提升点击到加购难度更低收益更确定。所以笔试中的最优解往往不是转化率最低的环节而是提升空间和提升难度的综合权衡。4. SQL场景化取数笔试里最不该丢分的硬功夫SQL是数据分析笔试的标配小红书的这批题也不例外。和LeetCode那种纯算法SQL题不同校招笔试的SQL题更接近实际工作场景——它给你几张表让你完成一个业务取数需求。这里我想重点聊聊三道典型题目它们基本覆盖了SQL笔试的核心考点。4.1 多表关联与聚合的考察逻辑第一类典型题是多表关联统计。比如题目给出用户表user_id, reg_date, channel、订单表order_id, user_id, order_date, amount让你统计每个渠道的新用户在下单后7天内的复购率。这题考察的不仅仅是JOIN语法还有你对7天内这个时间窗口的处理逻辑。我当时做题时总结了一个模板适用于大部分每个XX的YYY类题目SELECT u.channel, COUNT(DISTINCT o.user_id) AS repurchase_users, COUNT(DISTINCT u.user_id) AS new_users, COUNT(DISTINCT o.user_id) / COUNT(DISTINCT u.user_id) AS repurchase_rate FROM users u LEFT JOIN orders o ON u.user_id o.user_id AND o.order_date BETWEEN u.reg_date AND DATE_ADD(u.reg_date, INTERVAL 7 DAY) WHERE u.reg_date 2019-01-01 GROUP BY u.channel;这里有两个关键点。第一为什么用LEFT JOIN而不是INNER JOIN。如果用INNER JOIN那么没有任何订单的用户会被直接过滤掉复购率的计算中未复购用户这个分母就丢失了得到的结果会虚高。很多人在这个细节上栽跟头——测试数据恰好所有用户都有订单时看不出问题但换成线上真实数据就错了。第二关联条件里的时间窗口过滤要写在ON子句而不是WHERE子句。写在WHERE里LEFT JOIN就变成了INNER JOIN逻辑直接错误。提示笔试SQL题中看到统计每个XXX的YYY率第一反应先问自己——用户表和数据表是什么关系一的一方还是多的一方需要保留没有行为的用户吗想清楚再动手。4.2 窗口函数的进阶用法第二类典型题是窗口函数的应用。2019年那会儿窗口函数在校招笔试中已经不算冷门了但很多人只会简单的ROW_NUMBER()遇到复杂场景就抓瞎。常见题目是统计每个用户最近一笔订单的金额以及该订单距离注册日期的天数。这类题必须用窗口函数才能高效解决。我的写法是SELECT user_id, order_amount, DATEDIFF(order_date, reg_date) AS days_since_reg FROM ( SELECT o.user_id, o.order_amount, o.order_date, u.reg_date, ROW_NUMBER() OVER (PARTITION BY o.user_id ORDER BY o.order_date DESC) AS rn FROM orders o LEFT JOIN users u ON o.user_id u.user_id ) t WHERE rn 1;思路是先用ROW_NUMBER()按用户分区、按下单时间倒序编号取rn1就是最近一笔订单。这类题还可能有变形比如取每个用户第二笔订单rn2、取每个品类销量最高的商品RANK()等。掌握一个核心逻辑——分组TOP N用窗口函数不要用GROUP BY LIMIT——就够应对80%的变体了。4.3 留存计算的SQL实现第三类必考题型是留存率计算。留存率的SQL实现有很多种写法笔试时最容易出错的不是SQL语法而是对留存口径的理解。一个标准写法如下SELECT DATE(u.reg_date) AS reg_date, COUNT(DISTINCT u.user_id) AS new_users, COUNT(DISTINCT CASE WHEN DATEDIFF(DATE(o.order_date), DATE(u.reg_date)) 1 THEN u.user_id END) AS retained_users_day1, COUNT(DISTINCT CASE WHEN DATEDIFF(DATE(o.order_date), DATE(u.reg_date)) 7 THEN u.user_id END) AS retained_users_day7 FROM users u LEFT JOIN orders o ON u.user_id o.user_id WHERE u.reg_date 2019-01-01 GROUP BY DATE(u.reg_date);注意几个细节。第一活跃的定义。题目如果说次日活跃那你应该去用户活跃表找登录行为而不是订单表——除非题目明确说次日下单。用错表会让整个答案失去意义。第二去重。用户一天可能下多单或登录多次所以必须用COUNT(DISTINCT ...)。第三时间的粒度。注册日期和活跃日期都是datetime还是date如果混用DATEDIFF的结果会差一个边界小时数。笔试环境里通常给的是date类型但养成先确认类型的习惯永远不会错。SQL部分除了语法正确我特别想提醒一个点读题时先画出表结构。哪怕题目已经给出了字段列表也建议在草稿纸上快速写一下每张表的粒度一行代表什么。比如订单表的一行可能是一笔订单也可能是一个订单中的一件商品订单明细表差别极大。搞错了粒度后面的JOIN和COUNT逻辑全都会出错。5. 统计与概率数据人的内功心法部分统计学在数据分析笔试中的比重是不高但致命。说它不高是因为题量通常不会超过三分之一说它致命是因为一旦在统计题上失手基本意味着与offer无缘——这块内容是可以通过短期复习拿满分的丢分非常可惜。5.1 假设检验的必考套路假设检验是统计部分的绝对重点。笔试通常不会让你手算t统计量那太偏数学系了而是考察你对第一类错误和第二类错误的理解以及如何根据业务场景选择检验方法。一个经典选择题在AB测试中我们将显著性水平α从0.05调整为0.01以下说法正确的是A. 犯第一类错误的概率降低 B. 犯第二类错误的概率降低 C. 统计检验力提高 D. 样本量需求降低。正确答案是A。但很多人因为对两类错误的关系不熟练错选C或D。这里有个便于记忆的口诀α降低第一类错误降低第二类错误升高检验力降低所需样本量增大。所有变化方向都是反着来的。还有一个高频考点是p值怎么解释。很多人会写成p值为0.03说明原假设为真的概率是3%——这是错的。正确解释是在原假设为真的前提下观察到当前样本或更极端样本的概率是3%。笔试时可能会用一个判断题来考察这个区别。这个知识点非常基础但恰恰是区分背过统计和理解统计的分水岭。5.2 概率题的商业包装概率题在校招笔试中往往会披上商业的外衣。比如某社区内容平台用户发布一篇笔记后48小时内获得超过100个赞的概率为30%。假设该用户在周五晚上8点发布了一篇笔记截至周六晚上8点获得了80个赞。请问该笔记在周日晚上8点前获得100个赞的概率是多少请用贝叶斯定理说明思路。这类题的目的不是让你算出精确数值——实际上给的信息也无法直接算——而是考察你能否识别出这是一个贝叶斯更新问题。你需要在答题中明确写出先验概率是30%观察到48小时时只获得80个赞这个新证据后需要根据这个证据修正先验如果能知道48小时获得80个赞的条件概率分布就能计算后验概率。即使不会算最终数字把思路框架写清楚就能拿到大部分分数。这里想多说一句概率题里的业务背景不是装饰而是提示。比如周五晚上8点发布这个信息暗示这个时间点的用户活跃度和内容消费特征不同于工作日会影响点赞速率。答题时如果能点出发布时段是重要协变量会让阅卷人眼前一亮——即使在机器阅卷的环境下这份敏感度也会在其他环节体现出来。5.3 常见分布与实际业务的对号入座统计部分偶尔会考察常见分布的识别。比如用户在一小时内到达某直播间的次数最可能服从什么分布答案是泊松分布。这种题靠背就能得分但我会建议你多想想为什么——泊松分布描述的是单位时间内随机事件的发生次数要求事件独立且发生率恒定。直播间的用户到达虽然不是完全恒定有开播冷启动、峰值效应但作为近似是合理的。理解背后的假设比单纯记住计数数据用泊松要靠谱得多。6. 业务案例分析没有标准答案的送命题也是送分题业务案例题是整个笔试中分值最大、最开放、也最能拉开差距的部分。小红书的这批笔试中业务题给我的印象是问题朴素但考察的分析深度不朴素。我挑两个典型的问法来拆解。6.1 DAU下降5%怎么分析的完整回答结构这道题几乎可以算数据分析面试的国歌了。小红书版本的问法大致是某内容社区产品近一周DAU持续下降降幅约5%作为数据分析师你会如何分析请写出完整的分析思路。很多人看到这道题第一反应是这题我都会就是拆维度嘛。但真正动笔时要么只列了几个维度要么直接跳到结论。我的建议是用结构化的问题清单来组织回答。第一步是定义问题。DAU下降5%是相对哪个基准是环比上周还是同比去年不同基准的解读完全不同。如果去年同期也呈现类似下降比如春节因素那可能只是季节性波动不算真正异动。第二步是校验数据。确认统计口径没有变化、埋点没有缺失、数据仓库有没有延迟。这一步的权重甚至应该高于业务归因——我前面也说过很多异动最后查出来都是数据问题。第三步是维度拆解。DAU 新用户 老用户回流 老用户持续活跃分别看这三大块的贡献。然后再往下拆新用户看渠道、看获客成本老用户看留存曲线、看访问频次、看内容消费时长。平台侧看内容供给是否充足、推荐算法是否有变动、是否有重大舆情事件。第四步是提出假设并验证。比如推荐算法调整导致新用户首刷体验变差那么应该去对比调整前后的新用户次留数据某个大V停止更新导致内容供给下降那么应该去看头部内容生产者的活跃度数据。第五步是输出结论和行动建议。这一步很多人忽略但它恰恰是数据分析师和取数机器的区别。分析完了不能只说DAU下降了是因为老用户流失还得给出建议召回策略建议调整推送频次这样的可落地方案。我见过一个不错的答题框架分享出来供你参考我将按照口径确认→维度拆解→假设验证→落地建议四个步骤进行分析。先确认统计口径和数据质量再按新老用户和大盘维度拆解下降来源然后针对贡献最大的下降部分分别提出业务假设并用数据验证最后输出可执行的建议。这个框架好在先确认口径、再拆维度、最后才谈归因逻辑链条完整面试官一眼就能看出你是有实战经验思路的而不是背了一堆结论。6.2 指标体系的搭建思路业务题还有一种问法是为一个新功能设计核心指标。比如小红书的内容平台如果要上线一个新的合集功能你会关注哪些指标这类题没有标准答案但有一个通用的思考框架从用户行为链路出发拆出感知、使用、沉淀、传播四个环节。感知环节看功能曝光量和点击率使用环节看创建合集的用户数、人均创建数量、合集内笔记的添加率沉淀环节看合集页的访问深度、回访率传播环节看合集被分享的次数、带来的新用户转化。再往上还要挂钩业务价值——合集是否提升了用户的长期留存量、是否带动了笔记发布频次。写这类题时记住一个原则指标要成体系而不是罗列。不要把所有想到的指标全列上去那会让阅卷人觉得你缺乏优先级判断。更好的做法是分主次指标一个北极星指标比如每周创建合集用户数 三个过程指标 两个防风险指标比如合集功能是否挤压了普通笔记的发布。这样既体现了全局观又体现了取舍能力。7. 笔试中的隐藏失分点为什么你感觉答得不错分却不理想最后聊聊一个很扎心的话题——笔试复盘时觉得自己答得还行为什么不通过结合我自己的经验和带人辅导时的观察校招笔试的失分点往往藏在下面几个不起眼的地方。失分点一只看结果不看过程。这在SQL题里特别明显。很多人写出的SQL能跑出结果但写法非常粗暴——比如用子查询嵌套了七八层或者一个字段反复计算多次。笔试虽然不像面试那样会现场追问优化思路但如果有主观评分环节可读性和规范性的价值就会体现出来。养成用WITH语句拆解复杂逻辑、给关键计算加注释的习惯是值得的。失分点二业务题答成了数据分析报告。有些同学业务题写得洋洋洒洒从宏观环境讲到竞品分析篇幅很大但信息量很低。业务题考察的是分析框架与可执行建议不是叙事能力。建议只用总分结构先说核心结论再说推导过程最后给行动项。写太多冗余内容反而稀释了重点。失分点三统计题只看数字不解释业务含义。比如算出了p值却不说明这个差异在业务上是否重要。显著性不等于业务显著性——样本量足够大时0.1%的差异也能显著但对业务毫无意义。答题时最好在统计结论后补一句业务解读这会体现出你是用统计做决策的人而不是会算统计题的人。失分点四时间分配严重失衡。这套题的二批卷子整体难度中上如果在一道SQL题上卡了20分钟后面的业务大题大概率会写得很仓促。我的建议是先扫一遍全卷把概念题和简单的SQL题快速做完把业务大题留足20-25分钟最后再啃硬骨头。数据分析笔试的本质是在有限时间内展示你的稳定输出能力而不是证明你能解出最难的题。失分点五忽略审题中埋的口径时间线。校招笔试题里经常出现类似近7日次月自然周这样的时间范围限定。很多人做题时默认按自然周计算结果题目要求的是滚动7天。笔试没有机会提问所以读题时用笔圈出所有时间词、主体词、排除词宁可多花30秒审题也不要写到最后发现跑题。8. 最后再分享一点备考的心得回到2019年这套笔试本身它的价值并不在于题目本身是否还会再考而在于它概括了一个数据分析校招候选人应该具备的基本盘SQL要能处理多表场景统计要能解释业务问题业务分析要成框架指标理解要够扎实。这四样东西哪怕现在拿出来依然是数据分析笔试的核心。如果你正在准备类似的笔试我的建议是不要沉迷于刷偏题怪题。把SQL窗口函数练熟、把假设检验的两类错误吃透、把指标异动分析的框架写到自己能脱口而出这三件事做好市面上90%的数据分析笔试题你都能应付。等进了面试轮再去看更深度的机器学习或者产品Sense也不迟。我当时带过的一个学弟笔试前只做了三件事把SQL窗口函数的所有用法过了一遍把常见的业务分析框架整理成自己的模板把统计概念用能不能用大白话解释给非技术同事听来检验理解程度。他最后顺利拿到了多个大厂的数据分析offer。这套思路放在今天依然成立。