先说一个结论这套小红书2020校招数据分析笔试题绝不只是考你会不会写SQL、知不知道几个统计公式。它更像是一道筛选器把“能取数”和“能解决问题”的人分开。我拿这套题反复刷了三遍越刷越觉得它代表了一批互联网公司数据分析校招题的典型风格题目看似基础但每一问都往业务底层逻辑上引。这也是我把它当成教学样本的原因。无论你面的是内容社区、电商还是本地生活这套题里的考察逻辑都通用值得认真拆一遍。这篇文章我会从出题人的视角还原这套题的考察点用具体题目讲解题思路最后再聊几个备考时最容易踩的坑。1. 笔试整体设计与考察逻辑拆解1.1 这不是考代码是考业务落地能力拿到卷子第一感受是题目量不大但每道题都有“身份”。比如一道SQL题它不会让你单纯把两个表join起来而是会写成“某内容社区用户每天登录一次登录后产生的行为记录在另一张表请计算最近7天活跃用户的次日留存率”。表面考join和date_diff实际考你懂不懂“活跃用户”和“留存用户”的业务定义。很多人在这一步就栽了。不是不会写SQL而是不知道为什么要用count(distinct case when ...)而不是直接count(distinct user_id)。实际上留存率的计算有两个隐含口径分母是“某日活跃用户”分子是“这些用户中次日仍活跃的人数”这两个口径在SQL里如果不写成清晰的子查询结果一定错。我复盘下来的感受是出题人默认你具备入门的工具能力但更想知道你能不能把模糊的业务问题转化成可执行的取数逻辑。这套题刚好就是围绕这个底层逻辑设计的。1.2 四个核心考察维度整理卷面四个维度最醒目考察维度常见出题形式背后能力点SQL与数据提取留存、漏斗、用户标签计算把业务口径转成代码逻辑业务分析与归因指标下跌/上涨原因分析结构化拆解、假设验证概率与统计基础随机试验、贝叶斯、假设检验统计直觉与严谨性数据敏感度与估算估算题、指标异常判断商业直觉、量级判断这四个维度不是简单的知识考点而是数据分析师日常工作的四类场景接需求取数、看数据报告、做AB实验、支持决策。所以如果你只是为了“刷题”而刷题收获会非常有限你得把这些题当成一个个“小型项目”去推演才能把这套题的价值吃透。2. 核心题型解析与答题框架2.1 SQL题先讲清楚口径再动手写代码这套题的SQL部分最典型的一题是涉及用户活跃和内容互动表的两表关联。我建议不管题目怎么变都按三步来写先定义口径“活跃用户”是哪张表去重键是什么“次日留存”的时间窗口怎么算如果是跨天凌晨怎么处理再搭框架先用子查询算出“基准日活跃用户集合”再关联“次日活跃集合”最后聚合得到留存率。最后只写必要字段别一上来就select *既跑得慢思路也不清晰。拿一个简化版题目举例表A记录了用户登录日志login_log(user_id, login_date)表B记录了用户对内容的点赞记录like_log(user_id, like_date, content_id)。现在需要统计2020年6月每日活跃用户中当天有过点赞行为的人数占比。我当时写的参考答案是这样的with active as ( select distinct user_id, login_date from login_log where login_date between 2020-06-01 and 2020-06-30 ), liked as ( select distinct user_id, like_date from like_log where like_date between 2020-06-01 and 2020-06-30 ) select a.login_date, count(distinct a.user_id) as active_users, count(distinct if(l.user_id is not null, a.user_id, null)) as liked_users, count(distinct if(l.user_id is not null, a.user_id, null)) / count(distinct a.user_id) as liked_ratio from active a left join liked l on a.user_id l.user_id and a.login_date l.like_date group by a.login_date;这里有个关键点关联条件必须同时包含user_id和日期不然会出现跨天错配。很多人只join user_id结果把“历史点赞用户”误算进“当日点赞用户”结论直接失真。2.2 业务思维题指标异动分析是必考题问卷里有一道“某内容社区7日用户活跃数明显下降请分析原因”的题。这是典型的指标异动分析回答质量差距极大。差的回答一上来就说“可能是竞品上线了”“天气变差了”全是猜测好的回答会先确认数据是否真实再拆维度再提假设再设计分析方案。我常用的拆分框架是先看数据本身的准确性是不是埋点漏了是不是报表口径变了是不是节假日/周末因素再拆维度新老用户、渠道来源、设备类型、地区、内容品类。再看行为路径是新增少了还是老用户回访少了是登录环节流失还是首页推荐点击率下降最后给验证方案需要哪些数据来验证下一步怎么查。比如“新用户少了”可以拆为新用户下载量、注册转化率、首刷内容消费情况。任何一个环节松动都可能影响活跃数不能说“我觉得是投放少了”要有数据佐证。出题人看到能按这个流程展开的答案哪怕最终的结论是“需要进一步排查”也会认为你有分析框架比直接给一个武断结论强很多。2.3 概率统计题掌握基础模型别陷进复杂计算概率统计部分这套题考得不算偏但很讲究“统计思维”。比如有一道题提到“抽奖活动的中奖率是1%100个人参加至少一人中奖的概率”这题用1 - (0.99)^100算就行约等于63.4%。看似简单但很多人会凭直觉答“100%”或“1%”说明对概率的乘法原理不够敏感。再比如假设检验部分我看到题目的倾向是比起让你手算t值更希望你能够解释p-value的含义、区别“统计显著”和“业务显著”。这种题就是提醒你平时做AB实验不能只看p值还要看效应量、置信区间、样本量是否足够。实用建议把二项分布、正态分布、条件概率、贝叶斯公式、假设检验这几块吃透配合一些商业案例去理解。比如“先验概率”可以用推荐系统冷启动来解释没有行为数据时我们默认新品目的点击率接近类目平均这就是先验有了用户行为后验概率会更新这就是贝叶斯更新。把这个逻辑想通了比硬背公式有用得多。3. 拆一道典型题留存率计算的完整推演3.1 从SQL到业务口径的全流程这套卷子里有一道留存题让我印象很深给了用户注册表和登录表要求计算注册用户次日、7日、30日留存率。很多人第一反应是直接对登录表做日期差但注册表里有注册日期两表关联时容易多算。正确做法是以注册表为主表保留注册日期reg_date。去关联登录表统计每个用户在注册后第N天是否有登录行为。用datediff(login_date, reg_date) N判断是否构成N日留存。汇总得到retained_users / total_registered_users。一段参考SQL如下with reg as ( select user_id, date(reg_time) as reg_date from user_register where date(reg_time) between 2020-05-01 and 2020-06-30 ), login as ( select user_id, date(login_time) as login_date from user_login where date(login_time) between 2020-05-01 and 2020-07-31 ) select r.reg_date, count(distinct r.user_id) as new_users, count(distinct if(datediff(l.login_date, r.reg_date) 1, r.user_id, null)) as day1_retained, count(distinct if(datediff(l.login_date, r.reg_date) 6, r.user_id, null)) as day7_retained, count(distinct if(datediff(l.login_date, r.reg_date) 29, r.user_id, null)) as day30_retained, count(distinct if(datediff(l.login_date, r.reg_date) 1, r.user_id, null)) / count(distinct r.user_id) as day1_retention_rate from reg r left join login l on r.user_id l.user_id and l.login_date r.reg_date group by r.reg_date;注意l.login_date r.reg_date这个条件目的是防止把注册前的登录记录也算进去。这类细节最能体现一个数据分析师的基础扎实程度。3.2 留存的业务解读比SQL更重要SQL写出来只是第一步面试官真正想看的是你对数字的解释。如果次日留存是40%、7日留存是20%、30日留存是10%这个留存曲线说明什么它说明用户首日体验还行但一周内流失严重产品激活和长期价值有提升空间。这时候你就要能引出“激活漏斗”注册后有没有完成关注、有没有刷到感兴趣内容、有没有产生互动。每一个环节都可能影响后续留存。再看留存曲线形态如果7日留存和30日留存差距不大说明留下来的用户是相对忠诚的核心问题可能出在新用户首次体验如果曲线一直陡降说明产品没有形成使用习惯需要靠内容和通知机制来拉回用户。这些分析在卷面可能只是一个小问但把它答全了面试官会认为你真的理解“留存”这个指标背后的产品含义而不只是会跑数。3.3 案例题估算题的“量级感”是核心估算题在这套卷子里也出现了典型问法是“估算一个城市每月活跃的内容创作者数量”。这种题没有标准答案考察的是量级感和拆解逻辑。我记得当时是这么拆的某城市常住人口约2000万假设目标App渗透率20%月活跃用户400万。创作者是活跃用户中的少数假设5%的人每月至少发布一次内容那么创作者约20万。再考虑创作者中更活跃的头部人群比如每周发布一次的人大约占创作者总数的10%到20%那么核心活跃创作者在2万到4万之间。这个答案对不对不重要重要的是你能不能在60秒内给出一个有理有据的数字区间。面试官最怕的是你支支吾吾说“我不太了解这个行业”其实只要你敢拆、敢假设哪怕结果偏了一倍也能接受。关键是展示出逻辑链条。4. 备考建议与常见问题排查4.1 刷题时最容易踩的五个坑我见过不少候选人刷题很努力但效果很差其实都踩了类似的坑。我把最常见的五个列出来你对照一下自己有没有中招。第一个坑是只刷题不总结框架。今天做一道留存题明天做一道漏斗题两道题看起来不一样其实底层都是“按用户维度去重 时间窗口条件”。如果你能抽象出通用模板后面遇到类似题就很快。我自己的做法是每道SQL题做完后再写出一个“通用版逻辑”下次遇到同类型题目直接套。第二个坑是忽略业务口径。比如“活跃用户”可以有多种定义启动过App算活跃还是有过浏览行为算活跃不同公司定义不同。做笔试题时题目没给出明确定义时你要主动说明“我默认活跃用户是当天有启动行为的用户”这既是严谨也是向面试官展示你的业务意识。第三个坑是统计题只记公式不理解原理。p-value 0.05意味着什么很多人说是“原假设为假的概率”这表述不严谨。p-value是在原假设为真的前提下观察到当前或更极端数据的概率。如果概念本身糊了案例分析中的AB实验题肯定答不好。第四个坑是案例分析没有结构化。不少人的答案像聊天记录想到哪说到哪。建议用分层方式目标拆解、数据获取、分析维度、验证方法、落地建议。哪怕结论不够漂亮结构完整就很加分。第五个坑是眼高手低只看题不做题。数据分析笔试和面试很多时候拼的是临场反应。你看一遍答案觉得“哇明白了”但关上答案自己写一遍可能卡在下笔的第三行。所以一定亲手敲代码、亲手写出分析框架而不是停留在“看懂”的层面。4.2 面试官真正想看的答题习惯从我身边做面试官的朋友那里听到的反馈是他们一般不看候选人的“最终答案”有多完美而是看中间有没有体现思考过程。比如SQL题里你有没有先写注释说明逻辑有没有处理空值有没有考虑到数据去重这些都反映出你平时写数据的习惯。案例分析题也是一样你能快速列出“待验证假设清单”比直接给一个结论更有价值。因为真实工作中领导抛给你一个问题你不可能立刻有答案你需要的是一个可执行的探索路径。笔试时候你呈现这个路径面试官就会认为你“能上手干活”。还有一点很隐晦卷面书写和代码格式。很多人觉得代码能跑就行但面试官看卷面时第一眼看到的是缩进、字段命名、可读性。你写一坨没有格式的SQL即使逻辑对了也会让面试官怀疑你的工程素养。建议平时就养成字段别名清晰、子查询分层的习惯这不是形式主义是真能减少出错率。4.3 复习优先级与时间分配建议如果你的目标是在未来两三个月内完成笔试类面试时间分配可以按下面这个比例来30%给SQL练习重点是窗口函数、多表join、留存漏斗类问题。20%给业务分析框架整理把常见的指标异动、产品功能评估、活动效果复盘各总结一套模板。20%给概率统计基础主要复习描述统计、假设检验、贝叶斯、常见分布。15%给案例分析题结合自己投递的公司业务做针对性练习。15%留给自己复盘试卷和模拟考不要一上来就海量刷题而是做一套、复盘一套、沉淀一套。这里尤其想说一下复盘的重要性。做完一套题不要只看自己错在哪而是把正确思路写下来然后试着自己从零推导一遍。过两天再做一次看能不能在更短时间内独立完成。这个过程虽然累但能真正把“看会”变成“会做”。5. 再补几个现场答题的小技巧最后分享几个我实际做题时积累的小技巧。第一遇到任何指标题先写出口径假设。就算题目已经给定了定义你也别嫌多事加一句“我这里按题目定义活跃用户为当日有登录行为”既避免歧义也向面试官展示你的专业习惯。第二遇到分析题先画框架再填充。你可以在草稿纸上简单列一下背景、目标、数据范围、分析方法、可能结论。这样回答时不会乱也不会漏点。第三遇到不会的题不要硬编数字。估算题可以往合理区间靠但统计题如果你不知道某个公式可以坦白说“这个点我目前掌握得不够但我可以基于已有的知识给出我的推导思路”。面试官也是人能理解“不会但会思考”和“不会又装懂”的区别。第四多选题和开放题注意时间控制。笔试时间是有限的不要一道题卡住就反复想先把会做的做完再回头啃难题。数据分析笔试的容错率并不高会的题拿满不会的题保基本分是个不错的策略。第五心态上别把笔试当考试当作一次模拟真实工作的推演。这种心态转换听起来有点虚但确实管用。你把题目当成“leader临时丢来一个需求”来处理思考方式就完全不一样了。这套小红书2020校招数据分析笔试题我建议你多刷两遍每次都会有不同的收获。第一遍检验知识盲区第二遍训练答题速度第三遍重点打磨业务思维的表达。只要你能把一套题吃透再去面对其他公司的笔试题思路会清晰很多。