去年秋招我把饿了么的数据岗笔试当成了一次重点演练。原因很简单数据岗这几年太热了“投递-笔试-面试”这条链路里笔试是淘汰率最不客气的一环。收到笔试链接那天我其实没有太多意外但真正坐到镜头前才发现除了SQL和统计在线考试的环境、时间分配、答题结构每一项都可能在细节上给你上课。这篇文章不是官方攻略也不是题库合集而是我作为亲历者的一次完整复盘。我会把笔试里遇到的题型、准备过程、现场翻车点以及复盘后沉淀下来的方法都说清楚。如果你准备投的是偏业务的数据分析、数据运营岗这套思路可以直接拿去做参考如果偏数据开发或算法重点看SQL和解题思路的部分其他内容自行取舍。1. 开局先说清楚饿厂数据岗笔试到底考什么、筛什么人1.1 我收到的笔试通知长什么样不同部门、不同岗位的笔试入口和时间安排会有差别我这里说的是我实际经历的版本。当时通知里写的是“在线笔试”全程要求开摄像头总时长在100分钟左右。题目分成三个大块逻辑与图表推理、SQL与统计概率、业务案例分析。我拿到的题型分布大致是这样的模块题量建议用时核心考察点逻辑与图表推理10题15分钟快速读题、图表计算、逻辑推断SQL实操5题40分钟分组聚合、窗口函数、多表关联统计与概率8题25分钟条件概率、分布、假设检验、AB实验业务案例分析2题25分钟指标异动归因、业务方案设计这个时间不是我编的是我当时给自己切的预期节奏。真实考试里你不可能有时间在每一题上反复磨所以先知道“哪些地方不值得恋战”非常重要。例如图表推理题基本就是一分钟一题稍微卡住就应该先跳过SQL题反而值得多花一点时间因为它最能直接拉开差距。1.2 数据岗笔试到底想筛什么很多准备秋招的同学容易把数据岗笔试等同于“考SQL”。但经历过以后我的判断是笔试筛的不是你会不会写某条SQL而是你有没有一套成体系的、可迁移的数据处理思路。这里有三层第一层是基本功。SQL、概率统计、常用业务指标口径这些是最低门槛。如果连GROUP BY和SUM都写不顺基本没有后续。第二层是商业理解。数据岗不是纯开发你要面对的是“日活为什么跌了”“GMV为什么涨了”“补贴是不是真的拉来了新客”这类问题。笔试里的业务案例题就是想看你能否把一个模糊问题翻译成可执行的分析方案。第三层是表达习惯。案例题主观题没人要求你写论文但你的答案必须让判卷者几秒钟内看懂结论和依据。很多人题目会拆但写出来全是碎片最后得分一定不高。所以我在复盘时给自己的定位是数据岗笔试筛的不是“聪明人”而是“习惯好的人”。2. 笔试环境准备一套能让你少丢二十分的外设和工具2.1 别在浏览器和平台上赌人品在线笔试最大的隐藏风险不是题难而是系统不稳。我当时开考前留了十分钟专门做环境自检仍然遇到一次摄像头掉线好在重装驱动后恢复了。这里有几个建议用Chrome或系统推荐的浏览器提前关掉所有无关插件尤其是广告拦截和自动翻译插件它们经常和在线考试系统冲突。摄像头和麦克风权限要在考试链接里提前授权。不要等到开考后才去点“允许”那样会浪费正计时。网络尽量用有线而不是Wi-Fi。如果只能用Wi-Fi确认没有大流量下载在跑路由器旁边不要放无线降噪耳机充电亲测蓝牙设备偶尔会干扰。手机放到另一个房间或者至少调成免打扰。考试过程中如果手机亮屏弹消息很容易被误判也容易让自己分心。如果你收到的笔试通知里要求“提前10分钟进入系统”一定不要卡着最后一分钟再进。我见过有人因为身份核验失败折腾了十几分钟才进考场最后SQL题没写完。2.2 一只草稿本和一份速查表比多开屏幕更管用我知道很多人会想“多开一个显示器旁边放答案”。我劝你放弃这个念头在线笔试系统的切屏记录不是摆设一旦被判违规后面解释成本非常高。真正有用的是物理草稿纸和一支笔。概率题要列事件、画示意业务题要搭框架SQL题即使不写草稿也要先在纸上把表结构和关联关系捋清楚。屏幕有限草稿纸就是你的第二块脑区。另外我建议考前自己整理一份“速查表”。注意不是作弊用的答案小抄而是把常用函数、公式、答题模板用你自己的语言写一遍。比如SQLDATE_FORMAT、DATE_SUB、LEFT JOIN、ROW_NUMBER()、LAG()的常见写法。统计条件概率公式、AB实验样本量公式的变量含义、P值和置信水平的关系。业务日活异动归因的通用框架。这份速查表真正的作用不是让你场上翻而是你在手写过程中已经过了一遍知识点。考场上能想起来多少其实在考前一个星期就决定了。3. SQL题是白给还是白给取决于你会不会拆窗口函数3.1 看似送分的分组聚合题其实埋着三个坑先说一类最容易出现的题给一张订单表让你统计每个城市每个月的支付订单量和GMV。很多人看到这种题就松一口气但真正写对的人并不多。我用一张简化订单表来演示字段名是常见的业务口径不代表真实接口字段说明order_id订单IDuser_id用户IDcity_id城市IDorder_status订单状态pay_time支付时间pay_amount支付金额如果题目要求“只看支付成功的订单”最直接的回答是这样SELECT city_id, DATE_FORMAT(pay_time, %Y-%m) AS stat_month, COUNT(DISTINCT order_id) AS order_cnt, SUM(pay_amount) AS gmv FROM order_info WHERE order_status paid AND pay_time IS NOT NULL GROUP BY city_id, DATE_FORMAT(pay_time, %Y-%m) ORDER BY city_id, stat_month;看起来简单实际有三个坑。第一个坑是订单表里同一订单可能有多条记录。比如订单状态变更记录和订单基本信息放在同一张表里直接去COUNT(*)会把订单量算大。这时候用COUNT(DISTINCT order_id)更安全。第二个坑是pay_time存在空值。题目说“已支付”那就必须在条件里排除pay_time IS NULL否则SUM(pay_amount)可能把无支付记录的脏数据带上。第三个坑是月份字段的格式化口径。MySQL 用DATE_FORMAT(pay_time, %Y-%m)Hive 里可能要用substr(pay_time, 1, 7)如果是字符串字段还要先转成时间类型。笔试系统一般会限定SQL引擎但你的思路要兼容不同写法别因为函数名不熟白白扣分。3.2 窗口函数是数据岗的版本答案环比、TopN和留存比分组聚合更能拉开分数的是窗口函数。像“计算每个城市每个月GMV环比增长率”这种题几乎年年都会出现在数据岗笔试里。答案可以是下面这样WITH monthly AS ( SELECT city_id, DATE_FORMAT(pay_time, %Y-%m) AS stat_month, SUM(pay_amount) AS gmv FROM order_info WHERE order_status paid AND pay_time IS NOT NULL GROUP BY city_id, DATE_FORMAT(pay_time, %Y-%m) ) SELECT city_id, stat_month, gmv, LAG(gmv) OVER (PARTITION BY city_id ORDER BY stat_month) AS prev_gmv, ROUND( (gmv - LAG(gmv) OVER (PARTITION BY city_id ORDER BY stat_month)) * 100.0 / NULLIF(LAG(gmv) OVER (PARTITION BY city_id ORDER BY stat_month), 0), 2 ) AS mom_rate FROM monthly ORDER BY city_id, stat_month;这里有几个细节值得注意窗口函数里的PARTITION BY city_id表示按城市分别计算不会跨城市错位。ORDER BY stat_month是字符串格式的“年-月”可以直接按字典序排序不需要再转时间。NULLIF是为了防止除零报错。环比上个月没有数据时除数为空结果应该是NULL而不是让SQL直接报错。如果笔试环境不支持WITH思路也完全可以写成子查询。不管哪种写法窗口函数的计算逻辑一定要清楚。另外“TopN”也是高频考点。比如找出每个城市支付金额前3名的订单通常用ROW_NUMBER() OVER (PARTITION BY city_id ORDER BY pay_amount DESC)生成排名再在外面包一层过滤rank 3。宁可写复杂一点也别为了省代码漏掉分组逻辑。3.3 多表关联和空值处理决定你能不能“一遍过”业务里几乎没有单表现场。数据岗笔试里常见的就是“用户表、订单表、活动表、商品表”混在一起让你算活动转化率、复购率、沉默用户数。这类题的核心是先搞清楚关联关系用户和订单是一对多订单和商品也是一对多。多表关联后行数会被放大聚合前要想清楚到底按哪一层去重。统计“没有下单的用户”要用LEFT JOIN然后取IS NULL这是个非常基础但考场里容易写反的点。要区分“没有产生支付记录”和“产生了一条空支付记录”前者是IFNULL的手感问题后者是数据质量问题。我的经验是只要遇到多表关联先在草稿纸上画出表关系标清楚主键和外键再写SQL。别急着动手想清楚“每一行代表什么”再写能省掉一半调试时间。4. 统计、概率和AB实验很多人挂在第二个小问4.1 概率题与其硬算不如先把条件列完整数据岗笔试里的概率题难度通常不会超过高中数学但考场上的紧张感会放大失误。最常见的是条件概率题也就是经典的贝叶斯场景。我举个例子题目大概意思是某平台新用户的次日留存率是30%老用户次日留存率是60%新老用户占比分别是20%和80%。现在随机抽到一个次日有回访行为的用户问这个用户是新用户的概率是多少。这类题不能凭感觉答要先把事件写出来事件A用户是新用户P(A) 0.2事件B用户是老用户P(B) 0.8事件R用户次日有回访行为P(R|A) 0.3P(R|B) 0.6然后用贝叶斯公式P(A|R) P(A) × P(R|A) / [P(A) × P(R|A) P(B) × P(R|B)]代入就是 0.2 × 0.3 / (0.2 × 0.3 0.8 × 0.6) 0.06 / 0.54 ≈ 11.1%。很多人错在忘了分母是所有“有回访行为”的情况而不仅仅是新用户。其实只要在草稿上把事件写全这题根本不难。4.2 AB实验的样本量和显著性别只背结论数据岗笔试里AB实验属于必须会的知识点。题目不一定会让你手算大公式但你至少要理解样本量、显著性水平、统计功效这几件事的关系。我记得有一道题是给两组转化率问每组需要多少样本才能达到统计显著。这道题的关键不是背公式而是知道答案由几个变量决定基线转化率、最小可检测提升、显著性水平、统计功效。简化版的样本量公式是这样的n (p1(1-p1) p2(1-p2)) × (Z(1-α/2) Z(1-β))² / (p1 - p2)²其中 p1 是对照组预期转化率p2 是实验组预期转化率α 取0.05时 Z 约1.96β 取0.2时 Z 约0.84。假设对照组转化率5%实验组希望提升到6%那么差值就是0.01算下来每组大约需要八千多人两组加起来一万六左右。这个数字比我第一次凭感觉估的要大很多。所以我后来特别留意不要一看到“显著提升”就觉得是策略有效先看样本量够不够、实验周期有没有跨周末、两组样本是否完全随机。笔试里这类题不是纯计算而是在考你有没有实验思维。4.3 数据岗笔试里的统计题其实在考答题习惯统计知识本身不难难的是在有限时间内规范表达。我给自己定的答题顺序是第一步列出已知条件和要算的目标。第二步写清楚使用的公式或检验方法。第三步代入数据计算。第四步给一句业务结论。哪怕题目只要求填最终答案我也会在草稿上按这个流程走一遍。这么做不是为了给判卷者看而是为了降低低级错误。很多分数丢在“条件看错”“小数点错位”“显著性水平看错位”上不是知识盲区。另外有几类统计概念很容易被单独拎出来考正态分布与3σ、置信区间与P值、第一类错误和第二类错误、多重比较问题。这些点建议考前花半天统一复习性价比很高。5. 业务案例题的正确打开方式先定口径再搭框架最后给结论5.1 一个典型到不能再典型的题目“日活跃用户数下降了5%”业务案例题是最能区分“会做题”和“会做业务”的模块。我遇到的核心题目背景很简单某平台日活跃用户数相比上周同一时间下降了5%问你怎么分析和定位原因。很多人第一反应是“是不是竞品抢用户了是不是有bug是不是天气不好”这些不是错误答案但它们是零散假设没有一个分析框架。我在现场采用的结构是这样的先说结论初步判断是近期新用户激活环节出了问题而不是老用户大规模流失需要按渠道和版本进一步验证。 然后给验证顺序 1. 先定义日活口径是启动用户、登录用户还是产生核心行为的用户。 2. 把日活拆成新用户和老用户看谁在跌。 3. 老用户按端、城市、版本、渠道交叉切分找异常子群。 4. 新用户看激活渠道量级、次留曲线、投放节奏和渠道质量。 5. 看内部是否有改版、活动下线、服务异常。 6. 再看外部节假日、竞品动作、公共事件。这套顺序的好处是先排除最可能的问题再用数据逐层验证。哪怕最后发现主导原因不是新用户这个框架也能证明你“知道怎么查”。5.2 用指标拆解法把你的答案落地业务案例题不能只给框架必须落到具体指标。日活下降5%并不是一个可直接行动的目标我通常会把它拆成“流量-转化-交易”的漏斗再配合业务特点做调整。对于饿了么这类本地生活业务数据岗答题时至少要考虑三方角色用户、商家、骑手。只看用户指标是不够的商家供给减少、配送时效变差最终都会反映到用户活跃和复购上。层级核心指标可能异动方向流量DAU、人均浏览、启动次数启动次数下降可能是 Push 或生活号流量缩了转化门店点击率、下单转化率、支付成功率转化率下降可能是首页改版或优惠券门槛变化交易订单量、客单价、GMV客单价上升但订单量下降可能是补贴减少履约配送时长、超时率、投诉率履约变差会同时影响复购和口碑留存次日留存、7日留存、次月复购留存下降说明产品体验或供给出了问题我在答题时不会把所有这些指标都铺开而是先选“最能解释5%下跌”的两三个然后围绕它们给出假设和数据需求。比如我会说“我需要近7天新老用户日活拆分以及各城市各端口的登录用户数优先定位核心下降城市。”这种答法的好处是具体判卷者一眼就能看出你有数据分析实战经验而不是背了一个模板。5.3 答题结构怎么组织才不像外行业务案例题通常是主观题没有标准答案但表达结构非常重要。我自己的模板是“一句话结论 三个主假设 验证顺序”。一句话结论是让你在200字以内说清楚你的判断。比如“我认为是某大城市的补贴策略收紧导致新用户首单转化率下降进而影响了日活。”三个主假设是围绕结论给出可证伪的方向。每个假设都要能对应一张数据表或一个具体指标不能只说“用户体验不好”。验证顺序是告诉判卷者你会优先做哪张表、看哪个指标。这里不需要把SQL写出来但你要让别人相信你能把分析做出来。我当时最大的教训就是别写完大段背景分析才给结论。判卷人没时间看你绕先给结论后补论据这才是数据岗的沟通习惯。6. 复盘一下时间失控、系统弹窗和那些本可以提前避开的坑6.1 我犯过的两个时间管理错误第一次做这种在线笔试题我的时间分配出了明显问题。第一个错误是SQL里死磕一个case。有一道SQL题我一直没跑通但原因其实只是一个字段名写错了。我花了将近8分钟反复调试做完才发现后面统计和业务题的时间被压缩了。笔试系统里SQL题通常不是让你肉眼手写而是要跑测试用例一旦卡住就非常容易上头。现在回头看正确的做法应该是先跳过把所有能拿分的大题做完最后如果还有时间再回来debug。笔试分数的收割顺序永远是“先拿确定的分再抢不确定的分”。第二个错误是在统计题里反复重算。其实我已经算出了答案但因为担心算错又用另一种方式算了两遍白白浪费了三分钟。后来我给自己定了一个原则只要式子列对、代入无误第一遍结果就作为最终结果不再回头看。这听起来有点赌但在限时场景里这个策略能让你把时间留给更有把握的题。6.2 在线笔试系统那些防不胜防的“额外随机事件”除了题目系统的意外是我完全没预料到的变量。进系统时我做了人脸识别但识别过程一直提示“光线不足”我只好把台灯搬过来补光。这个环节花了我五分钟当时心里的慌乱感比做错题还难受。后来我建议所有人在笔试前模拟一遍人脸识别流程不要等正式开考才发现机器或光线有问题。还有一个坑是弹窗。我的浏览器时不时会弹出一个“通知权限”请求第一次我差点手滑点到允许。考试系统的人脸监控本来就敏感一旦有弹窗覆盖到考试页面很容易被记一次“离开页面”。所以在开考前我建议把所有无关网站的通知权限全部关掉包括微信网页版、企业IM后台、邮箱客户端。网络断开是更崩溃的事情。我朋友在另一场笔试里遇到过中途断网系统自动锁住重新登录后倒计时还在走最后硬生生丢了几道题。如果你也遇到类似情况第一时间截图保存证据事后联系HR或技术支持。别慌系统一般有恢复机制但你必须留下记录。6.3 一份我认为值得反复使用的考前检查清单最后一次复盘时我把所有踩过的坑整理成了一张清单后来每场笔试前都会过一遍时间点检查内容考前一周刷一遍SQL窗口函数、日期函数、留存的常见写法整理一份个人速查表考前三天模拟一次在线考试环境测试摄像头、麦克风、浏览器权限考前一晚把概率公式和AB实验样本量公式手写一遍不靠脑子记考前两小时找一个光线稳定、安静、网络有线连接的位置开考前十分钟登录系统、关闭所有无关提醒、准备草稿纸和笔这个清单看起来琐碎但每一行都是我或者身边朋友用真实分数换来的经验。最后说点实在的。我后来再看这场笔试真正让我遗憾的不是某道题不会而是明明会做的题因为环境和节奏出了状况。笔试前一天把所有环境变量都控好比多刷十道题更值。希望这份复盘能帮你少踩几个我踩过的坑。