1. 笔试现场的第一感受题量比想象中大时间比想象中紧说实话拿到58同城2023校招数分笔试页面的时候我第一反应是就四道大题但点进去做了十分钟才发现根本不是题少是每道题都要写一大段。整场笔试下来我更愿意把它形容成一次浓缩的数据分析项目答辩——不是靠蒙选项能混过去的每一道题都在逼你把分析思路完整地写下来。先说下整场笔试的基本构成方便后面备考的同学有个整体概念。四个模块分别是SQL题、统计学基础、业务案例分析、数据思维杂题。官方给的总时长是90分钟实际做下来绝大多数人会在最后一个模块明显感觉时间吃紧。我做题的顺序是先SQL、再统计、然后业务案例、最后数据思维这个顺序其实是有讲究的后面细说。值得注意的一点是笔试系统支持切换到下一题再回看上一题修改但题目一旦提交进入下一题就不能再改了。所以千万别赶时间每道题提交前都要把答案从头读一遍。特别是SQL题少了一个去重条件、多写了一个关联字段分数差距很大。这场笔试适合谁参考如果你正在准备互联网公司数据分析岗的校招笔试或者刚入行想了解大厂数分考察什么这篇文章应该能帮到你。我会把每类题的出题逻辑、高频考点、以及我在做题过程中的思考和踩坑经验都拆开讲。2. SQL题不是能写出来就行而是要写得对、写得稳2.1 给分点藏在细节里去重、NULL、关联关系SQL题大概是五道左右全部是手写查询。主题都是58同城这种信息分类平台很典型的场景——用户表、帖子表、类目表、浏览记录表之间的关联分析。表面上考的是select、join、group by这些基础语法但给分点其实都在细节里。比方说有一道题要求统计每个一级类目下发帖数大于等于5条的用户数量。我当时的第一版写法是直接join用户表和帖子表然后group by类目count用户。但提交前多看了一眼题目里的发帖数大于等于5条的用户数量意味着必须先算出每个用户的发帖数筛选出达标的人再按类目计数。如果直接对帖子和用户join之后count(user_id)会把同一个用户在多个类目下的帖子重复计算。这种题型的常见给分点我整理了一下考察点常见错误正确理解用户去重count(user_id) 导致重复先取 distinct user_id 再统计NULL处理left join 后未排除空值明确业务中NULL代表未发生还是未知关联条件漏掉平台/城市维度多条件关联要写全时间范围只看date忽略time根据业务判断是否需要精确到时分秒指标口径用户数、帖子数混淆读题时圈出指标名词2.2 一道窗口函数题连续发帖天数的计算思路这道题我记得很清楚因为它用到了窗口函数而且也是整场SQL模块中我认为最有区分度的一道题。题目大概是给定帖子表post_id、user_id、post_date求每个用户连续发帖的最大天数。如果是按月统计发帖量普通的group by就够用了。但连续天数意味着需要判断日期间隔是否连续这就必须用窗口函数来算。我的解法是用row_number()给每个用户的发帖日期按时间排序然后用发帖日期减去排序的序号得到一个分组标志日。同一个用户下日期减去序号相等的行就是连续发帖的同一组。得到这个分组标志后再按用户和分组标志聚合count天数最后取最大值。WITH post_rank AS ( SELECT user_id, post_date, -- 按用户分组、日期排序后编号 row_number() OVER (PARTITION BY user_id ORDER BY post_date) AS rn FROM post_info WHERE post_date 2023-01-01 AND post_date 2023-04-01 ), post_group AS ( SELECT user_id, post_date, -- 日期减去行号连续日期会得到同一个日期 date_sub(post_date, INTERVAL rn DAY) AS group_flag FROM post_rank ) SELECT user_id, max(cont_days) AS max_cont_days FROM ( SELECT user_id, count(1) AS cont_days FROM post_group GROUP BY user_id, group_flag ) t GROUP BY user_id;这道题的关键在于理解date_sub(post_date, INTERVAL rn DAY)这一行的含义。我可以用一个生活化的例子解释一下把日期想象成排队的人如果这些人是连续站着的比如1号、2号、3号那么日期 - 序号这个值是相等的如果中间隔了一天比如1号、2号、4号那最后一个人计算出来的值就会和前面的人不一样。这样就能自然地把连续的行切成不同的组。这里也有两个容易踩的坑。第一post_date如果是 datetime 类型一定要先转成 date 再计算否则连同一天的凌晨和晚上都会被视为不同的行。第二如果同一天发多次帖子直接row_number()会导致连续天数被错误地拉长正确的做法是先对user_id, post_date去重再编号。2.3 SQL模块的时间安排建议我自己的做题节奏是每道SQL题控制在8分钟以内写完先不急着提交花1分钟检查三件事join的字段有没有遗漏、group by的字段和select是否一致、count的指标是否和题目要求完全对应。SQL题占整场笔试的比重不低而且它是最容易拿分的一部分因为答案是确定的不像业务题那么主观。但前提是平时要练到手熟特别是窗口函数和日期处理函数这两类在数分笔试中出现频率非常高。考前建议把所有常见的窗口函数场景都过一遍排名、移动平均、分组内TopN、相邻行差值、连续性问题。3. 统计学板块假设检验那套框架比背公式重要得多3.1 一道AB实验分析题实验组转化率提升0.2个点算显著吗统计学的题量不大但每题都是综合性的重点考察假设检验、置信区间、样本量和实验设计。我还记得一道题背景是平台首页改版实验组和对照组各分配了10000个用户实验组首页改版后的点击转化率是5.2%对照组是5.0%。问题有三个这个差异是否统计显著如果显著是否意味着改版一定有效如果要结论更可靠还需要补充什么信息第一问看似简单套一下两比例z检验公式就能算出来。但真正考察的其实是第二问和第三问。第二问里即使p值小于0.05只能说明观察到的差异不太可能由随机波动引起但0.2个百分点的提升是否值得上线要看业务成本——比如改版后的页面是否影响其他指标人均浏览帖子数、发帖转化率、广告点击率以及长期看是否会有用户疲劳效应。统计显著不等于业务显著这是面试官反复强调的点。第三问我当时写的是要补充样本的性别、城市分布是否在两组中均衡以及实验是否做了AA测试来确定基线的稳定性。如果在实验之前没有做过AA测试可能实验组和对照组本身就存在系统性偏差比如新用户占比不一致。3.2 样本量计算想算出显著性先问自己样本够不够另一道题考样本量计算题目给了baseline转化率和最小可检测提升要求估算实验所需样本量。这道题考察的公式比较简单n (Z_α/2 Z_β)^2 * (p1 * (1-p1) p2 * (1-p2)) / (p2 - p1)^2但我更想强调的其实是思考过程题目并不是真的想让你手动算出精确数字而是看你是否有能力判断这个实验设计是否可行。如果baseline转化率只有1%想检验0.1%的提升需要的样本量会非常巨大。现实中往往没有那么多流量来支撑这样的实验这时合理的做法是要么降低精度要求要么改成分层实验要么延长实验周期要么选择更敏感的指标比如用户平均发帖量而不是发帖率。笔试中比较稳的思路是先写出公式和参数含义再代入数字估算最后给出基于这个样本量实验周期大概是X天的结论。能走到第三步的人不多但一旦写出来分数会明显不一样。3.3 p值常见的理解误区统计学的最后一个问题还专门考了p值的解释内容大概是p值小于0.05意味着原假设为真的概率小于5%这种说法是否正确这种题就是典型的我知道你哪里会错的坑题。p值的准确定义是在原假设为真的情况下观察到当前样本或更极端样本的概率。它并不是原假设为真的概率后者属于贝叶斯框架下的后验概率需要引入先验分布才能计算。我在笔试时特意用了很严谨的措辞来回答这个问题因为这种地方出错面试官会直接怀疑你的统计学基础。4. 业务案例分析信息分类平台的指标异动分析4.1 业务题到底在考什么58同城这类信息分类平台核心业务逻辑是连接发帖用户B端或C端和浏览用户C端平台的收入主要来自商家推广和会员增值服务。所以业务题基本围绕三个方向展开其一是平台核心业务指标的异动分析发帖量掉了、浏览时长降了其二是新策略或新功能的效果评估比如改了信息审核策略、上线了新的推荐排序其三是运营活动的ROI测算比如针对新用户做了补贴活动成本是否可控。笔试样例中占比最高的是第一类因为异动分析最能体现一个数分候选人的业务sense和分析框架。这类题没有标准答案但考察的分析路径是有高下之分的。我记得那天的题目大概是这样某城市站的帖子日均发布量连续两周下降了8%请你分析可能的原因并给出你的分析思路。如果只是简单地写可能是竞对抢了用户可能是发帖入口出bug了这种单点猜测分数会很一般。比较稳妥的框架是把问题拆成先定位、再归因、后验证三步。4.2 我的拆解思路从指标体系入手而不是一上来就找原因我的回答分了三步。第一步先确认下跌是真是假以及下跌主要集中在哪一层维度。我写的具体操作是把帖子发布量按城市、类目招聘、房产、二手车、二手物品、本地服务等、用户类型新用户、老用户、付费用户、免费用户拆分对比两周前和两周后的变化幅度确认下跌是全面性的还是结构性的。如果只是某个类目下跌那就去看这个类目近期有没有特殊事件比如招聘淡旺季、房产政策调整、类目运营策略变化。第二步确定是供给侧的问题还是审核侧的问题。因为这里的帖子发布量是审核通过后的发帖量并不知道发布提交量是否变化。需要看两个口径用户提交的发帖请求量有没有下降以及审核通过率有没有下降。如果提交量正常但通过率下降问题大概率出在审核策略如果提交量本身就下降那就是用户发文意愿或入口的问题。第三步再看新老用户结构。我特意写了一个比较细的判断逻辑如果把用户拆成新用户和老用户发现新用户发帖量没变老用户发帖量下降明显那可能不是功能问题而是用户激励问题反过来如果是新用户发帖量下降那就回到渠道和注册转化路径上去排查。这种答法好在什么地方它把为什么下降拆成了几个可验证的假设而且每个假设都能用数据去证实或证伪。面试官看重的不是你能猜中真实原因而是你有没有一套从现象到根因的排查方法论。4.3 答题结构建议结论先行假设其次数据验证最后业务题一般要求写一段分析思路有些还会让你补充需要哪些数据表、用什么指标来验证。我的经验是先写分析方向对该问题的理解再列出可能的假设哪怕只是候选也要说明假设之间的优先级关系最后写验证手段需要什么数据、用什么指标、怎么判断我有一个小技巧把假设按验证成本从低到高排序。比如先看后台数据能不能直接查到提交量、通过率再考虑做用户调研、看客服反馈这样既显得你考虑周全又符合实际工作的推进逻辑。5. 数据思维与杂题估算题考的不是答案是拆解方式5.1 一道估算题城市里一年成交多少辆二手车58同城的业务天然和数据估算题贴合我记得有一道题是估算你所在城市一年内二手车的成交量。很多人的第一反应是随便报一个数然后解释这个数是怎么来的。但这类题真正的评分点在于你的拆解逻辑是否清晰、假设是否合理、中间计算是否可复现。我的拆解方式是先看供给端再看需求端最后取两者约束后的值。从需求端看先估算城市常住人口再估算其中有购车意愿和购车能力的家庭数量。比如一个千万级人口的城市假设三口之家是300万个家庭其中30%的家庭有明确的购车需求就是90万个家庭。新车和二手车的比例为大约7比3也就是说二手车需求大概在20万到30万辆一年。从供给端看估一下每年的汽车保有量和换车周期。假设城市汽车保有量300万辆平均换车周期6年每年进入二手市场的车大概是50万辆但其中一部分会流向外地本地成交量按六成算大概30万辆。两端估算量接近就取一个中间数再说明误差来源。这类题的关键不是估得准而是每一个假设都有依据每一步计算都能给别人讲明白。我在笔试时明确写了我下面的假设基于公开估算和常识推断实际值会有偏差但分析框架是通用的然后把每一步的假设都列清楚。这样做的好处是让面试官觉得你具备把模糊问题变成结构化问题的能力。5.2 异常值判断题用数据发现刷帖行为另一道杂题是给了一张帖子浏览量和用户行为的明细表要求判断是否存在刷帖刷量行为并写出判断逻辑。我当时把异常特征归纳成几类单用户发帖频次远高于正常人、发帖时间集中在深夜或整点、同一IP段下大量账号注册、帖子内容重复度高、浏览量与收藏量比值异常。针对每一类都对应了一个查询逻辑比如用窗口函数统计每个用户按小时级发帖数如果某用户连续多天在凌晨2点到4点批量发帖就有很大嫌疑。这类题目考察的是数据敏感度。如果你平时在做数据监控时有积累异常判断的经验会比较容易回答。没有经验的同学建议先记住一个原则判断异常要同时看绝对指标和相对指标。单看发帖数超过100条可能不算离谱但如果这个用户同时是新注册账号、内容模板化、IP和多个账号重合那叠加起来的置信度就非常高了。5.3 卡壳时的应对策略写思考路径比写结论更能拿分杂题中的逻辑题偶尔会让人卡住我的建议是哪怕没有完整答案也要把已经想到的推理步骤写上去。笔试的评判维度里分析过程是否清晰本身就是一项独立打分点。一旦卡壳也要避免直接放弃把已知条件、尝试过的路径、中间结论先写出来再往下推导。6. 考完之后才发现这份试卷暗合了数分岗位的工作日常6.1 笔试题目与工作内容的对应关系做完这套题最大的感受是它不是在考你会不会写SQL懂不懂假设检验而是在模拟一个数分新人入职后的日常工作。SQL题对应的是每天要面对的取数需求而且不是简单取数通常是带着业务判断的复杂取数。统计题对应的是产品和运营的同学抛过来的实验分析需求。业务案例题对应的是业务方突然过来说指标掉了你帮看看的应急分析。数据思维题对应的是在没有现成数据的情况下如何用已知信息快速估算。想明白这一层之后备考的时候就不需要漫无目的地刷题了。我建议复习的顺序是SQL熟练度优先笔试中确定性最高、最容易练出来的部分统计理论其次以假设检验和置信区间为核心重点理解每个概念的业务含义业务分析框架最后通过看真实案例总结很难短期突击。如果时间有限SQL的优先级一定是最高的。6.2 备考资料和练习方向建议官方没有完整放出真题所以复习更多要靠通用型资料加自己模拟。SQL部分推荐去力扣刷数据库板块的中等难度题特别是窗口函数、连续性问题、TopN问题。刷够30道左右基本能覆盖笔试中80%的SQL题型。统计部分网上的公开课和入门教材都够用关键是把假设检验、p值、置信区间、样本量计算、AB实验流程这几个点吃透。业务部分多看互联网公司的数据案例分析或者自己找一些分析报告拆解。重点不是背诵框架而是学会怎么把问题拆成假设再转化成指标。6.3 一个容易被忽略的建议提前适应写长答案的节奏我给后来人最大的建议是数分笔试和理工科的考试不一样每道题的答案不是算出结果就够了而是要把思考过程完整地写出来。如果你想提前适应这种答题方式可以试着给自己出几道题然后强迫自己写出500字以上的完整分析包括假设、公式、计算过程、结论、可能存在的局限性。这个练习很有用因为笔试时会写的和会想的往往是两回事很多人在考场上才发现自己脑子里有思路但写不出来。我最后还想分享一个实用的小经验。笔试系统右侧通常有一个草稿区域我习惯把分析思路先写在草稿区搭好框架再往答题区誊写。这样做有两个好处一是答题区的文字更整洁逻辑更清晰二是誊写的过程本身就是一次检查能发现不少笔误和逻辑漏洞。考试时间紧张的情况下这个习惯省了我很多修改时间建议你也可以试试。 58同城数分笔试复盘：SQL窗口函数与AB实验实战指南
1. 笔试现场的第一感受题量比想象中大时间比想象中紧说实话拿到58同城2023校招数分笔试页面的时候我第一反应是就四道大题但点进去做了十分钟才发现根本不是题少是每道题都要写一大段。整场笔试下来我更愿意把它形容成一次浓缩的数据分析项目答辩——不是靠蒙选项能混过去的每一道题都在逼你把分析思路完整地写下来。先说下整场笔试的基本构成方便后面备考的同学有个整体概念。四个模块分别是SQL题、统计学基础、业务案例分析、数据思维杂题。官方给的总时长是90分钟实际做下来绝大多数人会在最后一个模块明显感觉时间吃紧。我做题的顺序是先SQL、再统计、然后业务案例、最后数据思维这个顺序其实是有讲究的后面细说。值得注意的一点是笔试系统支持切换到下一题再回看上一题修改但题目一旦提交进入下一题就不能再改了。所以千万别赶时间每道题提交前都要把答案从头读一遍。特别是SQL题少了一个去重条件、多写了一个关联字段分数差距很大。这场笔试适合谁参考如果你正在准备互联网公司数据分析岗的校招笔试或者刚入行想了解大厂数分考察什么这篇文章应该能帮到你。我会把每类题的出题逻辑、高频考点、以及我在做题过程中的思考和踩坑经验都拆开讲。2. SQL题不是能写出来就行而是要写得对、写得稳2.1 给分点藏在细节里去重、NULL、关联关系SQL题大概是五道左右全部是手写查询。主题都是58同城这种信息分类平台很典型的场景——用户表、帖子表、类目表、浏览记录表之间的关联分析。表面上考的是select、join、group by这些基础语法但给分点其实都在细节里。比方说有一道题要求统计每个一级类目下发帖数大于等于5条的用户数量。我当时的第一版写法是直接join用户表和帖子表然后group by类目count用户。但提交前多看了一眼题目里的发帖数大于等于5条的用户数量意味着必须先算出每个用户的发帖数筛选出达标的人再按类目计数。如果直接对帖子和用户join之后count(user_id)会把同一个用户在多个类目下的帖子重复计算。这种题型的常见给分点我整理了一下考察点常见错误正确理解用户去重count(user_id) 导致重复先取 distinct user_id 再统计NULL处理left join 后未排除空值明确业务中NULL代表未发生还是未知关联条件漏掉平台/城市维度多条件关联要写全时间范围只看date忽略time根据业务判断是否需要精确到时分秒指标口径用户数、帖子数混淆读题时圈出指标名词2.2 一道窗口函数题连续发帖天数的计算思路这道题我记得很清楚因为它用到了窗口函数而且也是整场SQL模块中我认为最有区分度的一道题。题目大概是给定帖子表post_id、user_id、post_date求每个用户连续发帖的最大天数。如果是按月统计发帖量普通的group by就够用了。但连续天数意味着需要判断日期间隔是否连续这就必须用窗口函数来算。我的解法是用row_number()给每个用户的发帖日期按时间排序然后用发帖日期减去排序的序号得到一个分组标志日。同一个用户下日期减去序号相等的行就是连续发帖的同一组。得到这个分组标志后再按用户和分组标志聚合count天数最后取最大值。WITH post_rank AS ( SELECT user_id, post_date, -- 按用户分组、日期排序后编号 row_number() OVER (PARTITION BY user_id ORDER BY post_date) AS rn FROM post_info WHERE post_date 2023-01-01 AND post_date 2023-04-01 ), post_group AS ( SELECT user_id, post_date, -- 日期减去行号连续日期会得到同一个日期 date_sub(post_date, INTERVAL rn DAY) AS group_flag FROM post_rank ) SELECT user_id, max(cont_days) AS max_cont_days FROM ( SELECT user_id, count(1) AS cont_days FROM post_group GROUP BY user_id, group_flag ) t GROUP BY user_id;这道题的关键在于理解date_sub(post_date, INTERVAL rn DAY)这一行的含义。我可以用一个生活化的例子解释一下把日期想象成排队的人如果这些人是连续站着的比如1号、2号、3号那么日期 - 序号这个值是相等的如果中间隔了一天比如1号、2号、4号那最后一个人计算出来的值就会和前面的人不一样。这样就能自然地把连续的行切成不同的组。这里也有两个容易踩的坑。第一post_date如果是 datetime 类型一定要先转成 date 再计算否则连同一天的凌晨和晚上都会被视为不同的行。第二如果同一天发多次帖子直接row_number()会导致连续天数被错误地拉长正确的做法是先对user_id, post_date去重再编号。2.3 SQL模块的时间安排建议我自己的做题节奏是每道SQL题控制在8分钟以内写完先不急着提交花1分钟检查三件事join的字段有没有遗漏、group by的字段和select是否一致、count的指标是否和题目要求完全对应。SQL题占整场笔试的比重不低而且它是最容易拿分的一部分因为答案是确定的不像业务题那么主观。但前提是平时要练到手熟特别是窗口函数和日期处理函数这两类在数分笔试中出现频率非常高。考前建议把所有常见的窗口函数场景都过一遍排名、移动平均、分组内TopN、相邻行差值、连续性问题。3. 统计学板块假设检验那套框架比背公式重要得多3.1 一道AB实验分析题实验组转化率提升0.2个点算显著吗统计学的题量不大但每题都是综合性的重点考察假设检验、置信区间、样本量和实验设计。我还记得一道题背景是平台首页改版实验组和对照组各分配了10000个用户实验组首页改版后的点击转化率是5.2%对照组是5.0%。问题有三个这个差异是否统计显著如果显著是否意味着改版一定有效如果要结论更可靠还需要补充什么信息第一问看似简单套一下两比例z检验公式就能算出来。但真正考察的其实是第二问和第三问。第二问里即使p值小于0.05只能说明观察到的差异不太可能由随机波动引起但0.2个百分点的提升是否值得上线要看业务成本——比如改版后的页面是否影响其他指标人均浏览帖子数、发帖转化率、广告点击率以及长期看是否会有用户疲劳效应。统计显著不等于业务显著这是面试官反复强调的点。第三问我当时写的是要补充样本的性别、城市分布是否在两组中均衡以及实验是否做了AA测试来确定基线的稳定性。如果在实验之前没有做过AA测试可能实验组和对照组本身就存在系统性偏差比如新用户占比不一致。3.2 样本量计算想算出显著性先问自己样本够不够另一道题考样本量计算题目给了baseline转化率和最小可检测提升要求估算实验所需样本量。这道题考察的公式比较简单n (Z_α/2 Z_β)^2 * (p1 * (1-p1) p2 * (1-p2)) / (p2 - p1)^2但我更想强调的其实是思考过程题目并不是真的想让你手动算出精确数字而是看你是否有能力判断这个实验设计是否可行。如果baseline转化率只有1%想检验0.1%的提升需要的样本量会非常巨大。现实中往往没有那么多流量来支撑这样的实验这时合理的做法是要么降低精度要求要么改成分层实验要么延长实验周期要么选择更敏感的指标比如用户平均发帖量而不是发帖率。笔试中比较稳的思路是先写出公式和参数含义再代入数字估算最后给出基于这个样本量实验周期大概是X天的结论。能走到第三步的人不多但一旦写出来分数会明显不一样。3.3 p值常见的理解误区统计学的最后一个问题还专门考了p值的解释内容大概是p值小于0.05意味着原假设为真的概率小于5%这种说法是否正确这种题就是典型的我知道你哪里会错的坑题。p值的准确定义是在原假设为真的情况下观察到当前样本或更极端样本的概率。它并不是原假设为真的概率后者属于贝叶斯框架下的后验概率需要引入先验分布才能计算。我在笔试时特意用了很严谨的措辞来回答这个问题因为这种地方出错面试官会直接怀疑你的统计学基础。4. 业务案例分析信息分类平台的指标异动分析4.1 业务题到底在考什么58同城这类信息分类平台核心业务逻辑是连接发帖用户B端或C端和浏览用户C端平台的收入主要来自商家推广和会员增值服务。所以业务题基本围绕三个方向展开其一是平台核心业务指标的异动分析发帖量掉了、浏览时长降了其二是新策略或新功能的效果评估比如改了信息审核策略、上线了新的推荐排序其三是运营活动的ROI测算比如针对新用户做了补贴活动成本是否可控。笔试样例中占比最高的是第一类因为异动分析最能体现一个数分候选人的业务sense和分析框架。这类题没有标准答案但考察的分析路径是有高下之分的。我记得那天的题目大概是这样某城市站的帖子日均发布量连续两周下降了8%请你分析可能的原因并给出你的分析思路。如果只是简单地写可能是竞对抢了用户可能是发帖入口出bug了这种单点猜测分数会很一般。比较稳妥的框架是把问题拆成先定位、再归因、后验证三步。4.2 我的拆解思路从指标体系入手而不是一上来就找原因我的回答分了三步。第一步先确认下跌是真是假以及下跌主要集中在哪一层维度。我写的具体操作是把帖子发布量按城市、类目招聘、房产、二手车、二手物品、本地服务等、用户类型新用户、老用户、付费用户、免费用户拆分对比两周前和两周后的变化幅度确认下跌是全面性的还是结构性的。如果只是某个类目下跌那就去看这个类目近期有没有特殊事件比如招聘淡旺季、房产政策调整、类目运营策略变化。第二步确定是供给侧的问题还是审核侧的问题。因为这里的帖子发布量是审核通过后的发帖量并不知道发布提交量是否变化。需要看两个口径用户提交的发帖请求量有没有下降以及审核通过率有没有下降。如果提交量正常但通过率下降问题大概率出在审核策略如果提交量本身就下降那就是用户发文意愿或入口的问题。第三步再看新老用户结构。我特意写了一个比较细的判断逻辑如果把用户拆成新用户和老用户发现新用户发帖量没变老用户发帖量下降明显那可能不是功能问题而是用户激励问题反过来如果是新用户发帖量下降那就回到渠道和注册转化路径上去排查。这种答法好在什么地方它把为什么下降拆成了几个可验证的假设而且每个假设都能用数据去证实或证伪。面试官看重的不是你能猜中真实原因而是你有没有一套从现象到根因的排查方法论。4.3 答题结构建议结论先行假设其次数据验证最后业务题一般要求写一段分析思路有些还会让你补充需要哪些数据表、用什么指标来验证。我的经验是先写分析方向对该问题的理解再列出可能的假设哪怕只是候选也要说明假设之间的优先级关系最后写验证手段需要什么数据、用什么指标、怎么判断我有一个小技巧把假设按验证成本从低到高排序。比如先看后台数据能不能直接查到提交量、通过率再考虑做用户调研、看客服反馈这样既显得你考虑周全又符合实际工作的推进逻辑。5. 数据思维与杂题估算题考的不是答案是拆解方式5.1 一道估算题城市里一年成交多少辆二手车58同城的业务天然和数据估算题贴合我记得有一道题是估算你所在城市一年内二手车的成交量。很多人的第一反应是随便报一个数然后解释这个数是怎么来的。但这类题真正的评分点在于你的拆解逻辑是否清晰、假设是否合理、中间计算是否可复现。我的拆解方式是先看供给端再看需求端最后取两者约束后的值。从需求端看先估算城市常住人口再估算其中有购车意愿和购车能力的家庭数量。比如一个千万级人口的城市假设三口之家是300万个家庭其中30%的家庭有明确的购车需求就是90万个家庭。新车和二手车的比例为大约7比3也就是说二手车需求大概在20万到30万辆一年。从供给端看估一下每年的汽车保有量和换车周期。假设城市汽车保有量300万辆平均换车周期6年每年进入二手市场的车大概是50万辆但其中一部分会流向外地本地成交量按六成算大概30万辆。两端估算量接近就取一个中间数再说明误差来源。这类题的关键不是估得准而是每一个假设都有依据每一步计算都能给别人讲明白。我在笔试时明确写了我下面的假设基于公开估算和常识推断实际值会有偏差但分析框架是通用的然后把每一步的假设都列清楚。这样做的好处是让面试官觉得你具备把模糊问题变成结构化问题的能力。5.2 异常值判断题用数据发现刷帖行为另一道杂题是给了一张帖子浏览量和用户行为的明细表要求判断是否存在刷帖刷量行为并写出判断逻辑。我当时把异常特征归纳成几类单用户发帖频次远高于正常人、发帖时间集中在深夜或整点、同一IP段下大量账号注册、帖子内容重复度高、浏览量与收藏量比值异常。针对每一类都对应了一个查询逻辑比如用窗口函数统计每个用户按小时级发帖数如果某用户连续多天在凌晨2点到4点批量发帖就有很大嫌疑。这类题目考察的是数据敏感度。如果你平时在做数据监控时有积累异常判断的经验会比较容易回答。没有经验的同学建议先记住一个原则判断异常要同时看绝对指标和相对指标。单看发帖数超过100条可能不算离谱但如果这个用户同时是新注册账号、内容模板化、IP和多个账号重合那叠加起来的置信度就非常高了。5.3 卡壳时的应对策略写思考路径比写结论更能拿分杂题中的逻辑题偶尔会让人卡住我的建议是哪怕没有完整答案也要把已经想到的推理步骤写上去。笔试的评判维度里分析过程是否清晰本身就是一项独立打分点。一旦卡壳也要避免直接放弃把已知条件、尝试过的路径、中间结论先写出来再往下推导。6. 考完之后才发现这份试卷暗合了数分岗位的工作日常6.1 笔试题目与工作内容的对应关系做完这套题最大的感受是它不是在考你会不会写SQL懂不懂假设检验而是在模拟一个数分新人入职后的日常工作。SQL题对应的是每天要面对的取数需求而且不是简单取数通常是带着业务判断的复杂取数。统计题对应的是产品和运营的同学抛过来的实验分析需求。业务案例题对应的是业务方突然过来说指标掉了你帮看看的应急分析。数据思维题对应的是在没有现成数据的情况下如何用已知信息快速估算。想明白这一层之后备考的时候就不需要漫无目的地刷题了。我建议复习的顺序是SQL熟练度优先笔试中确定性最高、最容易练出来的部分统计理论其次以假设检验和置信区间为核心重点理解每个概念的业务含义业务分析框架最后通过看真实案例总结很难短期突击。如果时间有限SQL的优先级一定是最高的。6.2 备考资料和练习方向建议官方没有完整放出真题所以复习更多要靠通用型资料加自己模拟。SQL部分推荐去力扣刷数据库板块的中等难度题特别是窗口函数、连续性问题、TopN问题。刷够30道左右基本能覆盖笔试中80%的SQL题型。统计部分网上的公开课和入门教材都够用关键是把假设检验、p值、置信区间、样本量计算、AB实验流程这几个点吃透。业务部分多看互联网公司的数据案例分析或者自己找一些分析报告拆解。重点不是背诵框架而是学会怎么把问题拆成假设再转化成指标。6.3 一个容易被忽略的建议提前适应写长答案的节奏我给后来人最大的建议是数分笔试和理工科的考试不一样每道题的答案不是算出结果就够了而是要把思考过程完整地写出来。如果你想提前适应这种答题方式可以试着给自己出几道题然后强迫自己写出500字以上的完整分析包括假设、公式、计算过程、结论、可能存在的局限性。这个练习很有用因为笔试时会写的和会想的往往是两回事很多人在考场上才发现自己脑子里有思路但写不出来。我最后还想分享一个实用的小经验。笔试系统右侧通常有一个草稿区域我习惯把分析思路先写在草稿区搭好框架再往答题区誊写。这样做有两个好处一是答题区的文字更整洁逻辑更清晰二是誊写的过程本身就是一次检查能发现不少笔误和逻辑漏洞。考试时间紧张的情况下这个习惯省了我很多修改时间建议你也可以试试。