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分钟写个框架版本果断跳过把时间留给后面的题。