数据分析笔试通关指南：从SQL实操到业务案例拆解

“你笔试结果出来了吗”2019年秋季我身边不少准备进互联网做数据岗的朋友都在等小红书的反馈。那段时间小红书正好在大力扩充数据团队校招笔试算是筛人的第一道硬门槛。我自己也完整参加了2019年校园招聘数据分析岗位的在线笔试第一批考完之后最大的感受是这场笔试不是考你背了多少算法而是考你有没有做过真实业务、能不能用数据回答业务问题。这篇文章我拖了很久才整理出来。原因很简单网上能找到的笔经大多只列题目不讲背后的答题逻辑看完还是不知道怎么准备。我想换个写法把当时那套卷子里最核心的几类题型拆开告诉你每道题到底在考什么、面试官想看什么、以及如果让我重新答一遍我会怎么组织答案。内容同时覆盖业务常识、SQL实操、概率统计和案例分析无论你今年打算投小红书还是想去其他大厂做数据分析应该都能用得上。1. 整体认知先搞清楚这场笔试在筛什么样的人1.1 核心需求拆解小红书的分析岗到底要什么人先说结论2019年小红书招数据分析岗要的不是“会写SQL的工具人”而是“能驱动业务决策的分析师”。当时小红书的业务正处于快速增长期社区内容生态和电商交易两条线都在快速迭代数据团队要支撑的业务方非常多——内容运营要看笔记发布、曝光、互动数据电商团队要看转化漏斗、复购、GMV增长团队要看拉新渠道、留存曲线、裂变系数。每个业务方每天都在跟数据打交道分析岗的核心价值就是把这堆底层数据变成业务方能直接执行的建议。所以笔试题目设计上有一个很明显的特点题目不长但每道题都埋在业务场景里。比如给一个社区App的场景让你估算每天新增多少篇笔记给你一张用户行为日志表让你写SQL统计连续登录天数给你一个AB实验数据让你判断新版界面能不能全量上线。这些题目如果单独拎出来看似乎不难但组合在一起考察的就是你有没有数据 sense——读题时能不能抓住业务含义、拆解问题时有没有清晰框架、写出结论时敢不敢下判断。这场笔试的定位也决定了它的难度分布。它不是竞赛型笔试不会考你怎么手推复杂的机器学习公式也不会让你写分布式计算底层原理。它的核心目标是在 90 分钟内快速识别出“具备业务敏感度、有基本数据技能、思路清晰有逻辑”的候选人。所以如果你正在准备类似笔试请先调整好心态——不要死磕高难度技术题而是把精力放在如何把基础题答出业务深度上。1.2 试卷结构复盘时长、题型和分值分布我记得当时是线上笔试全程用牛客网的系统题目类型大致分四块单选题、多选题、SQL编程题和主观案例题。总时长我记得是 90 分钟但不同批次可能略有差异建议你以收到的邮件通知为准。从题目覆盖度来看单选题和多选题主要集中在统计学基础、概率论和业务指标理解上比如什么是 p-value、置信区间怎么解释、留存率如何计算、GMV和流水有什么区别。这类题只要你基础扎实基本是送分题。SQL编程题一般有两道左右一道偏简单条件查询、分组聚合一道偏难留存计算、连续交易、Top N 排序。主观案例题是最拉分的部分。通常会给你一段业务背景介绍然后抛出两三个递进式的问题。比如“某社交产品最近笔记发布量下降了10%请分析可能原因并提出解决方案。”这种题没有标准答案但能看出来你的拆解思路、归因能力和落地建议是否靠谱。我个人觉得大部分候选人笔试折戟都是死在了主观题上——要么只列原因没有优先级要么只写分析思路没有落地方案。下面我准备按题型逐一拆解每类题我会结合当时的真题回忆和常见的“参考答案”来讲解尽量还原我当时答题的思路和踩过的坑。2. 基础题与业务常识题别在这些送分题上翻车2.1 统计与概率高频考点笔试中的统计和概率题说实话难度不高但踩坑率出奇地高。我总结下来核心考点集中在三类第一类是描述性统计。比如给你一组数据让你算均值、中位数、众数、方差或者判断偏态分布中均值和中位数的大小关系。这类题目小学奥数加大学概率论的水平就够了但容易错在读题不仔细比如分不清样本方差和总体方差、忘记标准差和方差的区别。第二类是概率计算。常考的有条件概率、贝叶斯公式、二项分布、泊松分布和正态分布。我印象里有一道题大概是“某App新用户次日留存率是30%假设每个用户每天的活跃行为相互独立问一个用户前三天至少活跃两天的概率”这就是典型的二项分布应用。第三类是假设检验和AB实验基础。比如p-value的含义、第一类错误和第二类错误的关系、置信区间怎么解释。这类题在选择题里出现频次很高因为它直接对应日常业务中的实验分析场景。我提醒一句理解“p-value 是在零假设成立下观察到当前结果或更极端结果的概率”非常关键很多人会把它误解释成“零假设为真的概率”。我的建议是备考时把大学《概率论与数理统计》教材的目录过一遍重点看分布、期望方差、假设检验这几章配合刷 50 道左右的习题基本能覆盖笔试中80%的考点。如果时间充裕再补一点贝叶斯统计的基本概念因为业务题里经常让你“根据历史数据推测某个用户/内容的属性”。2.2 业务指标理解DAU、留存率、GMV背后的细节业务常识题是数据分析岗笔试的重头戏它考的不是概念背诵而是你对指标定义和业务口径的理解。我整理了当时出现频率较高的指标并标注了容易忽略的细节DAU日活跃用户数很多人以为就是“当天有行为的用户数”但严格来说要明确“活跃”的定义——是启动App就算还是要有浏览行为这里存在不同口径。同一用户一天内多次启动算一个人要用去重的用户ID计数。留存率Retention Rate核心要区分“次日留存”“7日留存”“30日留存”的口径。比如次日留存率 第一天新增用户中第二天还有活跃行为的用户占比。注意这里的“Day 0 / Day 1”日期对齐方式新人容易在计算时把日期轴搞错一天。GMV全称 Gross Merchandise Volume即成交总额。但不同平台对 GMV 的口径差异很大——是拍下付款就算还是确认收货就算退款订单是否要剔除作为分析师要清楚数据的统计口径边界不然同一个数字不同人讲出来会差很多。点击率CTR点击次数 / 曝光次数但这里要定义清楚是“用户点击次数”还是“点击行为次数”以及是否排除了重复曝光、无效点击。如果面试官问你“为什么CTR下降了”你第一反应不应该是“用户不爱点了”而是先检查口径变化和异常数据。分享率、互动率、赞藏比这类社区产品的核心指标小红书尤其看重。分享率是分享用户数/活跃用户数互动率通常指点赞、评论、收藏、转发的总和除以曝光或阅读数。赞藏比常用于衡量内容质量如果比值异常可能意味着内容类型发生变化或推荐策略调整。我的经验是准备这类题目时别只背定义要把每一个指标放在一个完整的业务链路里去理解从曝光、点击、浏览、互动到转化、复购、分享清楚每个环节对应哪些指标、它们之间有怎样的转化关系。这样笔试时不管题目换什么产品场景你都能举一反三。3. SQL现场数据岗笔试的分水岭题型3.1 高频SQL题型与通用解题思路SQL 编程题是数据分析笔试里最能拉开差距的环节。会写的人几分钟内解决不会写的人只能看着题目干瞪眼。我梳理了当年考场上出现频率最高的几类题型以及对应的通用解法。第一类是分组聚合与条件筛选。这类题考察基本的 SELECT、WHERE、GROUP BY、HAVING 和 ORDER BY。常考的场景比如统计每个渠道每天的注册用户数、筛选出下单金额超过1000元的用户列表。这类题只要语法熟练基本没问题但要注意分组字段和聚合字段别搞混比如按“日期渠道”分组SELECT 里就能同时出现这两个字段。第二类是留存计算。这是每场笔试几乎必考的题型比如“计算某天新增用户在随后7天内的每日留存率”。留存计算的基本思路可以拆成三步第一步提取新增用户的标识和新增日期第二步提取用户后续每天的活跃记录第三步把新增表和活跃表做关联用日期差判断第N天是否活跃。写SQL时推荐使用 LEFT JOIN 确保新增用户即使没有活跃记录也能出现在结果里再用 GROUP BY 日期计算分母和分子。第三类是“连续出现”问题如连续登录天数、连续交易天数。这类题有固定的解法套路——用 ROW_NUMBER() 窗口函数对用户按日期排序然后用“日期减去排行序号”得到一个差值如果日期是连续的话这个差值应该相同。然后再按用户和差值分组计数就能得到每段连续区间的长度。19年笔试那会儿很多人对这个套路不熟但现在网上资料已经很多了务必练熟。第四类是排名与Top N问题。比如“取每个品类销量前3的商品”典型解法是使用 RANK()、DENSE_RANK()、ROW_NUMBER() 窗口函数按品类分组、按销量排序再过滤出排名小于等于3的记录。注意 RANK 和 DENSE_RANK 在处理并列时的差异业务上如果要求并列名次占用排序位置用 RANK如果要求并列名次不占位用 DENSE_RANK。第五类是时间序列与同比环比。比如计算每日订单量的环比增长率。这种题一般用 LAG() 或 LEAD() 窗口函数取上一周期的值然后做差值计算。当年我笔试时这类题还没大规模出现但现在已经成了新晋高频考点建议提前准备。3.2 完整真题拆解从建表到结果输出的全过程为了让你看明白实际笔试中 SQL 题的完整流程我根据记忆还原了一道比较典型的题目并给出我的解题全过程。题目背景某电商平台现有一张订单表 orders字段包括user_id用户ID、order_date下单日期格式 YYYY-MM-DD、order_amount订单金额单位元、channel下单渠道如 iOS、Android、Web。题目要求写一条 SQL统计 2019 年 8 月每个渠道的日均订单量和日均下单用户数。我当时的答题步骤是这样的确定主查询范围。数据范围是 2019 年 8 月所以 WHERE 条件写 order_date 2019-08-01 AND order_date 2019-08-31或者用 order_date BETWEEN 2019-08-01 AND 2019-08-31。注意 BETWEEN 是闭区间包含两端日期用的时候确认下边界。明确粒度。订单表的粒度是一行一单但一个用户可能一天下多单。日均订单量可以直接 COUNT(order_id)但“日均下单用户数”需要对 user_id 去重后再计数。按渠道分组后8月共有 31 天所以分母除以 31。写出核心 SQLSELECT channel, COUNT(*) / 31 AS avg_daily_orders, COUNT(DISTINCT user_id) / 31 AS avg_daily_users FROM orders WHERE order_date BETWEEN 2019-08-01 AND 2019-08-31 GROUP BY channel;补充说明。我在注释里写了一句订单量统计口径为下单成功且未取消的订单避免因退款单造成数据虚高。这个说明在实际考试中很加分因为面试官能看到你不只是写SQL还在思考口径问题。如果题目升级成“计算每个用户8月首单之后的次日回购率”那么 SQL 会复杂一些思路类似留存计算先找到每个用户的首单日期再关联后续订单判断次日是否复购。核心是构建一个首单日期表然后 JOIN 回原表做时间差判断。笔试碰到这类题建议先写子查询/CTE不要一上来就写长嵌套容易把自己绕晕。3.3 窗口函数、CTE 这些技能现在必须掌握2019年那会儿我印象中笔试环境允许用的 SQL 版本还比较老但窗口函数这类语法已经存在。如果你想稳妥拿高分我强烈建议把以下技能练扎实它们不仅是笔试加分项更是日常工作高频使用的工具CTECommon Table Expression用 WITH 子句定义临时表能把复杂嵌套查询拆成多个清晰步骤。笔试写复杂 SQL 时CTE 能显著降低错误率也方便面试官读懂你的思路。窗口函数ROW_NUMBER()、RANK()、DENSE_RANK()、SUM() OVER()、LAG()、LEAD()。窗口函数最大的优势是在不减少行数的前提下完成计算比如“求每个用户到当前日期的累计消费金额”用 SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date) 一行就搞定。多表连接INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL OUTER JOIN 的语义区别必须清晰。尤其是 LEFT JOIN 可能出现右表多行匹配导致左表数据膨胀的问题笔试中经常靠这些细节出坑。字符串和时间处理函数DATE_FORMAT、DATE_ADD、DATEDIFF 这类函数常用来处理日期笔试中日期计算出现频率极高。如果你离笔试还有两周以上时间我建议每天在 LeetCode 数据库题库刷 3-5 道中等难度题把上述知识点全部覆盖一遍。不要去碰太难的题笔试题的难度一般在 LeetCode 简单到中等之间。4. 主观案例分析题把碎片信息整理成可决策建议4.1 案例题的通用分析框架主观案例题很多人拿到题目的一瞬间是懵的因为题干可能只有两三行但问题却很大很开放。比如“小红书笔记日均发布量最近两周下降了5%请分析原因并提出建议。”这种题目没有唯一正确答案但面试官手里往往有一个差不多的评分维度逻辑是否完整、拆解是否结构化、归因是否合理、建议是否可落地。经过反复总结经验我在第四部分想分享一个我自己整理的“四步分析法”用来应对绝大多数业务分析题第一步锁定指标和维度。明确题目中要分析的核心指标是什么以及它可能被哪些维度影响。比如笔记发布量 活跃内容生产者数量 × 人均发布篇数那么就可以从内容生产者和生产行为两个维度往下拆。维度上常分为用户维度新老用户、不同城市、不同活跃等级、内容维度不同话题、不同内容形式、时间维度工作日/节假日、具体时段、渠道维度不同版本、不同入口。第二步提出假设并排序。结合业务常识列出所有可能的原因然后按“影响程度”和“发生可能性”排出优先级。这里很考验候选人对业务的理解深度。以笔记发布量下降为例合理假设包括头部活跃作者流失、推荐流量下降导致曝光减少、内容审核政策变化、竞品分流用户时间、季节性因素等。建议回答时明确说“我会优先排查能快速验证且影响面大的假设”。第三步设计数据验证方案。告诉面试官你会用哪些数据表、哪些指标、做什么样的对比来验证这些假设。比如想验证“推荐流量下降是否导致发布量下降”可以对比近两周推荐渠道带来的App访问时长和笔记发布引导点击率如果两者同步下降假设成立的概率就大。这里不需要给出具体 SQL但要体现出“你清楚数据从哪来、怎么用”。第四步输出业务建议。根据验证结果提出可执行的动作包括短期措施和长期机制。不要停留在“优化推荐算法”这种空话要落地到例如“针对活跃创作者启动召回策略通过Push和私信触达”、“在App端发布器增加图文编辑模板以降低创作门槛”这样的具体方案。4.2 常见业务场景与答题示范下面我把当年和其他批次中出现的几类典型案例题场景列出来每个场景给出一个简化版的答题框架你可以照着练。场景一社区内容生态类。“某社区的优质内容占比下降低质内容曝光升高用户互动率下滑请分析原因。”我的答题思路先定义“优质内容”和“低质内容”的判定标准没有这个前提一切分析都站不住脚。再拆解内容和流量两个链路。内容侧看优质内容供给量是否下降比如优质的创作者是否在流失、选题方向是否变化流量侧看推荐策略是否调整比如推荐系统是否开始偏向点击率更高但互动质量低的内容导致互动率下滑。最后给出建议优化推荐质量分权重将“用户长按不感兴趣”“举报率”等负反馈信号纳入算法同时为优质创作者提供流量激励稳住在活跃创作者。场景二增长拉新类。“某产品新增用户数量增长但7日留存下降怎么分析”这类题在面试中出现频率相当高。我的框架是先做新增用户的结构拆解是渠道结构变了还是用户年龄/地域结构变了再拆解留存环节是首日体验出了问题导致用户次日就不来了还是新用户没有找到核心功能价值。建议中常用举措包括优化新手引导流程、针对高流失渠道调整投放策略、为新用户做个性化推荐。场景三商业变现类。“某电商平台GMV下降10%如何定位原因”先把GMV拆成用户数 × 客单价 × 购买频次。用户数下降可能来自流量侧客单价下降可能来自品类结构或折扣力度变化购买频次下降可能来自复购激励减弱。再结合渠道、品类、新老客等维度做细拆形成假设后通过数据验证。这类题目最忌讳眉毛胡子一把抓一定要把指标先拆到可计算、可验证的颗粒度。4.3 表达技巧让面试官一眼看到你的逻辑主观题作答时除了内容本身表达形式也很重要。在线笔试一般是用文字输入答案你写的内容面试官会逐字看。我总结了几条非常实用的表达建议先给结论再给过程。每个问题先说“我认为应优先排查XX”然后再说你的验证路径这样面试官能迅速抓住你的重点。用数字编号和层级标题。例如“1. 原因假设1.1 假设A1.2 假设B”这种形式在纯文字环境中可读性很强也是我在笔试中最爱用的格式。区分“马上能做的”和“需要长期建设的”。建议部分至少包含一条今天就能安排的动作比如发一张数据看板给业务方看和一条长期机制比如建立广告投放反作弊监控体系体现务实和远见。额外提一句案例分析题不要回避“概率不大但影响很大”的黑天鹅因素。比如数据口径调整导致的历史数据不可比或者节假日效应带来的自然回落。这类原因在实际业务中经常出现如果能在回答里主动提及“在分析前先确认数据口径和异常波动”会显得你非常有实战经验。5. 工具与学习路径笔试后如何持续补齐能力5.1 考后复盘清单笔试结束后不管结果如何一定要做一次考后复盘。我通常建议按下面这个清单逐项过一遍统计与概率题有没有因为概念混淆丢分比如置信区间解释错误、p-value 理解有偏差。SQL题有没有因为语法细节丢分比如窗口函数不会用、日期函数不熟悉、NULL 值处理出错。业务指标题有没有因为口径不清晰丢分比如留存率的分母选错。案例分析题有没有因为缺少结构或可落地建议丢分每一类问题都可以对应一个后续学习动作。比如SQL 不熟就去刷题统计概念混乱就回头看教材案例分析没有框架就多读数据分析面经和行业案例。5.2 推荐学习资源与实操工具数据分析这条路上工具永远是为业务理解服务的但工具本身也需要持续打磨。我结合自己的使用经验整理了几个不同场景推荐的工具和资源数据处理与分析日常使用 Python Pandas 做数据清洗、透视和可视化效率非常高。网上有人分享“excel python飞速搞定数据分析与处理”的案例很适合办公场景中不想切换多个工具的分析师。Excel本身也别丢很多业务方还是习惯让你给一张 Excel 表。数据库与SQL建议在自己电脑上装一个 MySQL 或 PostgreSQL导入一份真实的业务模拟数据比如开源的电商数据集每天练一道SQL题。Navicat 或 DBeaver 这类数据库客户端也建议装一个尤其是 DBeaver能直接连接多种数据库并把查询结果做可视化图表用来快速排查数据非常方便。数据可视化与报表Tableau、Power BI 和开源的 Superset 都可以。如果你不想装太重的东西直接用 Python 的 Matplotlib、Seaborn 或者 Plotly 做探索性分析也够了。重点是培养“拿数据画图快速看出异常”的习惯。商业分析案例多看商业数据分析报告和行业分析案例比如电商、社区产品、金融风控领域的案例。金融风控数据分析这个方向也很值得学习它和普通互联网数据分析的区别在于对模型稳定性和可解释性要求更高能训练你的严谨思维。大数据平台如果公司有离线数仓和 Spark 环境建议学一下基本的 Spark 数据处理。现在很多社区和一些面试题会提到“spark数据分析案例”说明大数据技能已经成为中级数据分析师的隐性门槛。5.3 从“会做题”到“会做事”数据分析师的能力模型最后我想聊聊比笔试更长远的事。笔试只能证明你在特定时间、特定压力下把题目做出来了但数据分析师这个岗位的真正价值是持续在模糊、复杂、多变的业务问题中找到关键路径。我个人的体会是数据分析师的能力大致分三层第一层是工具层包括 SQL、Python、Excel、BI工具这是入行的敲门砖。 第二层是方法论层包括实验设计、因果推断、业务指标体系搭建、A/B测试等这决定了你能不能科学地回答业务问题。 第三层是业务判断力层这是最难的需要你花大量时间和业务方泡在一起理解他们的痛点、用户的真实反馈、行业的竞争格局。到了这一层你产出的是“决策建议”而不是“数据报告”。如果你的目标是长期做数据分析建议刚入行时不要只盯着 SQL 和 Python 等硬技能可以试着每周花一点时间读业务周报、看产品功能迭代、分析竞品动态。这些东西短期看和笔试无关但长期决定你能走多深。再说一个我踩过多次坑后总结出来的心得笔试答主观题时永远不要只写“我要做数据分析”而不写“具体怎么做”。面试官看到“我认为要提升用户留存”这种话心里是不会加分的因为他没看到你的思考过程。你要写的是“我建议从新用户首次启动后的关键行为出发设计一个分步引导流程并通过A/B测试验证不同引导策略对次日留存的影响”。只有具体到可以执行别人才会相信你是真的会做而不是只会说。这批笔试已经过去几年小红书的业务和数据体系也早就迭代了好几轮。但我相信这类在线笔试考察的核心逻辑没有变找一个有数据 sense、能做实事、能跟业务对话的人。希望这份从2019年现场带回的细节拆解能给你接下来的准备提供一点点方向感。