2024蚂蚁数据岗笔试复盘：从SQL到业务指标的硬核拆解

2024年春招蚂蚁集团数据岗第一批笔试说实话这批题目给我的整体感觉是基础题占比不低但区分度全藏在“看起来不难”的题里。先说下我的背景普通211统计专业硕士有过两段互联网中厂数分实习平时刷题以LeetCode SQL为主Python主要靠业务实战积累没专门刷过算法硬核题。这套背景去考蚂蚁数据岗有点代表性也给后来人一个参考坐标。笔试是牛客网线上双机位一共两个小时题量大概在20道左右题型分布大概是单选多选大概10道SQL大题2道Python代码题1道剩下的是业务场景问答题。纯纯的数据岗风格不考工程架构不考大数据组件底层原理但考察你对数据分析底层逻辑、业务落地敏感度。下面逐块拆解把还有印象的题和思路整理出来。1. 从笔试结构看蚂蚁数据岗的用人逻辑先说结论蚂蚁的数据岗笔试并不像开发岗那样“一棍子打死”它的题量和难度其实在互联网大厂里面算是中等偏上但风格非常“蚂蚁”。整套卷子两个小时题型结构大致如下客观题单选多选约10道覆盖概率统计、机器学习基础、业务指标理解、SQL语法细节。SQL编程题2道一道偏常规查询一道带窗口函数和漏斗分析。Python编程题1道不考复杂算法考数据处理和逻辑抽象。业务分析题1道直接给你一个业务场景要求搭建指标体系或者分析框架。从结构能看出蚂蚁数据岗要的是三类硬能力基础扎实、数据提取效率高、业务逻辑框架清晰。这和市面上一些偏“机器学习模型”的数据岗笔试很不一样。蚂蚁的数据岗更偏“数据分析和决策支持”方向比如商业分析、运营分析这类岗位对模型深度的要求其实不及对业务理解深度的要求。另外整场笔试还有一个隐藏考点时间分配。客观题里好几道需要动笔算期望、算概率的题如果磨太久后面SQL和业务题就没时间写了。我复盘时发现凡是能顺利做完的基本都遵循“客观题15分钟内解决战斗SQL题40分钟Python题20分钟业务题30分钟留15分钟检查”的节奏。2. 各知识板块的考察深度还原2.1 概率统计不考偏怪但爱考条件概率和贝叶斯这批笔试的概率统计题让我印象很深因为大部分题目并不超纲但需要你想得快。有一道题大概是这样某支付场景风控模型误报率为5%漏报率为1%实际风险交易占比为0.5%。问当模型报警时这笔交易真正是风险交易的概率是多少这就是一道标准贝叶斯题。设风险交易占比P(A)0.005报警率P(B|A)0.99因为漏报率1%误报率P(B|非A)0.05。那么P(A|B) 0.99 × 0.005 / (0.99 × 0.005 0.05 × 0.995)算出来大概是0.09也就是即使模型报警真实风险概率也还不到10%。这道题考察的不只是贝叶斯公式更重要的是业务理解——风控模型不能只看准确率要看基准率和误报率之间的博弈。还有一道题考了期望这是典型的“低成本高区分度”题一个抽奖活动抽中概率为1%抽一次成本1元中奖奖励50元问连续抽100次期望收益是多少如果没有中奖上限直接用二项分布期望算结果是50-100-50元。但这类题经常会加“最多中奖一次”的条件那就需要用几何分布或者分段函数去算。当时我特意多看了一眼题干确实没有上限条件于是直接用了二项分布。这里给后来人一个提醒多选题的坑在于选项里经常有“看似对但边界条件不对”的说法。比如考中心极限定理时有一个选项是“无论样本容量多大样本均值都服从正态分布”这个说法就是错的漏了“n足够大”的前提。这种题目不是考你记不记得住公式而是考你对统计概念“适用条件”的敏感度。2.2 SQL窗口函数是分水岭漏斗分析是压轴SQL题一共有两道难度层级拉得比较开。第一道是常规查询表结构大概是用户支付表user_id, pay_time, pay_amount, merchant_id要求统计每个商户在2024年1月的支付用户数、支付总金额、笔均金额并按支付用户数降序排序。这题只要会用GROUP BY和聚合函数就能解属于送分题但要注意一点笔均金额不是SUM(pay_amount)/COUNT(*)很多表里会有一条订单拆多笔支付的情况需要用SUM(pay_amount)/COUNT(DISTINCT order_id)或者用SUM(pay_amount)/COUNT(pay_id)取决于订单维度还是支付维度。这道题表面上考SQL实际上考你对业务口径的敏感度。第二道SQL是典型的漏斗分析。场景大概是用户在APP内从浏览商品到提交订单再到支付成功给你三张表浏览记录表user_id, item_id, view_time、订单表order_id, user_id, item_id, order_time、支付表order_id, pay_time。要求统计每个环节的用户转化率并且要输出“提交订单但两小时内未支付”的用户明细。这题的难点在于漏斗每一步的用户集合怎么定义浏览用户数是不是去重后的user_id提交订单用户数是不是从订单表去重支付用户数是否要关联支付表这里最容易出错的是“提交订单但两小时内未支付”的筛选不能用NOT EXISTS直接关联支付表因为可能存在“当天支付但超过两小时”的情况要先用时间差函数把两小时内的支付记录过滤掉再去做LEFT JOIN。这类题考的就是日常数分工作的基本功漏斗分析是互联网数据分析最高频的分析框架之一笔试基本是必考的。建议把“浏览→点击→提交→支付”这类经典链路的SQL写法练到肌肉记忆。2.3 Python不是算法题而是数据清洗和逻辑抽象Python大题难度不大但对代码规范有要求。题目大致是给定一个包含用户交易记录的列表每个元素是一个字典包含字段user_id、trans_time、amount、trans_type要求按用户分组计算每个用户在一个月内的交易总金额并且输出单笔金额超过1000元的交易次数占比。这题的常规思路是用defaultdict分组然后遍历计算。但不建议直接拿pandas去做因为很多笔试平台的Python环境不一定装了pandas用纯Python实现更稳妥。我当时写的核心逻辑大概是from collections import defaultdict user_stats defaultdict(lambda: {total_amount: 0, high_count: 0, trans_count: 0}) for record in trans_list: uid record[user_id] user_stats[uid][total_amount] record[amount] user_stats[uid][trans_count] 1 if record[amount] 1000: user_stats[uid][high_count] 1 for uid, stats in user_stats.items(): stats[high_ratio] stats[high_count] / stats[trans_count]这种题的核心考点不是语法而是能不能在不依赖第三方库的情况下用最直接的方式完成数据分析任务。很多做数据的人习惯了一上来就pandas但笔试环境里反而要求更基础的编程能力。还有一点蚂蚁这种级别的公司对代码可读性是有要求的。变量命名要有意义逻辑分支要清晰不能写一堆看不明白的列表推导式嵌套。2.4 机器学习只考概念不考手推公式机器学习相关的客观题分值大概有3-4道覆盖了过拟合的解决方法、交叉验证的目的、线性回归和逻辑回归的区别、特征选择的方法。有一道多选题问“以下哪些措施可以缓解过拟合”选项包括增加训练数据量、降低模型复杂度、正则化、交叉验证。我一开始想选“交叉验证”因为交叉验证确实能帮助发现过拟合。但仔细想想交叉验证本身并不能直接缓解过拟合它只是帮你评估泛化能力、选择超参数。真正的缓解手段是前三个。这就是多选题的坑一个方法如果只是“有助于评估”而不直接作用于减轻过拟合那它就不是正确答案。另外有一题是给了一组数据要求判断该用线性回归还是逻辑回归。这类题实际考的是因变量类型是连续还是离散。如果你的预测目标是“用户是否会流失”0/1即使特征和标签之间看起来有线性关系也必须用逻辑回归。蚂蚁的数据岗笔试对机器学习的考察不会太深更侧重“你在实际分析场景中是否记得用对方法”。所以准备这批笔试不用疯狂啃PRML把常见模型的使用场景、优缺点、基本概念过一遍就够。3. 业务分析题指标体系搭建是核心中的核心最后一道业务题花了我最多时间写也是我最想分享的。题目大概是“为蚂蚁森林的‘绿色能量’功能设计一套指标体系用来评估该功能的健康度和用户参与度要求包括指标定义、计算口径、数据来源和预期用途。”这道题本身不设标准答案考的就是你有没有搭过指标体系的经验。我的回答框架是这样的目标拆解层面我把绿色能量功能指标分为北极星指标、过程指标、结果指标三个层级。北极星指标用的是“每日活跃收集能量的用户数DAU”因为这直接反映核心功能参与度过程指标包括每日打开蚂蚁森林页面用户数、每日收取能量用户数、每日好友互动浇水/偷能量用户数、能量产生到被收取的转化率结果指标包括七日留存率、用户平均好友互动数、绿色能量碳减排总量等。计算口径上我特别强调了几个细节活跃用户的定义是“当日完成至少一次收取或浇水动作”不是“打开页面就算”能量收取转化率的分母是“当日产生能量的用户数”分子是“当日收取能量的用户数”避免把未产生能量的“僵尸用户”拉低转化率留存率采用“新增用户中N日后仍活跃的比例”。数据来源上活跃数据来自APP埋点日志event 蚂蚁森林_收取能量能量产生数据来自服务端“能量发放记录”表好友互动数据来自“浇水/偷取日志”表。这道题的价值在于它让你现场演示一个数据人最基本的素养。不是让你上来就写SQL而是先想清楚“我要用什么指标来衡量这个业务”。回答的逻辑层次、口径定义的严谨度、对业务目标的理解都会在阅卷时被重点评估。对后来人建议平时做业务分析时多积累“指标体系”的搭建经验不要只做临时取数。面试官想看到的是你能从业务目标出发去设计度量体系而不是只会执行需求。4. 几个容易丢分的答题雷区这些坑有的是我自己踩的有的是复盘时和同批笔试的同学对答案发现的写出来帮大家避雷。第一个雷区客观题里不写计算过程只写答案。很多平台是主观题模式不能只给最终答案需要把推导步骤写清楚。特别是概率题就算你只写结果阅卷人也可能因为看不到你的思路而给低分。我当时每道概率题都写了公式和关键计算步骤这习惯一定要养成。第二个雷区SQL题不检查字段类型和空值。用户ID在两张表里可能一张是字符串一张是数值型直接JOIN会全表匹配失败。空值处理也很关键统计均值时如果直接用AVGNULL会被忽略但如果业务上要“把无支付记录的用户算作0”就需要用COALESCE先做转换。这类细节数据人平时都要注意笔试里更加放大。第三个雷区时间分配严重失衡。我认识一个一起笔试的同学客观题做了40分钟结果最后业务题只写了两句话。客观题一道才1-2分业务题一道可能占20分这个性价比一定要算清楚。进了笔试页面先花半分钟把所有题扫一遍标记分值大、耗时长的题优先保证大题的答题质量。第四个雷区Python题用不存在的库。笔试平台不一定预装pandas和numpy用纯Python实现的方案永远最稳。另外如果环境里确实可以用pandas也要先import试试不要默认它存在。我在平台环境里试过pandas不可用所以老老实实写了纯Python版本。5. 笔试结束后的复盘与总结笔试结束后我第一时间做了复盘把每个板块的得分预期和失误点列了出来方便后续面试时针对性补强。复盘时最大的感受是这套笔试题出得相当“聪明”它没有刻意刁难你但每一道题都在还原真实的数据分析工作场景。真实做数据分析是什么状态是你拿到一个需求先理解业务目标再拆解决思路然后写SQL取数拿到数据后再用Python做二次加工最后把结果沉淀成业务可用的结论。这套笔试恰好就是这条链路的缩版。给未来备考蚂蚁数据岗的同学三个核心建议第一SQL基本功一定要扎实。不是会写简单的SELECT就够了窗口函数、漏斗分析、时间差计算、去重逻辑都要非常熟练。建议至少刷完SQL面试高频50题每道题尽量手写而不是只在脑子里过。第二概率统计不能只背公式。多关注贝叶斯、条件概率、期望计算在业务场景中的应用。蚂蚁的风格是把数学题包装成业务场景如果你只看懂了公式、看不懂背后的业务逻辑很容易被选项中的干扰项带偏。第三业务分析题要形成自己的答题框架。任何一个业务场景先拆目标、再定义指标、再定义口径、再考虑数据来源这个框架要烂熟于心。可以提前准备几个经典案例比如“评估一个活动效果”“评估一个功能健康度”“评估一个推荐策略的收益”练习用STAR原则去组织答案。整体来看蚂蚁数据岗笔试更看重的是数据分析思维的完整性和执行力而不是死记硬背的“知识点”。如果你平时就是真正在业务中做分析的人这套题对你是友好的。我当时考完虽然心里没底但复盘时发现凡是按照业务惯性去答题的部分基本都答在了点上。希望这份复盘对准备下一批笔试的同学有帮助。