最近不少同学在准备数据分析方向的校招翻出摩拜2018年校招数据分析工程师的笔试卷来研究。说实话虽然这是好几年前的题了但每年都有人拿它当模拟题练手因为这套卷子的出题思路确实比较典型既有硬核的SQL和概率统计又有和业务强相关的场景题基本上把数据分析工程师笔试最常见的几个考核维度都覆盖到了。我结合自己这些年参与校招面试和看过的各类笔试卷把这套题背后的考察逻辑、解题思路和复习方法完整拆一遍希望对准备数据岗面试的同学有帮助。1. 这份笔试卷考了什么整体结构与出题逻辑1.1 摩拜2018年校招数据分析岗的基本画像先搞清楚这份卷子是给谁出的。摩拜在2018年正处于快速扩张期日均订单量千万级车辆投放、用户增长、运营调度这些环节每天都在产生海量数据。那时候摩拜的数据分析工程师核心任务不只是“出报表”而是要把数据转化成运营决策的依据比如车辆该往哪里投放、高峰期怎么调度、用户流失了该怎么召回。所以笔试的定位很明确招的不是纯代码选手也不是纯统计学家而是能落地、懂业务、能通过数据推动决策的人。反映到试卷上就是基础技能题SQL、Python、统计概率和业务思维题案例分析、指标拆解各占一定比例而且业务题往往没有标准答案考察的是你拆解问题的逻辑是否清晰、假设是否合理、结论是否能落地。1.2 模块分布与出题意图分析我根据当年的考生回忆和同类笔试试卷结构把考察内容大致梳理成下面几个模块考察模块典型题型考察目的SQL留存率计算、订单统计、同环比、多表关联数据处理基本功是否扎实Python数据清洗、分组聚合、简单可视化逻辑是否具备实际分析工具链能力概率统计分布计算、期望值、假设检验、区间估计统计功底和业务推断能力业务分析题车辆调度、流失归因、指标体系设计数据思维和商业敏感度综合应用题专题分析策略、AB测试设计独立分析框架和表达能力出题意图其实很清晰前三类是门槛后两类是分水岭。SQL和统计题只要认真准备过大部分人都能拿到不错的分数这类题刷掉的是基本功不扎实的候选人。业务分析题则是拉开差距的地方它不以“对不对”来评分而是看你的分析框架是否完整、思考是否有深度、方案是否可落地。这个结构放在今天依然适用绝大部分互联网公司数据岗笔试都沿用了类似思路。所以摩拜这份卷子虽然年头久了但拿来当练习材料并不过时。2. SQL与数据处理最基础也最拉分的部分2.1 高频SQL题取数、留存、同环比先聊SQL。摩拜这类公司考察SQL从来不会只让你写一个简单的select查询而是会给你一张订单表、一张车辆表、一张用户表然后让你做复合统计。最常见的几类题目是计算某月每日的活跃用户数DAU计算新用户次日留存率、7日留存率计算某城市各区域早高峰时段的订单量排名计算订单量环比、同比的变化率。以留存率为例核心思路是先把用户按首次使用日期分组再关联出这些用户后续某天的使用记录。很多同学第一反应是用join但这里有一个关键点用户表可能很大直接用子查询和join如果不加优化条件跑起来会非常慢。标准做法是先找到每个用户的首单日期再与每日活跃表关联按首单日期和活跃日期分组统计用户数最后用活跃用户数除以首日新增用户数得到留存率。示意SQL大概是这样的以Hive或标准SQL为例-- 1) 每个用户的首单日期 with first_order as ( select user_id, min(order_date) as first_date from orders group by user_id ), -- 2) 每日活跃用户与首单日期关联 active as ( select o.user_id, o.order_date, f.first_date from orders o left join first_order f on o.user_id f.user_id ) -- 3) 按首单日期、活跃日期统计留存 select first_date, datediff(order_date, first_date) as day_diff, count(distinct user_id) as retained_users from active group by first_date, datediff(order_date, first_date) order by first_date, day_diff;这道题的隐藏考点是你有没有理解“留存”是按自然日对齐的而不是简单地看同一天有多少老用户回来。如果把口径弄混算出来的留存率会虚高或偏低。同环比也是高频考点。环比是和上一个统计周期比同比是和一整年前的同一周期比。共享单车受季节和天气影响很大如果只看环比夏天订单量上升可能被误判为运营策略有效加上同比才能剔除季节因素。所以这类题目考的不是计算而是你对业务波动核心因素的敏感度。2.2 动手实操一个最小可复现的SQL练习光看不练没意义。我这里给一个最小可复现的分析场景你可以自己建两张表练一下场景非常摩拜假设有两张表bike车辆表字段包括bike_id、city、launch_date投放日期、status1表示可用0表示维修中trip骑行记录表字段包括trip_id、bike_id、user_id、start_time、end_time、start_station、end_station。题目可以这样出统计每个城市当前可用车辆数统计最近7天每个城市的日均订单量找出平均骑行时长最长的前5个城市计算每个城市的车辆日均使用次数订单量/车辆数。这些题目本质上就是一道题变着花样考group by join 时间函数。你如果能在10分钟内把这几道题完整写出来SQL基本功基本过关。很多同学平时刷题用牛客、LeetCode其实效果不如拿业务表自己造数据练因为笔试题目更贴近实际数据形态而不是纯逻辑题。2.3 写SQL的三个常见失误点我在面试候选人的时候经常发现一些低级失误在这里提前帮大家避坑关联条件漏掉时间范围。统计每日指标时如果订单表和日期表关联很容易因为时区或日期格式不一致导致数据丢失或重复。建议在统计前先确认时间字段格式统一为yyyy-MM-dd。distinct使用泛滥。有些同学追求数据准确大量用count(distinct user_id)但笔试环境数据量大的时候会非常慢。合理做法是先缩小数据范围再用group by count效果一样但效率高很多。窗口函数、case when 使用不熟练。像row_number() over(partition by ... order by ...)这类用法在业务题里出现频率很高比如“每个城市日均骑行次数前3的车型”。平时练习一定要把窗口函数练熟这是从基础SQL进阶到业务SQL的分水岭。3. 概率统计别只会背公式要会用3.1 必考概率题共享单车场景中的泊松分布概率统计在摩拜笔试卷里占的比重不低尤其是和共享单车场景结合的概率题出得很有意思。一个典型题目是某地铁站附近的单车平均每小时被骑走10辆假设骑行需求服从泊松分布问某一小时恰好有12辆被骑走的概率是多少。这类题考的是泊松分布公式P(Xk) (λ^k · e^(-λ)) / k!其中λ10k12。代入公式算一下结果大概是0.0948左右。很多同学能背出公式但笔试时容易漏掉一个点要先说明为什么可以假设为泊松分布。泊松分布适合描述单位时间内随机独立事件发生次数的场景在地铁站这种单车需求量大、每个用户独立决策的场景下是基本合理的。这个“为什么能用”的说明有时候比计算结果更能体现统计功底。另一个常见变体是指数分布比如“平均每10分钟来一单求下一次订单在5分钟内到达的概率”。这其实就是把泊松过程的时间间隔用指数分布来描述累积分布函数为F(t) 1 - e^(-λt)这里λ1/10每分钟t5算出来概率约为0.3935。这类题的共同点是看似在考计算实际在考你是否能把实际问题抽象成合适的概率分布模型。3.2 AB测试与显著性检验业务部门经常需要验证某个策略是否有效比如“在App上把开锁按钮改成红色是不是能提高骑行转化率”。笔试可能会让你设计一个AB测试方案并分析结果是否显著。回答这类题可以按下面的框架来明确实验指标比如骑行转化率点击开锁按钮后实际开锁的比例主指标要先确定设定原假设和备择假设原假设H0是新版和旧版转化率没有差异备择假设H1是新版转化率更高确定样本量和实验周期根据历史转化率、最小可检测提升幅度、显著性水平通常α0.05和统计功效通常1-β0.8来计算样本量样本量公式可以用两独立比例检验的近似公式随机分流确保用户被均匀、独立地分配到实验组和对照组避免分流不均造成偏差结果分析计算实验组和对照组的转化率差做z检验或卡方检验看p值是否小于0.05同时计算置信区间而不是只看一个点估计。一个很常见的坑是不做样本量估算就直接上线实验。如果样本量不够实验结束时很容易得到“不显著”的结论但这可能只是统计功效不足并不是策略真的无效。所以笔试答题时一旦涉及AB测试一定要把样本量计算这步写进去这会让你的答案明显比只写“看p值是否小于0.05”的候选人高一个档次。3.3 常见失分点把概率当确定把相关当因果统计题失分往往不是公式没记住而是概念理解有问题。我在批改卷子和面试交流中发现下面几种情况最普遍混淆概率分布和现实确定性。比如算出泊松分布下某个结果的概率是0.1就觉得“不可能发生”。概率低不等于不会发生尤其在业务判断中不能只依赖概率大小做绝对化决策。把相关性直接当成因果性。笔试里经常给一张相关系数表然后问“哪些因素会影响用户骑行时长”很多同学直接写相关系数大的就是原因。严格来说相关性只能说明两个变量有关联不能说明谁影响谁还可能存在第三个隐藏变量。答题时一定要补一句“需要进一步做因果推断或控制变量实验”。忽略样本偏差。有些题会给一份抽样数据比如只在工作日采集的数据让你推断全周用户行为。如果不提样本偏差直接把结论推广到周末就会被扣分。点到这个点说明你真的有统计常识。4. 业务场景题数据思维的真正分水岭4.1 车辆调度与投放选点把数据分析落到地上摩拜最典型的业务场景就是车辆调度。笔试里一道经典开放题某城市早高峰时段大量用户从住宅区骑行到地铁站导致住宅区车辆被骑空而地铁站周边车辆大量堆积你会如何用数据辅助调度决策这个问题没有标准答案但答题的框架决定了你的分档。基础答法是把问题拆成“哪里缺车、哪里多车、怎么调”三步。优秀答法会在此基础上补充建立供需指数。比如用某个网格区域在某个时间段的“订单需求量/可用车辆数”作为供需紧张程度的度量供需指数越高说明越缺车需要优先调度。对调度请求做优先级排序。不能所有缺车点都同时调度要考虑调度车辆的运输时间、当前路况、后续需求趋势。用历史数据训练一个短时需求预测模型预测未来30分钟各区域的订单热度再结合当前库存做调度规划。设置动态阈值。调度阈值不能定死工作日和周末、晴天和雨天、早晚高峰和平峰时期供需指数达到多少需要触发调度这些阈值应该动态调整。闭环评估。调度完之后不能不管了要对比调度前后的供需指数、订单满足率、单车周转率看调度策略是否真的改善了用户体验和运营效率。我建议答题时不要贪多而是把一个方案讲透。比如围绕“供需指数”这一个核心指标从定义、计算方式、阈值设定、调度触发、后端评估完整说一遍比列七八个方向但每个都只写一句话要强得多。4.2 用数据拆解用户流失从指标到行动另一类高频题是用户流失分析。比如问某城市最近一个月骑行用户数下降了10%你如何分析原因并给出建议这道题的核心是三层漏斗先定位、再归因、最后给建议。定位层面先确认下降是普遍现象还是局部现象。把总用户数按月拆到城市、区域、用户类型新用户/老用户、月卡用户/单次付费用户看看是哪些群体下降最明显。还要看数据口径是活跃用户数下降还是订单量下降还是人均骑行次数下降这三个指标对应的问题完全不同。归因层面常见归因方向分内因和外因。内因包括App体验、计费规则调整、车辆投放减少、客服响应变慢外因包括天气变化、对手补贴、城市公共自行车竞争、出现新的出行方式。这时候要利用数据验证比如如果老用户流失严重就看他们的消费次数、骑行时长在流失前是否有逐步下降的趋势如果是某区域集中流失就结合该区域的车辆投放数据和竞品数据判断。建议层面建议必须可落地。如果发现包月用户骑行频次下降可以考虑做找回优惠券或积分激励如果发现新用户首骑后很快流失就重点优化新用户体验流程。尽量把建议和前面的归因一一对应形成“分析结论—数据依据—落地动作”的闭环。4.3 指标体系搭建从单点指标到全局视角业务题还会考指标体系比如让你为共享单车业务设计一套核心指标体系。这题的答题逻辑不是罗列一堆指标而是从业务目标出发分层设计。我会按这个框架来第一层北极星指标。共享单车业务的核心价值是“用户完成骑行次数”所以北极星指标可以是日骑行订单量或周活跃骑行用户数。这个指标要能反映产品给用户带来的核心价值而不是单纯的营收或装机量。第二层过程指标。用户从注册到完成一次骑行的链路每层都要有指标。注册转化率、激活率、找车成功率、开锁成功率、骑行完成率。这些指标帮助定位漏斗中哪一步流失最多。第三层体验指标。找车时长、开锁失败率、故障车比例、客服响应时长。体验指标往往和留存、口碑直接相关。第四层成本效率指标。单车周转率、单均运营成本、车辆维修周期、调度人效。共享单车是重资产模式效率指标关系到商业模式能否成立。答题时不要只列指标还要把指标之间的因果关系简单说清楚。比如开锁失败率上升会导致骑行完成率下降进而影响日订单量和用户留存这样主考官能看出你有全局思维而不是只会背指标名。5. 笔试实战策略与备考路径5.1 时间分配与做题顺序摩拜这份笔试卷题量不算小时间一般在90到120分钟。我见过很多同学在SQL题上死磕一道题导致后面业务分析题没时间写非常可惜。我的建议是先做自己有把握拿分的题再做需要思考的题最后啃硬骨头。具体操作上发卷后先花2分钟快速浏览全部题目标记出哪些是送分题、哪些是核心题、哪些是拔高题先做概率统计基础题和简单的SQL题这类题只要会做就能拿满分性价比最高再做业务分析题这类题不追求唯一答案但需要完整框架最好留足30分钟以上最后回头啃复杂的SQL题和综合应用题如果时间不够至少写出核心思路和第一步SQL能得步骤分。尤其要提醒业务分析题千万不要留白。哪怕没有完整思路把你想到的分析框架、关键指标、数据来源写出来也比一个字不写强得多。阅卷时往往对思路完整但细节不完美的答案给分更高。5.2 常见答题误区批改这类笔试卷多了发现几个特别普遍的问题这里集中说下答非所问。题目要求“分析原因”你答了一堆“如何做用户画像”。闭卷前先把题目问的是什么圈出来避免写偏。只有结论没有推导过程。业务题直接写结论“建议增加投放”但前面没有数据分析做支撑。数据分析岗位的笔试过程比结论重要一定要展示你是怎么从数据到结论的。SQL题不写注释、缩进混乱。不是你写对了就一定能被发现。SQL题建议加上简单注释逻辑层次用缩进或CTE拆清楚阅卷人一眼就能看懂你的思路。忽略数据口径。凡是涉及计算率的题目比如留存率、转化率、渗透率都要在答案里明确分子分母的定义。不同口径结果差异很大不写清楚会被认为分析不严谨。5.3 备考路径从一份卷子到一套方法如果你现在准备校招只刷摩拜这一套卷子是不够的。我的建议是把它当成“体检表”用来发现自己哪个模块薄弱然后再针对性补齐SQL模块薄弱去牛客或LeetCode刷SQL题重点练窗口函数、日期函数、多表关联。同时可以自己造一份模拟订单数据每天用SQL做一次日报统计两周内基本功会有明显提升。概率统计薄弱把概率论教材里的常见分布二项、泊松、正态、指数和假设检验、置信区间、回归分析都过一遍。刷题时不要只算答案每道题都口头复述一遍“为什么用这个方法”。业务思维薄弱多看行业分析报告和公司公开的案例分析。看到一篇分析报告后试着问自己如果我是分析师这个结论怎么从数据里得出还有哪些数据可以补充分析表达和结构化能力弱每次做完一道业务题强迫自己用“背景—目标—分析框架—数据指标—结论—落地建议”的模板写下来写到能在一分钟内讲清楚的程度。我在实际带人和面试的过程中发现笔试能拿高分的候选人不一定是最聪明的但一定是最熟悉套路、表达最清晰的。数据岗位的笔试本质上是筛选两类能力扎实的工具功底和清晰的业务思维。工具功底靠练业务思维靠拆解和复盘两者缺一不可。最后再分享一个小技巧如果你在笔试时遇到完全没思路的业务题不要慌试着从“用户、行为、结果”三个层面去拆。先想清楚这个业务里用户是谁、核心行为是什么、想要达成什么结果再围绕这三个层面去铺指标和方案。这个三件套我试过无数次基本能应对大多数开放式数据问题希望也能帮你兜住底。 摩拜校招数据分析师笔试题解析：SQL、统计与业务思维全攻略
最近不少同学在准备数据分析方向的校招翻出摩拜2018年校招数据分析工程师的笔试卷来研究。说实话虽然这是好几年前的题了但每年都有人拿它当模拟题练手因为这套卷子的出题思路确实比较典型既有硬核的SQL和概率统计又有和业务强相关的场景题基本上把数据分析工程师笔试最常见的几个考核维度都覆盖到了。我结合自己这些年参与校招面试和看过的各类笔试卷把这套题背后的考察逻辑、解题思路和复习方法完整拆一遍希望对准备数据岗面试的同学有帮助。1. 这份笔试卷考了什么整体结构与出题逻辑1.1 摩拜2018年校招数据分析岗的基本画像先搞清楚这份卷子是给谁出的。摩拜在2018年正处于快速扩张期日均订单量千万级车辆投放、用户增长、运营调度这些环节每天都在产生海量数据。那时候摩拜的数据分析工程师核心任务不只是“出报表”而是要把数据转化成运营决策的依据比如车辆该往哪里投放、高峰期怎么调度、用户流失了该怎么召回。所以笔试的定位很明确招的不是纯代码选手也不是纯统计学家而是能落地、懂业务、能通过数据推动决策的人。反映到试卷上就是基础技能题SQL、Python、统计概率和业务思维题案例分析、指标拆解各占一定比例而且业务题往往没有标准答案考察的是你拆解问题的逻辑是否清晰、假设是否合理、结论是否能落地。1.2 模块分布与出题意图分析我根据当年的考生回忆和同类笔试试卷结构把考察内容大致梳理成下面几个模块考察模块典型题型考察目的SQL留存率计算、订单统计、同环比、多表关联数据处理基本功是否扎实Python数据清洗、分组聚合、简单可视化逻辑是否具备实际分析工具链能力概率统计分布计算、期望值、假设检验、区间估计统计功底和业务推断能力业务分析题车辆调度、流失归因、指标体系设计数据思维和商业敏感度综合应用题专题分析策略、AB测试设计独立分析框架和表达能力出题意图其实很清晰前三类是门槛后两类是分水岭。SQL和统计题只要认真准备过大部分人都能拿到不错的分数这类题刷掉的是基本功不扎实的候选人。业务分析题则是拉开差距的地方它不以“对不对”来评分而是看你的分析框架是否完整、思考是否有深度、方案是否可落地。这个结构放在今天依然适用绝大部分互联网公司数据岗笔试都沿用了类似思路。所以摩拜这份卷子虽然年头久了但拿来当练习材料并不过时。2. SQL与数据处理最基础也最拉分的部分2.1 高频SQL题取数、留存、同环比先聊SQL。摩拜这类公司考察SQL从来不会只让你写一个简单的select查询而是会给你一张订单表、一张车辆表、一张用户表然后让你做复合统计。最常见的几类题目是计算某月每日的活跃用户数DAU计算新用户次日留存率、7日留存率计算某城市各区域早高峰时段的订单量排名计算订单量环比、同比的变化率。以留存率为例核心思路是先把用户按首次使用日期分组再关联出这些用户后续某天的使用记录。很多同学第一反应是用join但这里有一个关键点用户表可能很大直接用子查询和join如果不加优化条件跑起来会非常慢。标准做法是先找到每个用户的首单日期再与每日活跃表关联按首单日期和活跃日期分组统计用户数最后用活跃用户数除以首日新增用户数得到留存率。示意SQL大概是这样的以Hive或标准SQL为例-- 1) 每个用户的首单日期 with first_order as ( select user_id, min(order_date) as first_date from orders group by user_id ), -- 2) 每日活跃用户与首单日期关联 active as ( select o.user_id, o.order_date, f.first_date from orders o left join first_order f on o.user_id f.user_id ) -- 3) 按首单日期、活跃日期统计留存 select first_date, datediff(order_date, first_date) as day_diff, count(distinct user_id) as retained_users from active group by first_date, datediff(order_date, first_date) order by first_date, day_diff;这道题的隐藏考点是你有没有理解“留存”是按自然日对齐的而不是简单地看同一天有多少老用户回来。如果把口径弄混算出来的留存率会虚高或偏低。同环比也是高频考点。环比是和上一个统计周期比同比是和一整年前的同一周期比。共享单车受季节和天气影响很大如果只看环比夏天订单量上升可能被误判为运营策略有效加上同比才能剔除季节因素。所以这类题目考的不是计算而是你对业务波动核心因素的敏感度。2.2 动手实操一个最小可复现的SQL练习光看不练没意义。我这里给一个最小可复现的分析场景你可以自己建两张表练一下场景非常摩拜假设有两张表bike车辆表字段包括bike_id、city、launch_date投放日期、status1表示可用0表示维修中trip骑行记录表字段包括trip_id、bike_id、user_id、start_time、end_time、start_station、end_station。题目可以这样出统计每个城市当前可用车辆数统计最近7天每个城市的日均订单量找出平均骑行时长最长的前5个城市计算每个城市的车辆日均使用次数订单量/车辆数。这些题目本质上就是一道题变着花样考group by join 时间函数。你如果能在10分钟内把这几道题完整写出来SQL基本功基本过关。很多同学平时刷题用牛客、LeetCode其实效果不如拿业务表自己造数据练因为笔试题目更贴近实际数据形态而不是纯逻辑题。2.3 写SQL的三个常见失误点我在面试候选人的时候经常发现一些低级失误在这里提前帮大家避坑关联条件漏掉时间范围。统计每日指标时如果订单表和日期表关联很容易因为时区或日期格式不一致导致数据丢失或重复。建议在统计前先确认时间字段格式统一为yyyy-MM-dd。distinct使用泛滥。有些同学追求数据准确大量用count(distinct user_id)但笔试环境数据量大的时候会非常慢。合理做法是先缩小数据范围再用group by count效果一样但效率高很多。窗口函数、case when 使用不熟练。像row_number() over(partition by ... order by ...)这类用法在业务题里出现频率很高比如“每个城市日均骑行次数前3的车型”。平时练习一定要把窗口函数练熟这是从基础SQL进阶到业务SQL的分水岭。3. 概率统计别只会背公式要会用3.1 必考概率题共享单车场景中的泊松分布概率统计在摩拜笔试卷里占的比重不低尤其是和共享单车场景结合的概率题出得很有意思。一个典型题目是某地铁站附近的单车平均每小时被骑走10辆假设骑行需求服从泊松分布问某一小时恰好有12辆被骑走的概率是多少。这类题考的是泊松分布公式P(Xk) (λ^k · e^(-λ)) / k!其中λ10k12。代入公式算一下结果大概是0.0948左右。很多同学能背出公式但笔试时容易漏掉一个点要先说明为什么可以假设为泊松分布。泊松分布适合描述单位时间内随机独立事件发生次数的场景在地铁站这种单车需求量大、每个用户独立决策的场景下是基本合理的。这个“为什么能用”的说明有时候比计算结果更能体现统计功底。另一个常见变体是指数分布比如“平均每10分钟来一单求下一次订单在5分钟内到达的概率”。这其实就是把泊松过程的时间间隔用指数分布来描述累积分布函数为F(t) 1 - e^(-λt)这里λ1/10每分钟t5算出来概率约为0.3935。这类题的共同点是看似在考计算实际在考你是否能把实际问题抽象成合适的概率分布模型。3.2 AB测试与显著性检验业务部门经常需要验证某个策略是否有效比如“在App上把开锁按钮改成红色是不是能提高骑行转化率”。笔试可能会让你设计一个AB测试方案并分析结果是否显著。回答这类题可以按下面的框架来明确实验指标比如骑行转化率点击开锁按钮后实际开锁的比例主指标要先确定设定原假设和备择假设原假设H0是新版和旧版转化率没有差异备择假设H1是新版转化率更高确定样本量和实验周期根据历史转化率、最小可检测提升幅度、显著性水平通常α0.05和统计功效通常1-β0.8来计算样本量样本量公式可以用两独立比例检验的近似公式随机分流确保用户被均匀、独立地分配到实验组和对照组避免分流不均造成偏差结果分析计算实验组和对照组的转化率差做z检验或卡方检验看p值是否小于0.05同时计算置信区间而不是只看一个点估计。一个很常见的坑是不做样本量估算就直接上线实验。如果样本量不够实验结束时很容易得到“不显著”的结论但这可能只是统计功效不足并不是策略真的无效。所以笔试答题时一旦涉及AB测试一定要把样本量计算这步写进去这会让你的答案明显比只写“看p值是否小于0.05”的候选人高一个档次。3.3 常见失分点把概率当确定把相关当因果统计题失分往往不是公式没记住而是概念理解有问题。我在批改卷子和面试交流中发现下面几种情况最普遍混淆概率分布和现实确定性。比如算出泊松分布下某个结果的概率是0.1就觉得“不可能发生”。概率低不等于不会发生尤其在业务判断中不能只依赖概率大小做绝对化决策。把相关性直接当成因果性。笔试里经常给一张相关系数表然后问“哪些因素会影响用户骑行时长”很多同学直接写相关系数大的就是原因。严格来说相关性只能说明两个变量有关联不能说明谁影响谁还可能存在第三个隐藏变量。答题时一定要补一句“需要进一步做因果推断或控制变量实验”。忽略样本偏差。有些题会给一份抽样数据比如只在工作日采集的数据让你推断全周用户行为。如果不提样本偏差直接把结论推广到周末就会被扣分。点到这个点说明你真的有统计常识。4. 业务场景题数据思维的真正分水岭4.1 车辆调度与投放选点把数据分析落到地上摩拜最典型的业务场景就是车辆调度。笔试里一道经典开放题某城市早高峰时段大量用户从住宅区骑行到地铁站导致住宅区车辆被骑空而地铁站周边车辆大量堆积你会如何用数据辅助调度决策这个问题没有标准答案但答题的框架决定了你的分档。基础答法是把问题拆成“哪里缺车、哪里多车、怎么调”三步。优秀答法会在此基础上补充建立供需指数。比如用某个网格区域在某个时间段的“订单需求量/可用车辆数”作为供需紧张程度的度量供需指数越高说明越缺车需要优先调度。对调度请求做优先级排序。不能所有缺车点都同时调度要考虑调度车辆的运输时间、当前路况、后续需求趋势。用历史数据训练一个短时需求预测模型预测未来30分钟各区域的订单热度再结合当前库存做调度规划。设置动态阈值。调度阈值不能定死工作日和周末、晴天和雨天、早晚高峰和平峰时期供需指数达到多少需要触发调度这些阈值应该动态调整。闭环评估。调度完之后不能不管了要对比调度前后的供需指数、订单满足率、单车周转率看调度策略是否真的改善了用户体验和运营效率。我建议答题时不要贪多而是把一个方案讲透。比如围绕“供需指数”这一个核心指标从定义、计算方式、阈值设定、调度触发、后端评估完整说一遍比列七八个方向但每个都只写一句话要强得多。4.2 用数据拆解用户流失从指标到行动另一类高频题是用户流失分析。比如问某城市最近一个月骑行用户数下降了10%你如何分析原因并给出建议这道题的核心是三层漏斗先定位、再归因、最后给建议。定位层面先确认下降是普遍现象还是局部现象。把总用户数按月拆到城市、区域、用户类型新用户/老用户、月卡用户/单次付费用户看看是哪些群体下降最明显。还要看数据口径是活跃用户数下降还是订单量下降还是人均骑行次数下降这三个指标对应的问题完全不同。归因层面常见归因方向分内因和外因。内因包括App体验、计费规则调整、车辆投放减少、客服响应变慢外因包括天气变化、对手补贴、城市公共自行车竞争、出现新的出行方式。这时候要利用数据验证比如如果老用户流失严重就看他们的消费次数、骑行时长在流失前是否有逐步下降的趋势如果是某区域集中流失就结合该区域的车辆投放数据和竞品数据判断。建议层面建议必须可落地。如果发现包月用户骑行频次下降可以考虑做找回优惠券或积分激励如果发现新用户首骑后很快流失就重点优化新用户体验流程。尽量把建议和前面的归因一一对应形成“分析结论—数据依据—落地动作”的闭环。4.3 指标体系搭建从单点指标到全局视角业务题还会考指标体系比如让你为共享单车业务设计一套核心指标体系。这题的答题逻辑不是罗列一堆指标而是从业务目标出发分层设计。我会按这个框架来第一层北极星指标。共享单车业务的核心价值是“用户完成骑行次数”所以北极星指标可以是日骑行订单量或周活跃骑行用户数。这个指标要能反映产品给用户带来的核心价值而不是单纯的营收或装机量。第二层过程指标。用户从注册到完成一次骑行的链路每层都要有指标。注册转化率、激活率、找车成功率、开锁成功率、骑行完成率。这些指标帮助定位漏斗中哪一步流失最多。第三层体验指标。找车时长、开锁失败率、故障车比例、客服响应时长。体验指标往往和留存、口碑直接相关。第四层成本效率指标。单车周转率、单均运营成本、车辆维修周期、调度人效。共享单车是重资产模式效率指标关系到商业模式能否成立。答题时不要只列指标还要把指标之间的因果关系简单说清楚。比如开锁失败率上升会导致骑行完成率下降进而影响日订单量和用户留存这样主考官能看出你有全局思维而不是只会背指标名。5. 笔试实战策略与备考路径5.1 时间分配与做题顺序摩拜这份笔试卷题量不算小时间一般在90到120分钟。我见过很多同学在SQL题上死磕一道题导致后面业务分析题没时间写非常可惜。我的建议是先做自己有把握拿分的题再做需要思考的题最后啃硬骨头。具体操作上发卷后先花2分钟快速浏览全部题目标记出哪些是送分题、哪些是核心题、哪些是拔高题先做概率统计基础题和简单的SQL题这类题只要会做就能拿满分性价比最高再做业务分析题这类题不追求唯一答案但需要完整框架最好留足30分钟以上最后回头啃复杂的SQL题和综合应用题如果时间不够至少写出核心思路和第一步SQL能得步骤分。尤其要提醒业务分析题千万不要留白。哪怕没有完整思路把你想到的分析框架、关键指标、数据来源写出来也比一个字不写强得多。阅卷时往往对思路完整但细节不完美的答案给分更高。5.2 常见答题误区批改这类笔试卷多了发现几个特别普遍的问题这里集中说下答非所问。题目要求“分析原因”你答了一堆“如何做用户画像”。闭卷前先把题目问的是什么圈出来避免写偏。只有结论没有推导过程。业务题直接写结论“建议增加投放”但前面没有数据分析做支撑。数据分析岗位的笔试过程比结论重要一定要展示你是怎么从数据到结论的。SQL题不写注释、缩进混乱。不是你写对了就一定能被发现。SQL题建议加上简单注释逻辑层次用缩进或CTE拆清楚阅卷人一眼就能看懂你的思路。忽略数据口径。凡是涉及计算率的题目比如留存率、转化率、渗透率都要在答案里明确分子分母的定义。不同口径结果差异很大不写清楚会被认为分析不严谨。5.3 备考路径从一份卷子到一套方法如果你现在准备校招只刷摩拜这一套卷子是不够的。我的建议是把它当成“体检表”用来发现自己哪个模块薄弱然后再针对性补齐SQL模块薄弱去牛客或LeetCode刷SQL题重点练窗口函数、日期函数、多表关联。同时可以自己造一份模拟订单数据每天用SQL做一次日报统计两周内基本功会有明显提升。概率统计薄弱把概率论教材里的常见分布二项、泊松、正态、指数和假设检验、置信区间、回归分析都过一遍。刷题时不要只算答案每道题都口头复述一遍“为什么用这个方法”。业务思维薄弱多看行业分析报告和公司公开的案例分析。看到一篇分析报告后试着问自己如果我是分析师这个结论怎么从数据里得出还有哪些数据可以补充分析表达和结构化能力弱每次做完一道业务题强迫自己用“背景—目标—分析框架—数据指标—结论—落地建议”的模板写下来写到能在一分钟内讲清楚的程度。我在实际带人和面试的过程中发现笔试能拿高分的候选人不一定是最聪明的但一定是最熟悉套路、表达最清晰的。数据岗位的笔试本质上是筛选两类能力扎实的工具功底和清晰的业务思维。工具功底靠练业务思维靠拆解和复盘两者缺一不可。最后再分享一个小技巧如果你在笔试时遇到完全没思路的业务题不要慌试着从“用户、行为、结果”三个层面去拆。先想清楚这个业务里用户是谁、核心行为是什么、想要达成什么结果再围绕这三个层面去铺指标和方案。这个三件套我试过无数次基本能应对大多数开放式数据问题希望也能帮你兜住底。