我2019年8月底在牛客网上看到小红书校招数据分析岗开放投递当时这个岗位还不像现在这么卷成一片红海。数据分析本身是那几年才逐渐从运营和商业分析里独立出来的方向小红书又正处于内容社区和电商双线增长的阶段DAU涨得凶业务上对数据人才的需求特别明确。我投了简历之后很快收到了在线笔试第一批的通知时间排在九月初是一整轮线上的限时作答。这篇文章我想把当时那场笔试从头到尾复盘一遍题型长什么样、每类题背后在考什么、我当时的答法、以及后来回头看这些题对准备数据岗笔试的人有什么参考价值。哪怕你不是投小红书是投其他互联网公司的数据分析岗位这场笔试的考点结构也很有代表性——SQL、统计概率、业务案例分析这三板斧基本是数据岗笔试的标配。1. 从投递到笔试筹备考前一周我做的事和踩过的信息差1.1 为什么选了小红书的数据分析岗2019年的校招市场上数据分析岗有一个很明显的特点岗位名字一样做的事情可以差很远。有的公司数据分析挂在运营部下干的活是写周报和取数有的公司挂在用户增长组天天和AB实验、漏斗模型打交道还有一些公司数据分析实际是算法工程师的平替岗一样要啃复杂的机器学习模型。小红书当时的数据分析岗更偏内容生态用户增长的组合。小红书的业务核心是UGC内容社区用户的完整链路是浏览-搜索-互动-发布笔记这个链路里每个环节都在生产数据。做数据的人能接触的题目从内容推荐效果评估、社区氛围指标监控、电商转化漏斗到新用户留存分析跨度很大。对一个刚毕业想入行、又不想一上来就写纯SQL报表的人来说这是很理想的起点。我还有一个比较个人的考量小红书当时处在业务快速扩张期岗位职责还没有被切得非常碎数据分析师往往要自己完成接需求-取数-分析-给结论的完整闭环。这意味着你在一场校招笔试里可能会遇到SQL题、概率题、案例分析题同时出现。对喜欢综合题型的我来说这比纯考算法题友好很多。1.2 考前一周我把时间花在了哪里从收到笔试通知到真正上考场大概间隔七天。这七天我没有选择盲目刷题而是先做了信息收集再按优先级分配时间。当时我通过牛客网的面经帖和学长学姐的分享大概拼凑出小红书数据分析笔试的常见范围行测逻辑题、SQL题、统计概率题、业务案例分析题。机器学习相关的内容占比很低算法题基本不考。基于这个判断我把一周时间做了这样的分配SQL刷题约3天重点刷了牛客网的SQL实战题库以及LeetCode数据库板块中涉及窗口函数、多表关联、连续问题的中等难度题。每天早晚各固定一小时专门用来练习看到题目先想清楚表之间的关联关系再动手写代码的习惯。统计概率复习约2天把概率论教材里条件概率、贝叶斯公式、常见分布二项分布、正态分布、泊松分布过了一遍。重点是会推导常见统计量的表达式比如两组样本的点击率差异是否显著这种假设检验题。业务分析框架梳理约1天围绕指标异动归因漏斗分析留存分析三个方向各准备一个答题框架。当时我没有死记硬背模板而是把每个框架背后的业务逻辑想清楚了后面实战时就能灵活套用。行测逻辑约0.5天刷了一些数字推理和图形推理的题目保持手感。这一块投入产出比不高因为它主要考思维反应短时间很难有质的提升但也不能完全裸考。现在回头看这个时间分配是合理的。笔试里SQL的题量和分值占比最大而SQL又是短期内最容易通过刻意练习提升的板块统计概率需要理解概念而不是背公式投入的时间主要用于恢复思维习惯业务案例分析则更多靠积累和结构化表达临时抱佛脚效果有限但准备一套自己的分析框架确实有用。2. 在线笔试全流程还原题型分布、系统限制和真实的作答节奏2.1 三个单元的内容构成我记得当时整场笔试被分成了三个大的单元每个单元单独计时到时间自动交卷不能回头改上一单元的答案。单元题型大致题量限时内容特点第一单元行测逻辑题约25题40分钟左右数字推理、图形推理、逻辑判断偶有资料分析小题组第二单元SQL与数据基础题约5-6题50分钟左右手写SQL、表结构设计、数据口径判断题第三单元统计概率与业务案例题约4-5题60分钟左右概率计算、假设检验、业务指标拆解与案例论述三个单元加起来大概两个半小时。体感上第一单元的时间最紧张因为行测题本身需要读题和思考加上数字推理题不确定性强遇到卡壳的题很容易超时。第二、三单元虽然是大题但因为每道题有明确的作答目标反而能更好地控制节奏。一个印象很深的细节是笔试系统明确提示每个单元的提交按钮都是独立的提交后不能再进入。这意味着考试策略从一开始就不是把所有题做完而是在自己能力范围内把每道题做对。我当时的策略是行测部分遇到超过一分半钟还没思路的题直接标记跳过确保后面的逻辑判断题有充足时间。2.2 在线笔试环境里那些容易被忽略的坑2019年的在线笔试系统已经相当成熟了但依然有几个坑值得提醒后来的同学。第一切屏检测非常严格。笔试系统会监控浏览器的焦点变化一旦你切出笔试页面系统会记录一次切屏记录切屏次数达到一定阈值后可能会强制交卷。我当时为了安全起见提前把所有可能用到的软件都关掉了只留一个浏览器窗口。考试过程中如果误触了系统提示或者打开了一个广告页也会被记录为切屏这点要特别注意。第二SQL题基本不能本地调试。大多数在线笔试系统的SQL题是在一个文本框中直接作答没有真实的数据库环境也跑不了测试用例。你写出来的SQL是否正确只能靠自己手动推演。这要求你写SQL时自带人肉执行器的能力——每写一段代码脑子里就要过一遍它对数据行的处理结果。第三网络和浏览器兼容性问题。在线笔试最怕写了一大半答案突然断网或者浏览器崩溃。考前一天我专门测试了网络环境并且把系统推荐的Chrome浏览器更新到最新版本关掉了所有插件。建议参加这类笔试前用目标公司的模拟笔试链接提前走一遍流程确认摄像头权限、系统通知权限都已经正常放行。3. SQL实战题复盘连续登录、留存率与TopN的三种高频考法3.1 连续N天登录用户数一个把连续性转成分组的经典套路考题大致还原给定一张用户登录表表字段包括uid和login_date其中每个用户一天内可能有多条登录记录。要求统计连续登录3天及以上的用户数量。这个题在2019年的数据岗笔试里出现频率极高可以说是SQL综合能力的试金石。它的难点在于关系型SQL天然不擅长处理连续这种基于行间关系的判断你需要想办法把连续问题转化成离散的分组问题。我当时写的是窗口函数解法SELECT COUNT(DISTINCT uid) AS user_cnt FROM ( SELECT uid, login_date, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER(PARTITION BY uid ORDER BY login_date) DAY) AS grp_date FROM ( SELECT uid, DATE(login_date) AS login_date FROM user_login_log GROUP BY uid, DATE(login_date) ) t1 ) t2 GROUP BY uid, grp_date HAVING COUNT(*) 3;这个解法的核心原理是连续登录的日期序列在减去行号之后会得到同一个基准日期。比如某用户连续3天登录登录日期分别是9月1日、9月2日、9月3日对应的行号是1、2、3减去对应天数后得到8月31日、8月31日、8月31日——这三行被划入了同一个组。一旦分了组连续问题就变成了统计每个组内有多少条记录的问题。要是笔试环境不支持窗口函数也有替代写法。用自连接关联间隔2天的日期再配合EXISTS判断中间那天是否存在SELECT COUNT(DISTINCT a.uid) FROM user_login_log a JOIN user_login_log b ON a.uid b.uid AND b.login_date DATE_ADD(a.login_date, INTERVAL 2 DAY) WHERE EXISTS ( SELECT 1 FROM user_login_log c WHERE c.uid a.uid AND c.login_date DATE_ADD(a.login_date, INTERVAL 1 DAY) );这个写法求的是存在某一天t用户在第t天、第t1天、第t2天都登录过本质上覆盖了所有以t为起点的连续3天登录的情况。注意这类题最大的易错点不是SQL语法而是数据去重。用户一天内登录多次是常态如果不先按uid DATE(login_date)去重直接用原始表做窗口函数同一个用户同一天的多条记录会被当成多天登录导致连续天数虚增。我当时是先做了内层去重再跑外层逻辑这样结果才可靠。3.2 新用户留存率口径比语法更容易翻车第二道SQL题是留存计算。题目给了一张活跃表user_active字段是uid和active_date要求计算每天新增用户在未来第1天、第7天的留存率。留存率本身不算难但非常容易在口径上翻车。一个常见的错误是直接拿某天活跃的用户中前一天也活跃的用户数来当作次日留存这其实是活跃用户留存率而不是新增用户留存率。新增用户留存率的正确口径是先找出每个用户的首个活跃日期作为其新增日期再统计这些用户在新增后第N天仍然活跃的占比。我当时的写法是这样的WITH first_active AS ( SELECT uid, MIN(active_date) AS first_date FROM user_active GROUP BY uid ) SELECT first.first_date, COUNT(DISTINCT first.uid) AS new_user_cnt, COUNT(DISTINCT act.uid) AS day1_active, ROUND(COUNT(DISTINCT act.uid) / COUNT(DISTINCT first.uid), 4) AS day1_retain_rate FROM first_active first LEFT JOIN user_active act ON act.uid first.uid AND act.active_date DATE_ADD(first.first_date, INTERVAL 1 DAY) GROUP BY first.first_date;这里有几个关键细节第一必须用LEFT JOIN而不是INNER JOIN。如果新用户第2天没有活跃INNER JOIN会直接把这一行过滤掉导致分母变小留存率虚高。用LEFT JOIN能保留未活跃的用户保证分于是完整的新用户数。第二COUNT(DISTINCT)非常重要。活跃表里用户可能在同一天有多条行为记录如果直接COUNT(act.uid)同一天重复活跃的同一用户会被计多次。用COUNT(DISTINCT)能保证统计的是用户粒度的活跃数。第三留存率的定义要前置确认。实际业务中新增用户可能有不同口径账号注册算不算新增首次浏览算不算新增付费用户的新增怎么定义笔试虽然没有业务背景但答题时最好在注释里写清楚你采用的口径这会让阅卷人觉得你有严谨的数据意识。这种题在真实业务里会演变成更复杂的版本比如计算7日留存率的完整曲线用一张透视表呈现各渠道用户在第1天、第3天、第7天、第14天的留存率背后的SQL逻辑和上面是一致的只是把CASE WHEN拆得更细。3.3 TopN与行列转换窗口函数与条件聚合的组合使用第三道SQL大概率是TopN问题。题目大致是给定商品销售表sales字段包括category、product_id、sales_amount要求找出每个品类下销售额排名前3的商品。这个题在2019年有多种解法但最清晰、最不容易出错的是窗口函数SELECT category, product_id, sales_amount FROM ( SELECT category, product_id, sales_amount, ROW_NUMBER() OVER(PARTITION BY category ORDER BY sales_amount DESC) AS rn FROM sales ) t WHERE rn 3;注意如果销售额相同的商品希望都进入榜单应该用DENSE_RANK()而不是ROW_NUMBER()。比如销售额第3名有两个并列商品ROW_NUMBER()只会选其中一个DENSE_RANK()会把两个都保留。这个细节在笔试里很容易被忽略但它正好体现了对业务含义的理解——实际业务中并列排名通常应该显示为并列。另一个常见考点是行列转换。题目会给一张长表字段是month、channel、amount要转换成每个渠道占一列的宽表。解法就是条件聚合SELECT month, SUM(CASE WHEN channel A渠道 THEN amount ELSE 0 END) AS channel_a_amount, SUM(CASE WHEN channel B渠道 THEN amount ELSE 0 END) AS channel_b_amount, SUM(CASE WHEN channel C渠道 THEN amount ELSE 0 END) AS channel_c_amount FROM sale_month_channel GROUP BY month;这类题考的是两类窗口函数的能力用PARTITION BY做分组排序用CASE WHEN配合聚合函数做条件展开。两个技能组合起来基本就能应对数据岗SQL笔试里的大部分难题。3.4 手写SQL时怎么在没有数据库环境的情况下尽可能保证正确在线笔试系统里写SQL最大的痛点是没法跑测试用例所以你必须练就一套人肉调试的方法。我的习惯是写完之后在脑内构造一个3-5行的小样本表一行一行代入SQL逻辑手动推演每一步的结果。重点关注JOIN之后是否产生笛卡尔积或重复行。检查GROUP BY的粒度是否正确。比如按用户分组后SELECT里能不能出现login_date这种非聚合字段在严格模式下会报错笔试系统不一定会提示但阅卷人会看到。日期函数注意时区问题。DATE()函数和DATE_ADD()函数的参数类型不匹配时容易得到NULL导致结果直接不对劲。4. 统计概率与业务分析题从算得对到讲得清4.1 一道贝叶斯条件概率题考的是直觉和公式哪个先出场笔试第三单元有一个让我印象很深的概率题大意是某内容平台的内容池中约5%的内容会被标记为低质内容。平台训练了一个审核模型模型对真正低质内容能够准确标记出来的概率是90%同时有10%的概率将正常内容误判为低质。现在有一条内容被模型判定为低质问它真正是低质的概率是多少这是一道标准的贝叶斯条件概率题。设事件A为内容真正低质事件B为模型判定为低质。题目给出P(A) 0.05先验概率P(B|A) 0.90敏感度真正低质被判出来的概率P(B|非A) 0.10误报率正常内容被判为低质的概率要求的是P(A|B)即模型判低质时内容真的低质的概率P(A|B) P(B|A) × P(A) / [P(B|A) × P(A) P(B|非A) × P(非A)]代入数字P(A|B) 0.90 × 0.05 / (0.90 × 0.05 0.10 × 0.95) 0.045 / (0.045 0.095) ≈ 32.1%也就是说即使模型看起来准确率很高一条被判定为低质的内容真正是低质的概率也只有大约三分之一。这个结果非常反直觉但它恰恰是数据分析师在实际工作中经常遇到的场景。模型的输出结果不等于真实标签先验概率对后验概率的影响比大多数人想象中更大。类似的案例在推荐系统评估、风控模型、医学检测中都大量存在。笔试里考这道题目的不是看你能否算出32.1%而是看你能不能理解为什么准确率90%的模型其预测结果的可信度却远远不到90%。答题时除了写出计算过程我还额外解释了一句在实际内容质量治理中如果想要提升判低质后的准确率一方面要提高模型对低质内容的敏感度另一方面可以通过扩大低质内容的先验比例比如优先审核可疑内容来提升判后概率。这种延伸说明能体现数据分析的思维深度。4.2 假设检验题算Z统计量只是开始解读才是分水岭接下来是一道假设检验题和AB实验高度相关。题目大意是某推荐策略改版后对照组用户的点击率为2.0%实验组用户的点击率为2.2%两组样本量各为10万。问这个提升在统计上是否显著。这道题的数据很典型直接套正态近似法算Z统计量就行。设p1 0.022p2 0.020合并比例p (n1×p1 n2×p2) / (n1 n2) (2200 2000) / 200000 0.021。标准误SE sqrt(p(1-p) × (1/n1 1/n2)) sqrt(0.021 × 0.979 × 0.00002) ≈ 0.00064Z (0.022 - 0.020) / 0.00064 ≈ 3.12对应的p值小于0.01在0.05显著性水平下拒绝原假设认为实验组点击率显著高于对照组。但这里最值得说的不是Z统计量怎么算而是对结果的解读。统计显著不等于业务显著0.2个百分点的点击率提升可能统计学上很稳定但业务上是否值得全量上线还要看这个提升是否被其他指标稀释。比如点击率是涨了但人均停留时长降了或者误点击率上升了那就得综合评估。笔试的案例分析部分经常这类题一起出给你一个AB实验的结果表格点击率、转化率、客单价、退货率几个指标放在一起让你判断应该不应该全量上线。这里的答法是分层的先看核心指标的显著性判断策略是否有效果。再看反面指标有没有变差防止顾此失彼。看样本量和实验时长是否足够防止辛普森悖论或者实验周期不完整。最后结合业务背景做判断比如大促期间策略效果可能被稀释。4.3 案例论述题DAU下滑10%你怎么排查案例分析题是整场笔试里最开放、也最考验结构化表达能力的题目。当时的题目大意是某内容社区产品最近一周DAU环比下降了10%作为数据分析师你的排查思路是什么这种题没有标准答案但存在明显的踩分点。我当时的回答分成四个层次第一层先确认数据本身的可靠性。是统计口径变了还是埋点出了问题有没有节假日或特殊事件影响如果数据本身不可靠后面所有分析都是空中楼阁。第二层拆解指标。DAU 新增用户 老用户回流 - 老用户流失。先确定下降主要来自哪个部分。如果新增没有明显变化那问题大概率出在老用户活跃上如果新增变少就要看渠道投放和外部竞争。第三层进一步拆分维度。老用户活跃度下降要按渠道、版本、地域、用户注册时长拆分看下降是普适性的还是集中在一部分人群里。这个时候往往会用到维度下钻的方法——先整体再按多个维度交叉拆解。第四层关联业务和内容。小红书这类内容社区产品的DAU下降尤其要关注内容供给侧的波动。如果近一周笔记发布量明显下降或者推荐供给不够用户刷不出新内容活跃自然下滑。这种判断需要结合内容生产数据和推荐系统日志来做交叉验证。这类题真正想考察的其实是你面对模糊问题时展现出的分析思路。如果你一上来就急着给结论反而会显得不专业从数据口径校验到维度拆解再到业务逻辑回归用层层递进的方式展示思路阅卷人才会觉得你具备独立扛起一个分析项目的能力。5. 考后复盘数据岗笔试的知识点优先级与避坑清单5.1 从这场笔试反推出来的高频知识点排序考完之后我把整张卷子回顾了一遍惊讶地发现真正拉开差距的并不是偏题怪题而是几个基础模块的熟练度。后来我又陆续参加了其他公司的数据分析笔试发现考点结构高度相似。按我的个人经验给准备数据岗笔试的同学一个优先级参考优先级知识点考察方式投入产出比最高SQL窗口函数、多表关联、分组聚合手写SQL题极高短期可提升高条件概率/贝叶斯、假设检验、二项分布选择题计算题高理解概念后见效快高业务分析框架留存、漏斗、指标拆解案例分析题较高需要积累中行测逻辑选择题中等训练后稳定中低机器学习基础概念偶尔出现看岗位要求不建议重点投入数据岗笔试和算法岗笔试最大的不同就是SQL和业务意识的权重远大于模型推导。总有人担心是不是要精通各种机器学习算法才能过笔试实际上大多数数据分析日常工作是和SQL、指标、AB实验打交道机器学习更多是锦上添花。5.2 我在笔试中踩过的坑希望你避开写SQL前没有先想清楚表的结构导致中途改了两次JOIN条件。在线笔试系统里改代码的成本比本地IDE高很多因为没有语法高亮和自动补全思路不连贯时特别容易漏字段。后来我养成的习惯是先在草稿纸上画出表结构和关联键再动笔写SELECT。行测部分在一道图形推理上花了太长时间导致后面资料分析题时间不够。一道题卡住超过90秒就应该立刻放弃行测的得分策略本来就是用时间换分数而非每道题都做对。案例分析题只写了分析思路没有对可能的结果做延伸讨论。后来和其他拿到后续面试的同学交流发现笔试阅卷人更看重的是能不能从分析推到行动。也就是说你不仅要回答DAU为什么下降还要回答如果发现是某个渠道新增质量变差下一步应该怎么办。概率题审题太快差点把误报率当成模型准确率的反向操作。条件概率题目一定要把事件定义清楚先设事件A、B再把已知条件逐一对应到符号最后套公式。这个过程看起来慢其实是避免计算错误的最快方式。5.3 关于第一批笔试的备注如果你投递的岗位也标注了类似第一批笔试的字样有一点值得注意第一批通常意味着较早的投递批次题目的风格可能和后续批次略有差异但它不代表试水或者简单。从我了解到的情况看不同批次的试题难度基本一致只是题目内容会有变化。早投递的优势在于后续批次有概率出现第一批的变体题比如把连续登录天数从3天改成5天把留存从次日改成3日。所以如果你赶上了第一批不要抱着反正后面还有批次的心态随便应付反过来如果投得晚也可以去牛客网和论坛翻翻前辈们对第一批的回忆帖把常见题型提前过一遍。6. 给正在准备数据岗笔试的人三个比刷题更重要的习惯说完了当年那场笔试的具体内容最后再聊几句我自己在后来多次笔试面试中验证过的体会。第一个习惯是养成先想清楚再动手的答题节奏。笔试的时间压力会让人下意识地急着写答案但数据岗笔试的所有题目都有一个共同点想清楚方向比写得多重要。SQL题先想关联键和聚合粒度概率题先设事件和符号案例分析先搭分析框架。这个思维模式在入职之后做真实业务分析时同样适用。第二个习惯是把每一道题都当成一次业务沟通来对待。笔试里那道贝叶斯题如果你只是算出一个32.1%就结束和算出结果之后补充一句这意味着模型判低质后直接惩罚内容是有风险的需要结合其他信息做综合判断在阅卷人眼里的评价完全不同。数据分析师的价值不在于会算数而在于能把数字背后的业务含义讲清楚并推动正确的决策。第三个习惯是建立自己的错题本。我备考期间专门建了一个文档把所有写错的SQL、理解偏差的概率题、漏掉的业务分析维度都记下来并写下当时出错的原因。这个错题本在我后续参加的所有笔试里都发挥了实质作用因为数据岗笔试的高频考点就那么几个你犯过的错大概率会以变形的方式再次出现。把这些坑提前填平考试时自然会从容很多。如果你也准备投数据分析岗位希望这篇笔试复盘能帮你对这场考试到底考什么、该怎么准备有一个更清晰的判断。数据岗笔试的门槛不高但区分度不小真正的分水岭往往不在你背了多少公式和函数而在于你能不能像数据分析师一样思考问题——从数据出发用逻辑说话让结论落地。
小红书数据分析岗笔试复盘：SQL、统计概率与业务案例全解析
我2019年8月底在牛客网上看到小红书校招数据分析岗开放投递当时这个岗位还不像现在这么卷成一片红海。数据分析本身是那几年才逐渐从运营和商业分析里独立出来的方向小红书又正处于内容社区和电商双线增长的阶段DAU涨得凶业务上对数据人才的需求特别明确。我投了简历之后很快收到了在线笔试第一批的通知时间排在九月初是一整轮线上的限时作答。这篇文章我想把当时那场笔试从头到尾复盘一遍题型长什么样、每类题背后在考什么、我当时的答法、以及后来回头看这些题对准备数据岗笔试的人有什么参考价值。哪怕你不是投小红书是投其他互联网公司的数据分析岗位这场笔试的考点结构也很有代表性——SQL、统计概率、业务案例分析这三板斧基本是数据岗笔试的标配。1. 从投递到笔试筹备考前一周我做的事和踩过的信息差1.1 为什么选了小红书的数据分析岗2019年的校招市场上数据分析岗有一个很明显的特点岗位名字一样做的事情可以差很远。有的公司数据分析挂在运营部下干的活是写周报和取数有的公司挂在用户增长组天天和AB实验、漏斗模型打交道还有一些公司数据分析实际是算法工程师的平替岗一样要啃复杂的机器学习模型。小红书当时的数据分析岗更偏内容生态用户增长的组合。小红书的业务核心是UGC内容社区用户的完整链路是浏览-搜索-互动-发布笔记这个链路里每个环节都在生产数据。做数据的人能接触的题目从内容推荐效果评估、社区氛围指标监控、电商转化漏斗到新用户留存分析跨度很大。对一个刚毕业想入行、又不想一上来就写纯SQL报表的人来说这是很理想的起点。我还有一个比较个人的考量小红书当时处在业务快速扩张期岗位职责还没有被切得非常碎数据分析师往往要自己完成接需求-取数-分析-给结论的完整闭环。这意味着你在一场校招笔试里可能会遇到SQL题、概率题、案例分析题同时出现。对喜欢综合题型的我来说这比纯考算法题友好很多。1.2 考前一周我把时间花在了哪里从收到笔试通知到真正上考场大概间隔七天。这七天我没有选择盲目刷题而是先做了信息收集再按优先级分配时间。当时我通过牛客网的面经帖和学长学姐的分享大概拼凑出小红书数据分析笔试的常见范围行测逻辑题、SQL题、统计概率题、业务案例分析题。机器学习相关的内容占比很低算法题基本不考。基于这个判断我把一周时间做了这样的分配SQL刷题约3天重点刷了牛客网的SQL实战题库以及LeetCode数据库板块中涉及窗口函数、多表关联、连续问题的中等难度题。每天早晚各固定一小时专门用来练习看到题目先想清楚表之间的关联关系再动手写代码的习惯。统计概率复习约2天把概率论教材里条件概率、贝叶斯公式、常见分布二项分布、正态分布、泊松分布过了一遍。重点是会推导常见统计量的表达式比如两组样本的点击率差异是否显著这种假设检验题。业务分析框架梳理约1天围绕指标异动归因漏斗分析留存分析三个方向各准备一个答题框架。当时我没有死记硬背模板而是把每个框架背后的业务逻辑想清楚了后面实战时就能灵活套用。行测逻辑约0.5天刷了一些数字推理和图形推理的题目保持手感。这一块投入产出比不高因为它主要考思维反应短时间很难有质的提升但也不能完全裸考。现在回头看这个时间分配是合理的。笔试里SQL的题量和分值占比最大而SQL又是短期内最容易通过刻意练习提升的板块统计概率需要理解概念而不是背公式投入的时间主要用于恢复思维习惯业务案例分析则更多靠积累和结构化表达临时抱佛脚效果有限但准备一套自己的分析框架确实有用。2. 在线笔试全流程还原题型分布、系统限制和真实的作答节奏2.1 三个单元的内容构成我记得当时整场笔试被分成了三个大的单元每个单元单独计时到时间自动交卷不能回头改上一单元的答案。单元题型大致题量限时内容特点第一单元行测逻辑题约25题40分钟左右数字推理、图形推理、逻辑判断偶有资料分析小题组第二单元SQL与数据基础题约5-6题50分钟左右手写SQL、表结构设计、数据口径判断题第三单元统计概率与业务案例题约4-5题60分钟左右概率计算、假设检验、业务指标拆解与案例论述三个单元加起来大概两个半小时。体感上第一单元的时间最紧张因为行测题本身需要读题和思考加上数字推理题不确定性强遇到卡壳的题很容易超时。第二、三单元虽然是大题但因为每道题有明确的作答目标反而能更好地控制节奏。一个印象很深的细节是笔试系统明确提示每个单元的提交按钮都是独立的提交后不能再进入。这意味着考试策略从一开始就不是把所有题做完而是在自己能力范围内把每道题做对。我当时的策略是行测部分遇到超过一分半钟还没思路的题直接标记跳过确保后面的逻辑判断题有充足时间。2.2 在线笔试环境里那些容易被忽略的坑2019年的在线笔试系统已经相当成熟了但依然有几个坑值得提醒后来的同学。第一切屏检测非常严格。笔试系统会监控浏览器的焦点变化一旦你切出笔试页面系统会记录一次切屏记录切屏次数达到一定阈值后可能会强制交卷。我当时为了安全起见提前把所有可能用到的软件都关掉了只留一个浏览器窗口。考试过程中如果误触了系统提示或者打开了一个广告页也会被记录为切屏这点要特别注意。第二SQL题基本不能本地调试。大多数在线笔试系统的SQL题是在一个文本框中直接作答没有真实的数据库环境也跑不了测试用例。你写出来的SQL是否正确只能靠自己手动推演。这要求你写SQL时自带人肉执行器的能力——每写一段代码脑子里就要过一遍它对数据行的处理结果。第三网络和浏览器兼容性问题。在线笔试最怕写了一大半答案突然断网或者浏览器崩溃。考前一天我专门测试了网络环境并且把系统推荐的Chrome浏览器更新到最新版本关掉了所有插件。建议参加这类笔试前用目标公司的模拟笔试链接提前走一遍流程确认摄像头权限、系统通知权限都已经正常放行。3. SQL实战题复盘连续登录、留存率与TopN的三种高频考法3.1 连续N天登录用户数一个把连续性转成分组的经典套路考题大致还原给定一张用户登录表表字段包括uid和login_date其中每个用户一天内可能有多条登录记录。要求统计连续登录3天及以上的用户数量。这个题在2019年的数据岗笔试里出现频率极高可以说是SQL综合能力的试金石。它的难点在于关系型SQL天然不擅长处理连续这种基于行间关系的判断你需要想办法把连续问题转化成离散的分组问题。我当时写的是窗口函数解法SELECT COUNT(DISTINCT uid) AS user_cnt FROM ( SELECT uid, login_date, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER(PARTITION BY uid ORDER BY login_date) DAY) AS grp_date FROM ( SELECT uid, DATE(login_date) AS login_date FROM user_login_log GROUP BY uid, DATE(login_date) ) t1 ) t2 GROUP BY uid, grp_date HAVING COUNT(*) 3;这个解法的核心原理是连续登录的日期序列在减去行号之后会得到同一个基准日期。比如某用户连续3天登录登录日期分别是9月1日、9月2日、9月3日对应的行号是1、2、3减去对应天数后得到8月31日、8月31日、8月31日——这三行被划入了同一个组。一旦分了组连续问题就变成了统计每个组内有多少条记录的问题。要是笔试环境不支持窗口函数也有替代写法。用自连接关联间隔2天的日期再配合EXISTS判断中间那天是否存在SELECT COUNT(DISTINCT a.uid) FROM user_login_log a JOIN user_login_log b ON a.uid b.uid AND b.login_date DATE_ADD(a.login_date, INTERVAL 2 DAY) WHERE EXISTS ( SELECT 1 FROM user_login_log c WHERE c.uid a.uid AND c.login_date DATE_ADD(a.login_date, INTERVAL 1 DAY) );这个写法求的是存在某一天t用户在第t天、第t1天、第t2天都登录过本质上覆盖了所有以t为起点的连续3天登录的情况。注意这类题最大的易错点不是SQL语法而是数据去重。用户一天内登录多次是常态如果不先按uid DATE(login_date)去重直接用原始表做窗口函数同一个用户同一天的多条记录会被当成多天登录导致连续天数虚增。我当时是先做了内层去重再跑外层逻辑这样结果才可靠。3.2 新用户留存率口径比语法更容易翻车第二道SQL题是留存计算。题目给了一张活跃表user_active字段是uid和active_date要求计算每天新增用户在未来第1天、第7天的留存率。留存率本身不算难但非常容易在口径上翻车。一个常见的错误是直接拿某天活跃的用户中前一天也活跃的用户数来当作次日留存这其实是活跃用户留存率而不是新增用户留存率。新增用户留存率的正确口径是先找出每个用户的首个活跃日期作为其新增日期再统计这些用户在新增后第N天仍然活跃的占比。我当时的写法是这样的WITH first_active AS ( SELECT uid, MIN(active_date) AS first_date FROM user_active GROUP BY uid ) SELECT first.first_date, COUNT(DISTINCT first.uid) AS new_user_cnt, COUNT(DISTINCT act.uid) AS day1_active, ROUND(COUNT(DISTINCT act.uid) / COUNT(DISTINCT first.uid), 4) AS day1_retain_rate FROM first_active first LEFT JOIN user_active act ON act.uid first.uid AND act.active_date DATE_ADD(first.first_date, INTERVAL 1 DAY) GROUP BY first.first_date;这里有几个关键细节第一必须用LEFT JOIN而不是INNER JOIN。如果新用户第2天没有活跃INNER JOIN会直接把这一行过滤掉导致分母变小留存率虚高。用LEFT JOIN能保留未活跃的用户保证分于是完整的新用户数。第二COUNT(DISTINCT)非常重要。活跃表里用户可能在同一天有多条行为记录如果直接COUNT(act.uid)同一天重复活跃的同一用户会被计多次。用COUNT(DISTINCT)能保证统计的是用户粒度的活跃数。第三留存率的定义要前置确认。实际业务中新增用户可能有不同口径账号注册算不算新增首次浏览算不算新增付费用户的新增怎么定义笔试虽然没有业务背景但答题时最好在注释里写清楚你采用的口径这会让阅卷人觉得你有严谨的数据意识。这种题在真实业务里会演变成更复杂的版本比如计算7日留存率的完整曲线用一张透视表呈现各渠道用户在第1天、第3天、第7天、第14天的留存率背后的SQL逻辑和上面是一致的只是把CASE WHEN拆得更细。3.3 TopN与行列转换窗口函数与条件聚合的组合使用第三道SQL大概率是TopN问题。题目大致是给定商品销售表sales字段包括category、product_id、sales_amount要求找出每个品类下销售额排名前3的商品。这个题在2019年有多种解法但最清晰、最不容易出错的是窗口函数SELECT category, product_id, sales_amount FROM ( SELECT category, product_id, sales_amount, ROW_NUMBER() OVER(PARTITION BY category ORDER BY sales_amount DESC) AS rn FROM sales ) t WHERE rn 3;注意如果销售额相同的商品希望都进入榜单应该用DENSE_RANK()而不是ROW_NUMBER()。比如销售额第3名有两个并列商品ROW_NUMBER()只会选其中一个DENSE_RANK()会把两个都保留。这个细节在笔试里很容易被忽略但它正好体现了对业务含义的理解——实际业务中并列排名通常应该显示为并列。另一个常见考点是行列转换。题目会给一张长表字段是month、channel、amount要转换成每个渠道占一列的宽表。解法就是条件聚合SELECT month, SUM(CASE WHEN channel A渠道 THEN amount ELSE 0 END) AS channel_a_amount, SUM(CASE WHEN channel B渠道 THEN amount ELSE 0 END) AS channel_b_amount, SUM(CASE WHEN channel C渠道 THEN amount ELSE 0 END) AS channel_c_amount FROM sale_month_channel GROUP BY month;这类题考的是两类窗口函数的能力用PARTITION BY做分组排序用CASE WHEN配合聚合函数做条件展开。两个技能组合起来基本就能应对数据岗SQL笔试里的大部分难题。3.4 手写SQL时怎么在没有数据库环境的情况下尽可能保证正确在线笔试系统里写SQL最大的痛点是没法跑测试用例所以你必须练就一套人肉调试的方法。我的习惯是写完之后在脑内构造一个3-5行的小样本表一行一行代入SQL逻辑手动推演每一步的结果。重点关注JOIN之后是否产生笛卡尔积或重复行。检查GROUP BY的粒度是否正确。比如按用户分组后SELECT里能不能出现login_date这种非聚合字段在严格模式下会报错笔试系统不一定会提示但阅卷人会看到。日期函数注意时区问题。DATE()函数和DATE_ADD()函数的参数类型不匹配时容易得到NULL导致结果直接不对劲。4. 统计概率与业务分析题从算得对到讲得清4.1 一道贝叶斯条件概率题考的是直觉和公式哪个先出场笔试第三单元有一个让我印象很深的概率题大意是某内容平台的内容池中约5%的内容会被标记为低质内容。平台训练了一个审核模型模型对真正低质内容能够准确标记出来的概率是90%同时有10%的概率将正常内容误判为低质。现在有一条内容被模型判定为低质问它真正是低质的概率是多少这是一道标准的贝叶斯条件概率题。设事件A为内容真正低质事件B为模型判定为低质。题目给出P(A) 0.05先验概率P(B|A) 0.90敏感度真正低质被判出来的概率P(B|非A) 0.10误报率正常内容被判为低质的概率要求的是P(A|B)即模型判低质时内容真的低质的概率P(A|B) P(B|A) × P(A) / [P(B|A) × P(A) P(B|非A) × P(非A)]代入数字P(A|B) 0.90 × 0.05 / (0.90 × 0.05 0.10 × 0.95) 0.045 / (0.045 0.095) ≈ 32.1%也就是说即使模型看起来准确率很高一条被判定为低质的内容真正是低质的概率也只有大约三分之一。这个结果非常反直觉但它恰恰是数据分析师在实际工作中经常遇到的场景。模型的输出结果不等于真实标签先验概率对后验概率的影响比大多数人想象中更大。类似的案例在推荐系统评估、风控模型、医学检测中都大量存在。笔试里考这道题目的不是看你能否算出32.1%而是看你能不能理解为什么准确率90%的模型其预测结果的可信度却远远不到90%。答题时除了写出计算过程我还额外解释了一句在实际内容质量治理中如果想要提升判低质后的准确率一方面要提高模型对低质内容的敏感度另一方面可以通过扩大低质内容的先验比例比如优先审核可疑内容来提升判后概率。这种延伸说明能体现数据分析的思维深度。4.2 假设检验题算Z统计量只是开始解读才是分水岭接下来是一道假设检验题和AB实验高度相关。题目大意是某推荐策略改版后对照组用户的点击率为2.0%实验组用户的点击率为2.2%两组样本量各为10万。问这个提升在统计上是否显著。这道题的数据很典型直接套正态近似法算Z统计量就行。设p1 0.022p2 0.020合并比例p (n1×p1 n2×p2) / (n1 n2) (2200 2000) / 200000 0.021。标准误SE sqrt(p(1-p) × (1/n1 1/n2)) sqrt(0.021 × 0.979 × 0.00002) ≈ 0.00064Z (0.022 - 0.020) / 0.00064 ≈ 3.12对应的p值小于0.01在0.05显著性水平下拒绝原假设认为实验组点击率显著高于对照组。但这里最值得说的不是Z统计量怎么算而是对结果的解读。统计显著不等于业务显著0.2个百分点的点击率提升可能统计学上很稳定但业务上是否值得全量上线还要看这个提升是否被其他指标稀释。比如点击率是涨了但人均停留时长降了或者误点击率上升了那就得综合评估。笔试的案例分析部分经常这类题一起出给你一个AB实验的结果表格点击率、转化率、客单价、退货率几个指标放在一起让你判断应该不应该全量上线。这里的答法是分层的先看核心指标的显著性判断策略是否有效果。再看反面指标有没有变差防止顾此失彼。看样本量和实验时长是否足够防止辛普森悖论或者实验周期不完整。最后结合业务背景做判断比如大促期间策略效果可能被稀释。4.3 案例论述题DAU下滑10%你怎么排查案例分析题是整场笔试里最开放、也最考验结构化表达能力的题目。当时的题目大意是某内容社区产品最近一周DAU环比下降了10%作为数据分析师你的排查思路是什么这种题没有标准答案但存在明显的踩分点。我当时的回答分成四个层次第一层先确认数据本身的可靠性。是统计口径变了还是埋点出了问题有没有节假日或特殊事件影响如果数据本身不可靠后面所有分析都是空中楼阁。第二层拆解指标。DAU 新增用户 老用户回流 - 老用户流失。先确定下降主要来自哪个部分。如果新增没有明显变化那问题大概率出在老用户活跃上如果新增变少就要看渠道投放和外部竞争。第三层进一步拆分维度。老用户活跃度下降要按渠道、版本、地域、用户注册时长拆分看下降是普适性的还是集中在一部分人群里。这个时候往往会用到维度下钻的方法——先整体再按多个维度交叉拆解。第四层关联业务和内容。小红书这类内容社区产品的DAU下降尤其要关注内容供给侧的波动。如果近一周笔记发布量明显下降或者推荐供给不够用户刷不出新内容活跃自然下滑。这种判断需要结合内容生产数据和推荐系统日志来做交叉验证。这类题真正想考察的其实是你面对模糊问题时展现出的分析思路。如果你一上来就急着给结论反而会显得不专业从数据口径校验到维度拆解再到业务逻辑回归用层层递进的方式展示思路阅卷人才会觉得你具备独立扛起一个分析项目的能力。5. 考后复盘数据岗笔试的知识点优先级与避坑清单5.1 从这场笔试反推出来的高频知识点排序考完之后我把整张卷子回顾了一遍惊讶地发现真正拉开差距的并不是偏题怪题而是几个基础模块的熟练度。后来我又陆续参加了其他公司的数据分析笔试发现考点结构高度相似。按我的个人经验给准备数据岗笔试的同学一个优先级参考优先级知识点考察方式投入产出比最高SQL窗口函数、多表关联、分组聚合手写SQL题极高短期可提升高条件概率/贝叶斯、假设检验、二项分布选择题计算题高理解概念后见效快高业务分析框架留存、漏斗、指标拆解案例分析题较高需要积累中行测逻辑选择题中等训练后稳定中低机器学习基础概念偶尔出现看岗位要求不建议重点投入数据岗笔试和算法岗笔试最大的不同就是SQL和业务意识的权重远大于模型推导。总有人担心是不是要精通各种机器学习算法才能过笔试实际上大多数数据分析日常工作是和SQL、指标、AB实验打交道机器学习更多是锦上添花。5.2 我在笔试中踩过的坑希望你避开写SQL前没有先想清楚表的结构导致中途改了两次JOIN条件。在线笔试系统里改代码的成本比本地IDE高很多因为没有语法高亮和自动补全思路不连贯时特别容易漏字段。后来我养成的习惯是先在草稿纸上画出表结构和关联键再动笔写SELECT。行测部分在一道图形推理上花了太长时间导致后面资料分析题时间不够。一道题卡住超过90秒就应该立刻放弃行测的得分策略本来就是用时间换分数而非每道题都做对。案例分析题只写了分析思路没有对可能的结果做延伸讨论。后来和其他拿到后续面试的同学交流发现笔试阅卷人更看重的是能不能从分析推到行动。也就是说你不仅要回答DAU为什么下降还要回答如果发现是某个渠道新增质量变差下一步应该怎么办。概率题审题太快差点把误报率当成模型准确率的反向操作。条件概率题目一定要把事件定义清楚先设事件A、B再把已知条件逐一对应到符号最后套公式。这个过程看起来慢其实是避免计算错误的最快方式。5.3 关于第一批笔试的备注如果你投递的岗位也标注了类似第一批笔试的字样有一点值得注意第一批通常意味着较早的投递批次题目的风格可能和后续批次略有差异但它不代表试水或者简单。从我了解到的情况看不同批次的试题难度基本一致只是题目内容会有变化。早投递的优势在于后续批次有概率出现第一批的变体题比如把连续登录天数从3天改成5天把留存从次日改成3日。所以如果你赶上了第一批不要抱着反正后面还有批次的心态随便应付反过来如果投得晚也可以去牛客网和论坛翻翻前辈们对第一批的回忆帖把常见题型提前过一遍。6. 给正在准备数据岗笔试的人三个比刷题更重要的习惯说完了当年那场笔试的具体内容最后再聊几句我自己在后来多次笔试面试中验证过的体会。第一个习惯是养成先想清楚再动手的答题节奏。笔试的时间压力会让人下意识地急着写答案但数据岗笔试的所有题目都有一个共同点想清楚方向比写得多重要。SQL题先想关联键和聚合粒度概率题先设事件和符号案例分析先搭分析框架。这个思维模式在入职之后做真实业务分析时同样适用。第二个习惯是把每一道题都当成一次业务沟通来对待。笔试里那道贝叶斯题如果你只是算出一个32.1%就结束和算出结果之后补充一句这意味着模型判低质后直接惩罚内容是有风险的需要结合其他信息做综合判断在阅卷人眼里的评价完全不同。数据分析师的价值不在于会算数而在于能把数字背后的业务含义讲清楚并推动正确的决策。第三个习惯是建立自己的错题本。我备考期间专门建了一个文档把所有写错的SQL、理解偏差的概率题、漏掉的业务分析维度都记下来并写下当时出错的原因。这个错题本在我后续参加的所有笔试里都发挥了实质作用因为数据岗笔试的高频考点就那么几个你犯过的错大概率会以变形的方式再次出现。把这些坑提前填平考试时自然会从容很多。如果你也准备投数据分析岗位希望这篇笔试复盘能帮你对这场考试到底考什么、该怎么准备有一个更清晰的判断。数据岗笔试的门槛不高但区分度不小真正的分水岭往往不在你背了多少公式和函数而在于你能不能像数据分析师一样思考问题——从数据出发用逻辑说话让结论落地。