摩拜校招数据分析师笔试题解析：SQL、统计与业务思维全攻略

最近不少同学在准备数据分析方向的校招，翻出摩拜2018年校招数据分析工程师的笔试卷来研究。说实话，虽然这是好几年前的题了，但每年都有人拿它当模拟题练手，因为这套卷子的出题思路确实比较典型：既有硬核的SQL和概率统计，又有和业务强相关的场景题，基本上把数据分析工程师笔试最常见的几个考核维度都覆盖到了。我结合自己这些年参与校招面试和看过的各类笔试卷，把这套题背后的考察逻辑、解题思路和复习方法完整拆一遍，希望对准备数据岗面试的同学有帮助。

1. 这份笔试卷考了什么：整体结构与出题逻辑

1.1 摩拜2018年校招数据分析岗的基本画像

先搞清楚这份卷子是给谁出的。摩拜在2018年正处于快速扩张期，日均订单量千万级，车辆投放、用户增长、运营调度这些环节每天都在产生海量数据。那时候摩拜的数据分析工程师，核心任务不只是“出报表”，而是要把数据转化成运营决策的依据，比如车辆该往哪里投放、高峰期怎么调度、用户流失了该怎么召回。

所以笔试的定位很明确：招的不是纯代码选手，也不是纯统计学家，而是能落地、懂业务、能通过数据推动决策的人。反映到试卷上，就是基础技能题（SQL、Python、统计概率）和业务思维题（案例分析、指标拆解）各占一定比例，而且业务题往往没有标准答案，考察的是你拆解问题的逻辑是否清晰、假设是否合理、结论是否能落地。

1.2 模块分布与出题意图分析

我根据当年的考生回忆和同类笔试试卷结构，把考察内容大致梳理成下面几个模块：

出题意图其实很清晰：前三类是门槛，后两类是分水岭。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（投放日期）、status（1表示可用，0表示维修中）；
• trip：骑行记录表，字段包括trip_id、bike_id、user_id、start_time、end_time、start_station、end_station。

题目可以这样出：

1. 统计每个城市当前可用车辆数；
2. 统计最近7天每个城市的日均订单量；
3. 找出平均骑行时长最长的前5个城市；
4. 计算每个城市的车辆日均使用次数（订单量/车辆数）。

这些题目本质上就是一道题变着花样考：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(X=k) = (λ^k · e^(-λ)) / k!

其中λ=10，k=12。代入公式算一下，结果大概是0.0948左右。

很多同学能背出公式，但笔试时容易漏掉一个点：要先说明为什么可以假设为泊松分布。泊松分布适合描述单位时间内随机独立事件发生次数的场景，在地铁站这种单车需求量大、每个用户独立决策的场景下是基本合理的。这个“为什么能用”的说明，有时候比计算结果更能体现统计功底。

另一个常见变体是指数分布，比如“平均每10分钟来一单，求下一次订单在5分钟内到达的概率”。这其实就是把泊松过程的时间间隔用指数分布来描述，累积分布函数为：

F(t) = 1 - e^(-λt)

这里λ=1/10每分钟，t=5，算出来概率约为0.3935。这类题的共同点是：看似在考计算，实际在考你是否能把实际问题抽象成合适的概率分布模型。

3.2 AB测试与显著性检验

业务部门经常需要验证某个策略是否有效，比如“在App上把开锁按钮改成红色，是不是能提高骑行转化率”。笔试可能会让你设计一个AB测试方案，并分析结果是否显著。

回答这类题，可以按下面的框架来：

1. 明确实验指标：比如骑行转化率（点击开锁按钮后实际开锁的比例），主指标要先确定；
2. 设定原假设和备择假设：原假设H0是新版和旧版转化率没有差异，备择假设H1是新版转化率更高；
3. 确定样本量和实验周期：根据历史转化率、最小可检测提升幅度、显著性水平（通常α=0.05）和统计功效（通常1-β=0.8）来计算样本量，样本量公式可以用两独立比例检验的近似公式；
4. 随机分流：确保用户被均匀、独立地分配到实验组和对照组，避免分流不均造成偏差；
5. 结果分析：计算实验组和对照组的转化率差，做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做一次日报统计，两周内基本功会有明显提升。
• 概率统计薄弱：把概率论教材里的常见分布（二项、泊松、正态、指数）和假设检验、置信区间、回归分析都过一遍。刷题时不要只算答案，每道题都口头复述一遍“为什么用这个方法”。
• 业务思维薄弱：多看行业分析报告和公司公开的案例分析。看到一篇分析报告后，试着问自己：如果我是分析师，这个结论怎么从数据里得出？还有哪些数据可以补充分析？
• 表达和结构化能力弱：每次做完一道业务题，强迫自己用“背景—目标—分析框架—数据指标—结论—落地建议”的模板写下来，写到能在一分钟内讲清楚的程度。

我在实际带人和面试的过程中发现，笔试能拿高分的候选人不一定是最聪明的，但一定是最熟悉套路、表达最清晰的。数据岗位的笔试本质上是筛选两类能力：扎实的工具功底和清晰的业务思维。工具功底靠练，业务思维靠拆解和复盘，两者缺一不可。

最后再分享一个小技巧：如果你在笔试时遇到完全没思路的业务题，不要慌，试着从“用户、行为、结果”三个层面去拆。先想清楚这个业务里用户是谁、核心行为是什么、想要达成什么结果，再围绕这三个层面去铺指标和方案。这个三件套我试过无数次，基本能应对大多数开放式数据问题，希望也能帮你兜住底。