2024年秋招，饿了么数据岗笔试我前后准备了大概三周，最后拿到面试通知时复盘了一下，发现这个岗位的笔试其实很有规律：它不像互联网大厂通用卷那样考察玄学逻辑题，而是紧紧围绕着“业务+数据”这个主线来出题。如果你现在正要投递数据岗，或者已经收到了笔试通知，这篇文章希望能给你一个相对完整的参考框架。我会把题型、考点、准备思路、实际作答的取舍全部展开讲，尽量说人话，不堆术语。
1. 笔试整体认知：这个岗位到底考什么
1.1 数据岗笔试的底层逻辑
先聊一个很多人忽略的问题：笔试到底在筛什么人？
我个人的理解是，数据岗笔试的核心目的不是筛掉“不会写代码”的人，而是筛掉“不具备数据思维”的人。什么叫做数据思维？就是你看到一个业务问题，能不能自然地转化成指标、能联想到哪些数据可以回答、知道拆解的思路。饿了么作为本地生活服务平台，数据岗要处理的无外乎三个方向：C端用户增长、B端商户运营、履约配送效率。笔试题目基本都带着这三块业务底色。
所以备考的第一步不是刷LeetCode，而是了解业务。建议大家花一两个小时把饿了么的业务板块在脑子里过一遍：用户侧有首单、复购、会员、优惠券；商户侧有入驻、流量分配、活动报名、佣金；履约侧有配送时长、超时率、骑手运力。笔试题目不管怎么包装，最终都要落回这些业务逻辑上。
1.2 饿了么笔试的题型布局与时间压力
我参加的这场笔试总时长是120分钟，题量不算大，但类型跨度很大，大致分布是这样的：
- 单选和多选：约15题，覆盖统计学、机器学习基础、概率论、业务常识
- SQL编程：3题，从简单查询到中等难度的多表关联和窗口函数
- Python编程：1到2题，偏数据处理和逻辑实现，不是纯算法题
- 业务分析题：1到2题，需要文字作答，考察分析思路
- 产品逻辑题：偶尔出现，考察对功能/场景的理解
时间上看，120分钟做下来并不宽裕，尤其是SQL和Python如果现场debug，时间会非常紧张。我当时的策略是：选择题控制在35分钟内，SQL和Python大题留下60分钟，剩下25分钟给文字分析题。后面我会详细拆这套策略的执行细节。
2. 核心考点拆解：各板块怎么拿分
2.1 SQL：送分题也要写出区分度
SQL在饿了么这类数据岗笔试里基本是必考项，难度大概率是力扣中等偏下，核心考察集中在三类操作：多表关联（JOIN）、聚合分组（GROUP BY）、窗口函数（ROW_NUMBER、RANK、LAG/LEAD）。我那年考到的一道题大体是：给定订单表和用户表，要求统计每个城市当月新用户的首单金额和首单时段分布。其实就是JOIN + ROW_NUMBER的条件匹配，再加一个GROUP BY的分组统计。
这种题表面看不难，但想拿满分有一个容易被忽略的点：边界处理。比如新用户可能在下单当天就被拆单，会生成多个子订单；比如跨天订单的归属时间不同；比如优惠券抵扣后实付金额的计算口径。这些细节是区分“只会写JOIN”和“真正处理过数据”的关键。
实操上，我建议在本地用SQLite或者MySQL建两张测试表，把笔试里可能出现的场景都模拟一遍。窗口函数千万不要只停留在背语法，要能默写出ROW_NUMBER() OVER(PARTITION BY ... ORDER BY ...)的完整书写方式，因为线上笔试的编辑器没有自动补全。
2.2 Python与基础统计：效率与概念双线考核
Python题目的难度一般不会到LeetCode中高难度，更偏向于pandas数据处理、循环逻辑和简单算法实现。比如给你一个包含用户行为日志的DataFrame，要求计算相邻两次下单的时间间隔，筛选出24小时内重复下单的用户。这种题用pandas写很顺手，但笔试环境不一定安装了pandas。
这里有个重要建议：准备两套Python写法。如果环境里有pandas，直接用df.groupby和diff之类的函数；如果只有纯Python环境，要能用字典和列表推导式完成同样的逻辑。很多时候不是不会做，而是依赖了某个库导致场面失控。
统计学概念也是选择题的重灾区：假设检验里的p值含义、置信区间的解释方式、正态分布的性质、中心极限定理、方差和标准差的区别。这些概念看似基础，但出题人喜欢挖一些反直觉的迷惑选项。我当时就栽过一道题：问置信区间95%的拒绝域到底是什么含义，选项里有一个“总体参数落在区间内的概率是95%”，这明显是错的，正确答案是“重复抽样中95%的区间会包含真实参数”。这种区分度就藏在基础概念的精细理解里。
2.3 机器学习与AB实验：业务结合才是分水岭
机器学习在笔试里的占比不会特别大，但常出现一两道题来探测你的认知深度。题型多半是：在某个业务场景下选择合适模型，或者对召回率、精确率、AUC的理解。比如饿了么的营销活动场景，预测用户是否会在未来7天内下单，问用什么模型合适、正负样本不平衡怎么处理。
这里要注意，答题一定要踩在业务语境里。不要只写“用XGBoost”，可以简单补充一句为什么要用：这类表格型特征场景，树模型对非线性关系和高阶交互的表达力强，且对缺失值天然容忍，实际效果往往比深度模型稳定。信息量瞬间不同。
AB实验相关的知识也需要掌握。平台型公司非常看重你能否设计实验、判断实验有效性。需要掌握的包括：实验分桶的SRM问题（样本比例失衡怎么办）、显著性检验的p值怎么解释、实验周期多久合适（要覆盖一个完整的用户行为周期，比如外卖至少要包含工作日和周末）、AA实验的作用。我记得有一道选择题就是问“一个实验只跑了一天就显著，应该怎么判断”，正确思路是怀疑新奇效应，而不是直接全量上线。
2.4 业务分析题：怎么从“会做表”到“会分析”
业务分析题是数据岗笔试的重头戏，也是最难速成的部分。题目通常长这这样：某地区外卖订单量连续三周下滑，作为数据工程师/分析师，你会如何分析这个问题？
这种题没有标准答案，但判卷人一定有偏好。我总结出来的高分框架是：先定义问题，再拆解维度，最后给出数据需求和分析方法。千万不要上来就写“先看数据”，而是要说清楚看什么数据、为什么看这些数据。
我当时是这样拆解的：先确认“订单量下滑”是绝对量下降还是增速放缓，排除口径问题；再把订单量拆成“用户数 × 人均下单频次”，用户数继续拆新客和老客；对于新客要看渠道投放效率和转化率，对于老客要看流失率和沉睡唤醒；还要看竞争环境，比如周边竞对是否做了大规模促销；最后看平台内部动作，比如价格策略、配送费调整、流量分配逻辑有没有变化。每一步都要对应到具体的数据表和指标，才能体现你真的懂业务分析。
2.5 产品与逻辑题：有些坑别踩
有一部分岗位会夹带产品场景题，考的是对业务的理解和独立思考能力。比如“如果让你设计一个小功能提升午餐时段的订单量，你会选择什么功能？为什么？”这种题没有对错，但很能看出一个人是“有想法”还是“只会执行”。
我建议答题时遵循一条线：目标用户是谁，想改变什么行为，核心功能是什么，如何衡量效果。不要贪多，写一个功能点深入展开就够了，逻辑必须自洽，最后一定要提到衡量指标，这是数据岗区别于产品岗的关键。你把指标体系设计清楚，就已经赢了一半。
3. 系统准备与实操过程：从真题到模拟的完整复盘
3.1 备考时间线与资料盘点
如果从现在开始准备，我建议留出至少两周，把时间切三段：第一周补基础，第二周刷题，第三周模拟与查漏。基础部分重点是SQL窗口函数和业务分析框架，资料方面直接看《SQL必知必会》加力扣的数据库板块就够了，不需要把整本《高性能MySQL》啃完，笔试用不到。
业务分析框架可以参考《精益数据分析》里的经典指标拆解思路，再结合公众号里的一些行业分析文章建立场景感。如果有条件，可以在饿了么或美团上自己下一单，观察订单详情页、优惠展示、配送预估这些信息模块，理解数据在业务前端如何被使用。这不是废话，这种真实体验会在业务题里帮上大忙。
刷题部分不用贪多，力扣SQL的简单和中等难度做熟40题左右，Python用pandas刷一遍常见的分组、合并、透视操作，基本就覆盖了笔试的代码部分。重点不在于题量，而在于对每个做过的题都能讲清楚边界情况和适用范围。
3.2 笔试现场的时间分配策略
这里说一个我实际测试过有效的方案。选择题拆成两个阶段：第一遍快速扫过，会做的立刻选，不会的标记跳过。全部单选题完成后，回头统一处理标记题，但每道题只允许再思考一分钟，还是拿不准就直接蒙一个，不恋战。因为后面SQL和业务题的每1分含金量都比选择题高得多，别因小失大。
SQL题我的习惯是“先写框架后补细节”：先把主要逻辑骨架搭好，保证没有语法错误，然后再考虑边界条件和特殊情况。线上笔试环境通常没有很强大的调试工具，核心思路是写一步验证一步，不要全部写完再debug。如果是可以逐段执行的环境，就果断逐段跑。
业务分析题建议预留至少20分钟，因为文字量不小，而且需要条理。不要让面试官从一大堆文字里帮你找重点。合理的使用小标题和序号，一份整洁的回答本身就能加分。
3.3 一道典型综合题的完整作答演示
这里我完整复盘一道我在准备时反复练习的题目，题型非常接近真实笔试的风格。题目大意是：平台近期上线了大额满减活动，活动城市和非活动城市的订单量都有上升，但活动城市的人均客单价反而下降了，请分析可能原因，并设计指标体系来评估活动效果。
第一步一定要先明确“人均客单价”的定义，是实付金额除以订单数，还是实付金额除以用户数。口径不同，结论可能完全相反。如果按订单维度计算人均客单价，那么下降可能来自新用户占比提高，因为新用户首单的客单价一般偏低；也可能是满减门槛设计在订单金额40到50元的区间，原本客单价在60元以上的用户为了凑单反而把金额降到了45元左右。
第二步要拆解订单结构：活动城市的订单增长来源是什么？如果是新用户带来大量低价订单，那客单价下降是健康的；如果让老用户把大单拆成了小单来多次用券，那就要警惕补贴效率问题。从库存和履约的角度，还要考虑大量低价订单是否会拉低配送效率和商户利润。
第三步要设计评估指标体系：围绕活动有效性，至少应该看活动ROI（补贴金额换来的增量GMV）、新老用户结构变化、客单价分层变化、90天复购率有没有改善，以及是否产生了“活动依赖”。这些指标放到一张监控看板里，就能形成对活动效果的立体评价。这个框架在笔试里基本可以通用，换什么业务场景都能套。
4. 常见失分点与排查技巧实录
4.1 SQL和数据处理的五个高频失误
第一个高频失误是JOIN条件写错或漏写条件，导致笛卡尔积。两个几万行的表做笛卡尔积，线上环境直接卡死，时间就白白浪费了。我的经验是每写一个JOIN，立刻在下边加一行注释，说明左表和右表的键分别是什么，有没有一对多的情况。
第二个是GROUP BY和SELECT字段不匹配。很多环境中非聚合字段不在GROUP BY里会直接报错，但有些环境是静默处理的，结果数据完全不对。为了避免这个问题，我先规划好输出的明细粒度，再决定去重方式是用DISTINCT还是ROW_NUMBER。
第三个是日期时间字段的处理。外卖业务高峰期跨天数，比如深夜订单，你在做“自然日”分组的时候如果直接截取日期字符串，会把凌晨订单归入前一天，造成数据偏差。笔试里如果出现时间字段，第一时间想一想是否需要考虑时区、跨天、默认格式三个问题。
第四个是窗口函数和WHERE的执行顺序理解错。在WHERE里用窗口函数会直接报错，因为WHERE在SELECT之前执行，这个顺序很多新手常犯。处理的办法是子查询或CTE先计算好窗口字段，外层再做过滤。
第五个是漏考虑NULL值。比如LEFT JOIN后右表没有匹配记录，关键指标会出现空值，如果不做COALESCE处理，后面的计算可能带上NULL参与运算导致结果异常。笔试中多写一句COALESCE或者IFNULL，也许就是你比别人多出来的那点分。
4.2 业务题答非所问的三种典型错误
第一种是分析框架太大，落到不了具体场景。比如问外卖订单下滑的原因，回答从宏观到微观把行业走势全部写一遍，但没有任何一条具体到这个城市的用户行为变化。不要试图用一个大而全的框架覆盖所有可能性，数据岗的价值恰恰在于把问题定义到可操作的程度。
第二种是只有假设没有验证方法。说了一堆“可能是价格问题”“可能是竞对问题”，但是没有对应说明用什么数据去验证，这个假设成立不成立。面试官想看的不仅是发散思维，更多的是验证路径。应该写“用某时段某区域内价格弹性系数来验证价格影响，同时对比自然流量下没领券用户的下单率来判断是价格还是流量的问题”。
第三种是忽略业务方视角，只谈数据技法。比如大谈模型的调参技巧，但完全没提这个模型上线之后如何参与业务决策。数据岗的一切工作最终都要落到业务动作上，你的分析要能告诉业务方该干什么，而不是只告诉他们发生了什么。
4.3 心态与原题：最后的提醒
再补充一个很多人忽略的细节：笔试之前一定要去了解清楚岗位所在团队的具体业务方向。同样是饿了么数据岗，做用户增长和做物流规划，考官的出题偏好可能完全不同。我当时特意去脉脉和牛客搜了一圈往年面经，发现用户增长方向的笔试更偏向AB实验和用户分层，物流方向更偏向路线优化和时效预测。虽然不完全准确，但至少能让你在复习时有所侧重。
考试当天，环境检查比想象中更重要。提前一天把摄像头、浏览器、网络这些都跑一遍，不要等到开考前十分钟才手忙脚乱。笔试过程中如果遇到页面崩溃或者提交失败，第一时间截图保留证据，然后联系HR说明情况，一般都能安排补考。
最后再分享一个我踩过的坑：不要在某道题上死磕超过15分钟。我当时有一道SQL题，对输出结果的排序要求理解错了，反复调试了小20分钟，导致最后一道业务分析题只写了要点没有展开，整体得分肯定受了影响。回头看那道排序，其实影响并不大，而业务分析题的字数是实打实的印象分。如果时间重来，我会果断用10分钟写个框架版本，果断跳过，把时间留给后面的题。
