作为参加过2020年那波校招的老学长现在回头看小红书这套数据分析笔试题卷一还是很有感触。当时互联网大厂的数据分析岗还远没有现在这么卷但小红书这套卷子已经出得相当有水平既考基本功也考业务sense到现在依然有很强的参考价值。我印象最深的是这套卷子没有堆砌那种茴字的四种写法式的偏题怪题而是把真实业务场景拆成了一道道考题。你如果只看书不刷题、只知道概念不会算数基本会做得很难受。但如果平时有认真做过业务分析、写过SQL、跑过实验又会觉得每个题都似曾相识。这篇文章我不打算只贴答案而是想从这套题到底想考察什么出发把卷子里的SQL题、统计概率题、业务case题逐类拆开讲透顺带把我当年踩过的坑和后来的复盘思考都整理出来。不管你是正在准备校招还是想转行做数据分析这份拆解应该都能帮你在备考时少走很多弯路。1. 笔试题的整体设计与考察逻辑1.1 小红书想要什么样的数据分析师分析2020年这套笔试题不能只看题目本身要先搞清楚小红书作为一个内容社区对数据分析师的能力预期到底是什么。小红书的业务核心是内容生产和消费背后牵扯到推荐算法、社区治理、广告变现、电商闭环等多条线。数据团队并不是单纯地跑数而是需要能深入理解内容生态和数据指标之间的因果关系。从卷子能明显看出来小红书要的不是纯统计背景的书呆子也不是只会写SQL的取数机而是能同时理解业务语言和技术语言的人。这导向了三个层面业务上懂社区产品的核心指标技术上能熟练处理用户行为数据方法上懂AB实验和因果推断的基本逻辑。所以卷一里SQL题占大头因为它是最朴素的取数能力体现统计题紧跟其后因为实验评估是互联网决策的根基业务开放题压轴因为高阶分析师的价值恰恰在于从数据波动中定位业务问题。整套卷子难度梯度也设置得比较合理。前几题是送分的基础查询中间是窗口函数和留存计算这类进阶SQL后面就是概率计算和开放业务题。你如果从头做到尾会感觉是在模拟一个从取数到分析再到给建议的完整工作流。1.2 题型分布与题量节奏一套线上笔试通常会有8到12道题限时90到120分钟。按我当时的经验卷面结构一般可以划分为四个模块SQL与数据查询、统计概率与AB实验、业务分析与case题、以及少量Python/Excel实操题。各模块的权重也反映出岗位的侧重方向。SQL基本功占比最高大概在30%到40%之间统计概率其次约25%到30%业务分析题约20%到25%工具实操和开放题占剩余部分。这样的设置是在考察一个初级数据分析师入职后能不能快速上手干活因为入职前半年做的最多的事就是写SQL、看数、帮业务方做复盘。时间分配上这里有个我特别想提醒的坑。大多数人会按顺序从前做到后结果在中等难度的SQL题上死磕太久导致最后的大题只剩十几分钟。我的建议是拿到卷子先花3到5分钟快速浏览全部题目把业务case题的思路关键词先写在草稿纸上然后按先易后难的顺序做题把能拿的分先稳稳拿到手。2. 高频考点与核心知识点解析2.1 SQL内容平台的查数基本功小红书这套卷子里的SQL题场景基本都是围绕内容社区展开的。典型场景包括统计社区某天的发帖量、计算用户的次日留存率、找出连续活跃N天的用户、分析某个话题页的曝光到互动的转化漏斗。这些场景看起来简单但每道题背后都有一个关键的知识点而其中最核心的就是窗口函数。比如计算每个用户最后一次访问的页面常规group by之后你会发现拿不到访问时间对应的页面信息这时候就要用row_number()配合partition by来实现。还有每个话题下互动量排名前3的内容同样依赖rank或dense_rank这类窗口函数。我建议备考时把窗口函数的用法练到条件反射的程度特别是这几类row_number()用于编号、rank()和dense_rank()用于排名、lag()和lead()用于取前后行、sum() over ()用于计算累计值。笔试中只要出现分组排序和连续性问题八成都要用到它们。另一个必考重点是去重。很多同学刚学SQL的时候会用count(user_id)去统计用户数但这在行为日志表里是大忌因为同一个用户可能有多条记录。正确做法是count(distinct user_id)。而另一个容易错的地方是count(字段)和count()的区别。count()统计的是行数count(字段)则会自动跳过null值这两个结果在字段为null的时候会不一样踩过一次就很难忘。2.2 统计概率绕不开的AB实验思维统计概率题在小红书的笔试里不只是算概率而是几乎全部指向实验设计和效果评估。这也符合互联网公司的实际情况改个推荐策略、换个交互样式都需要通过AB实验来验证效果数据分析师就是实验的设计者和评估者。这里的高频考点集中在几个方向假设检验的基本流程、p值和置信区间的解读、第一类错误与第二类错误的区别、样本量的估算以及辛普森悖论这种容易迷惑人的反直觉问题。特别是第一类错误和第二类错误笔试里很喜欢用业务场景来考。比如我们要上线一个新功能你更担心把没效果的功能误判为有效还是把有效的功能误判为无效。前者是第一类错误会浪费研发资源去做一个假效果后者是第二类错误会错过一个真实增益。不同业务阶段对两类错误的容忍度不同这就要结合业务成本去回答不能只背定义。还有一类容易被忽视的考点是辛普森悖论。它说的是整体趋势和分组趋势不一致的现象。笔试题可能会这样出某推荐策略改动后整体点击率上升了但分设备类型看iOS和安卓的点击率都下降了请问这是怎么回事答案核心在于样本结构发生了变化新策略让低点击率设备或低点击率时段的流量占比大幅提升从而拉高了整体均值。这种题考的就是你有没有对数据进行分层观察的意识。2.3 业务思维题从数据到决策的临门一脚业务开放题是最能拉开分数差距的部分。它没有唯一答案但阅卷人能从你的回答里看出你是只会算数的工具人还是真的理解业务的数据分析师。以小某书这样的内容社区为例业务题通常会围绕几个主题来出社区核心指标体系怎么搭建、某个指标突然波动怎么归因、一次运营活动怎么评估效果、要不要对某个用户群体做激励。这些题目的共同点是需要你把一个模糊的业务问题转化成可以度量的数据问题。我发现很多同学在回答这类题时最大的问题是只给结论不给过程。比如问DAU下降了怎么分析有的人会直接说可能是因为竞品上线了新功能。这种答案没用因为没有任何数据支撑。正确做法是把问题层层拆解给出可验证的假设和对应的数据指标最后落到明确的下一步动作。一个比较好用的答题框架是先定义问题、确认口径再拆解指标、定位异常然后提出假设、用数据验证最后给出建议并设计监控方案。笔试题只要遵循这个框架就算数据假设不够精准框架的完整性也会给你带来可观的分数。3. 典型真题实操拆解3.1 一道SQL题计算连续活跃天数连续活跃类题目在各大厂笔试里出现频率高到什么程度呢几乎可以当成必考题来准备。题目通常会这样描述给定用户登录表user_login字段为user_id和login_date请统计连续活跃3天及以上的用户数。这个题的经典解法我直接写出来。思路是利用日期减去行号的分组技巧如果用户在某段时间内连续登录那么login_date减去一个递增的行号后得到的分组日期是相同的。核心SQL如下-- 先对每个用户的登录日期去重排序 with tmp as ( select user_id, login_date, row_number() over (partition by user_id order by login_date) as rn from ( select distinct user_id, login_date from user_login ) t ) -- 用日期减行号得到分组标记统计组内天数 select user_id, date_sub(login_date, interval rn day) as group_id, count(*) as active_days from tmp group by user_id, date_sub(login_date, interval rn day) having count(*) 3;这里有个特别容易踩的坑就是登录表里可能出现同一天多条登录记录。如果你不去重就直接做row_number排序同一个日期会被编成多个行号导致本来连续的日期被错位拆开结果就会算错。所以最稳妥的做法是先对(user_id, login_date)做distinct再进入后续计算。如果笔试里没有要求你写出完整SQL而是给了一个结果表让你判断是否正确那你也要留心连续活跃的定义。是连续3天每天都有登录还是3天内累计登录3天这两个口径如果没定义清楚写出来的答案完全不一样。遇到这类题先跟自己确认口径永远是第一优先级。3.2 一道业务题DAU环比下降的归因分析这类case题几乎每场笔试都会出现只是包装不同。我见过很多版本的问法比如某内容社区DAU环比下降5%请给出归因分析思路。回答的好坏很能体现分析功底。我在笔试里给出的回答思路是这样的。第一步先确认数据的真实性不要上来就分析业务波动。要检查是否有数据上报延迟、埋点变更、口径调整排除数据本身的问题这是很多新手容易忽略的一步。第二步做指标拆解。DAU可以拆成新用户和老用户两部分老用户又可以分为回流用户和留存用户。环比下降5%到底是新用户减少导致的还是老用户流失加剧导致的要先分清楚。进一步还可以拆到端iOS/Android、版本、渠道去定位下降的主要群体。第三步结合已知业务动作和外部环境提假设。比如近期是否上线了新的推荐策略、是否调整了推送频次、是否遇到了竞品的强运营活动、是否是节假日或开学季等周期性波动。每个假设都对应着可验证的数据指标。第四步落到行动建议。比如如果定位到是新用户次留下降就要进一步看新用户的注册流程、首刷内容质量、关注的博主数量等如果是老用户流失就要看高价值用户的流失预警和召回策略。这样整个回答就是完整的、可执行的而不只是停留在可能是什么原因的层面。3.3 一道概率统计题AB实验的样本量估算假设检验和样本量估算在笔试中出现很频繁以一道常见的题为例某个按钮的点击率基线是10%想通过实验检测出1个百分点的提升在显著性水平0.05、统计功效80%的条件下每个分组大概需要多少样本量样本量估算公式可以写成n ((Zα/2 Zβ)^2 * p * (1 - p)) / (p1 - p0)^2其中p0是基线转化率0.10p1是预期转化率0.11所以分母就是0.01的平方即0.0001。Zα/2在双侧0.05显著性水平下约为1.96Zβ在80%功效下约为0.84所以分子约为(2.8)² x 0.10 x 0.90。算出来大约是7.056除以0.0001等于70560人。考虑到AA分组和可能存在的样本波动实际投放时通常会再加10%到20%的余量。这个计算过程看似复杂但笔试考的核心不是你的算术能力而是你有没有样本量估算的概念。很多同学在回答时只会背公式却在解读结果时翻车。要记住样本量越少实验越难检测出小提升如果想要检测更小的提升幅度样本量就需要大幅增加这也是为什么很多产品实验都跑不满预期效果的原因之一。3.4 一道实操题用Excel快速完成数据检查不要觉得Excel题简单它考查的其实是指标口径理解和数据敏感度。这类题通常会给出一个内容数据明细表字段包括笔记ID、曝光量、点击量、点赞量、收藏量、评论量然后要求计算点击率和互动率。这里最大的坑就是口径陷阱。点击率的分子是用点击量还是点击用户数分母是用曝光量还是曝光用户数不同口径算出来的数字差异很大。做内容平台的数据分析师一定先明确曝光是次数还是人数点击是去重用户数还是总点击次数。如果题目没说明就要主动假设并注明这也是在考察你能不能独立处理工作中的口径模糊问题。实操上Excel数据透视表是处理这类题目最顺手的工具拖拽几下就能算完。如果你熟悉pandas用groupby也能快速验证结果。笔试中往往时间紧张我建议熟练掌握其中一种工具即可不必在多个工具间反复切换浪费时间。4. 常见失分点与避坑清单4.1 三个最冤的失分点回顾我当年和身边同学做笔试的情况发现失分最可惜的往往不是不会做的题而是会做但没做对的题。第一个高频失分点是忽略题目中的业务限定条件。比如题干说只要注册超过30天的用户结果SQL里没有写这个过滤条件整个统计口径就错了。第二个失分点是对null值的处理不当。很多人会理所当然地认为count(user_id)就能统计出所有用户但当user_id为空时计数结果与count(*)会不一致同样地用left join关联表之后右表字段也会出现null如果不处理就直接参与计算结果会偏差得很离谱。第三个失分点也是最常见的是业务题只写结论不写分析过程。笔试的阅卷规则大多是按点给分你多写一个合理的假设就多一分希望。空泛地说要提升内容质量不如具体到建议观察新品类的供给量变化对完播率的影响。数据分析师最重要的能力就是让结论变得可验证这个思维从笔试开始就要建立。4.2 答题节奏与检查策略笔试题量大且时间紧很多人在考场上会慌一慌就容易在细节上翻车。我自己后来的答题策略是严格的三轮法。第一轮快速扫题先把所有确定能做的题写完不纠结格式核心结果写出来就好。第二轮回头处理略有把握但需要思考的题这类题往往是窗口函数题和应用型统计题。第三轮重点攻坚最难的开放题和没做出来的题这时候哪怕只能写出思路框架也要写上因为开放题按点给分有一定框架就比空白卷好很多。检查环节同样重要但不要全面重做而是重点检查几个容易出错的地方SQL里的条件字段是否写全group by字段是否与select中的非聚合字段一致去重逻辑是否考虑到了null以及公式计算中的单位是否统一。这些细节只要多花三分钟检查一遍就能挽回很多不必要的失分。4.3 容易被忽视的细节笔试中的一些细节往往决定成败。SQL题中日期边界是最容易被忽视的。如果统计的是当天的数据要明确login_date是date类型还是datetime类型。如果你用login_date between 2020-01-01 and 2020-01-02这会把1月2日当天凌晨的数据也包含进来得到错误结果。datetime类型应该用 2020-01-01 and 2020-01-02这样的左闭右开区间。统计题里写完p值计算后记得写结论比如p值小于0.05拒绝原假设说明改动有统计显著性。很多同学算完就停了漏掉结论而白白丢分。case题中列指标时不要只写一个指标名称还要说明为什么要看这个指标它在整个业务逻辑里能说明什么问题。这个所以呢的追问是数据分析师和取数工最本质的区别。5. 从一套笔试题延伸到工作能力与备考方法5.1 笔试复盘对后续面试和工作的启发有些人觉得笔试只是入职的敲门砖过了就完了。但后来我进了互联网公司做数据分析再回头看这套卷子才明白笔试题目设计其实是工作场景的高度浓缩。SQL题的背后是日常取数和报表开发统计题的背后是每天要做的实验评估业务题的背后是周报月报里的指标异动归因。所以备考笔试的过程本质上是提前演练未来的工作方式。我建议不要只满足于做对题而是在每次刷完题后追问三个问题这个题对应什么业务场景如果数据出现异常我会怎么排查我要向业务方输出什么结论和建议养成这种思考习惯之后不管是笔试的开放题还是面试的case面你都会比那些只会背题库的人从容很多。5.2 备考时间线与训练建议如果你从零开始准备数据分析岗笔试我给一个三个月的大致规划。第一个月打基础集中在SQL和统计学SQL要刷完窗口函数、多表关联、去重与聚合这几大板块统计学重点放在描述统计、假设检验、置信区间和AB实验设计。第二个月做专项练习开始刷业务case题每天拆解一个常见的业务问题比如留存下降、转化率低、活动效果不明显把它写成结构化的分析思路。第三个月进入模拟冲刺严格按照考试时间做整套模拟卷训练答题节奏。工具方面不用贪多。SQL就用你最顺手的MySQL或Hive语法练习Python重点掌握pandas的数据清洗和聚合操作Excel会数据透视表和常用函数就够了。我在实际笔试中最常使用的还是SQL加Excel的组合Python更多是处理更复杂的数据清洗和建模场景时才用得上。案例分析方面平时可以多读一些行业分析报告和公开的数据复盘文章注意观察别人是如何拆解问题的。比如看一个内容平台的月报不要只记数字而要思考它为什么选择这些指标这些指标之间有什么勾稽关系如果其中某一个突然变化会牵动哪些其他指标。这种刻意练习对提升业务感很有帮助。5.3 笔试中值得长期保留的好习惯最后分享几个我后来一直保留的习惯。第一个习惯是任何分析项目都先写口径说明把自己的假设和指标定义放在最前面避免后面分析跑偏。第二个习惯是每做一个case最后都要落到一个具体的建议动作哪怕这个动作只是建议增加一个新的监控指标也要比空泛的继续观察好得多。第三个习惯是维护一份错题本。我把所有笔试和练习中做错的题按类型归档比如SQL类型、统计类型、业务逻辑类型并标注错误原因。这个习惯帮我避开了很多重复踩坑准备面试时也很有用翻一遍错题本就能快速回顾自己的薄弱点。从我后来参与校招简历筛选和面试的经验看笔试成绩确实是进入面试的重要参考但它考察的远不只是会不会做题而是你有没有结构化思考问题的能力。如果你正在准备校招或转行数据分析建议不要迷信刷完几百道题就能过把心态放平重点放在理解题目背后的业务逻辑和提升自己的分析框架上一套题吃透好过十套题囫囵吞枣。