“摩拜2018校招数据分析工程师笔试卷”这份卷子，在我这几年复盘过的所有数据分析笔试里，出题质量一直排在前列。我记得当年一起投递的朋友考完出来，第一反应都是“题量太大”“业务场景太贴地气”，但恰恰是这种压迫感，逼出了一个人真实的分析功底。现在回过头看，它考察的不只是你会不会写SQL、懂不懂P值，更是你能不能在一个完整的业务闭环里——从用户开锁、骑行、支付到车辆调度——把业务问题翻译成数据问题，再把数据结论翻译回业务动作。想进互联网做数据分析的同学，拿这套卷子做一次限时摸底，比盲目刷十套普通习题都管用。
这篇文章我会按当年的试卷结构做一次完整复盘，把每类题型的考察意图、解题思路、易错点和现场时间分配策略都拆开讲透。内容主要基于我自己参加笔试的回忆、同期同学的经验复盘，以及对同类共享出行业务笔试的长期整理，虽然无法逐字还原原卷，但题型分布和核心考点是高度吻合的。不管你是正在准备校招，还是工作两年想回来补基础，这篇都能给你一个清晰的坐标系。
1. 试卷整体结构与考核逻辑
1.1 四类题型分布与考察目标
2018年的摩拜校招数据分析笔试，整体题量和现在主流大厂的数据分析笔试差不多，90到120分钟，题量在25到30道左右，分为统计学与概率、SQL与数据提取、业务分析、综合案例分析四个模块。我根据回忆和横向对比同类笔试题，整理出下面这个分布表，供参考。
| 模块 | 预估占比 | 考察核心 | 典型题型 |
|---|---|---|---|
| 统计学与概率 | 20% - 25% | 假设检验、分布、置信区间 | 计算P值、判断分布类型、求期望方差 |
| SQL与数据提取 | 25% - 30% | join、聚合、窗口函数 | 统计活跃车辆、算留存率、取TopN |
| 业务分析 | 25% | 指标体系、异动归因、用户分层 | 指标下降分析、补贴效果评估 |
| 综合案例分析 | 20% - 25% | 综合分析、框架思维、落地建议 | 车辆调度优化、新用户转化漏斗 |
这套比例本身就有讲究。真实的数据分析师日常工作，70%以上的时间花在取数和清洗上，所以SQL占比最高；但取完数之后，你还得用统计学的方法验证结论是否靠谱，这就是统计学模块存在的意义；最后所有结论都要落到业务动作上，所以业务题和案例题决定了你能不能拿到offer。四个模块缺一不可，只擅长其中任何一块，都会在笔试中露馅。
1.2 为什么共享单车行业出题这么“活”
很多人第一次看到这套卷子的感受是：题目怎么全是骑行时长、车辆调度、潮汐效应这些场景。这不是出题老师懒，而是共享单车业务本身就是数据分析的绝佳样本。它的数据有几个鲜明特征：高频、短时、海量用户、强地理位置属性、天气敏感、潮汐效应明显。一个地铁站早高峰涌出几百辆车，晚高峰又全部骑走，这种动态平衡背后全是数据问题。
所以这套试卷实际上是把“业务理解”和“数据技能”焊在一起考。你如果不懂潮汐效应，就理解不了为什么调度模型要按半小时粒度切分；你如果没拆过用户生命周期，就不知道为什么要用“首骑时间”作为用户分群的锚点。2018年共享单车战局正酣，每个城市每天产生上千万条骑行记录，能用数据把车调度好、把用户留下来的人，就是企业最需要的人。这种“真实业务倒逼技能考察”的出题思路，放到今天依然是数据分析笔试的标杆。
2. 统计学与概率：最该拿满分的模块
2.1 假设检验的考场解题模板
统计学部分，摩拜和绝大多数互联网笔试一样，最偏爱假设检验，尤其喜欢套在“运营策略上线前后对比”的场景里。我印象很深的一道题是：运营团队在某个区域增加了调度车辆频次，想验证用户平均骑行时长是否有显著提升。采样得到优化前样本和优化后样本各若干条，要求你写出完整的假设检验过程。
这类题其实是有固定解题模板的，按顺序走就不会乱。第一步，明确原假设和备择假设，这里一定是“优化前后平均骑行时长无显著差异”作为原假设，你要证明的是备择假设“优化后骑行时长显著增加”。第二步，判断用z检验还是t检验，2018年那个版本给的是大样本数据，用z检验；如果样本量小于30，就要用t检验。第三步，计算检验统计量，公式是两组均值之差除以标准误，注意这里要用合并标准误还是分别标准误，取决于方差是否齐性。第四步，查临界值或算P值，判断是否拒绝原假设。
这里有几个现场特别容易踩的坑。第一个坑是单尾检验和双尾检验傻傻分不清。题目说“显著提升”，这就是单尾检验，P值直接用单尾概率；如果题目说“有显著变化”，才是双尾检验。用错检验方向，即使最后算出P值是一个数，也会判错。第二个坑是P值理解的表述错误，P值不是“原假设为真的概率”，而是“在原假设为真的前提下，观测到当前或更极端结果的概率”。写结论的时候绕开“H0为真的概率是3%”这种表述，直接说“在显著性水平0.05下，我们有足够证据拒绝原假设，认为优化后骑行时长显著提升”，就是标准答案。第三个坑是样本独立性，如果优化前后的样本根本就是从同一批重度用户里采的，那就要考虑配对样本检验，但这道题给的是独立抽样，不用画蛇添足。
2.2 概率分布：泊松分布是共享单车的“本命分布”
概率分布的题在这套试卷里也占了不小比例。印象比较深的是问某个地铁站早高峰时段，车辆到达数量的概率分布类型。这种描述“固定时间窗口内随机事件发生次数”的场景，标准答案就是泊松分布，参数λ表示单位时间内的平均到达数。做题的时候关键是抓住题干里的标志词：“给定时间段”“独立随机”“平均发生次数”，只要三个条件都满足，直奔泊松分布。
很多同学容易把泊松分布和二项分布搞混。我的记忆方法是：二项分布描述的是“固定次数试验中的成功次数”，比如100辆车里有几辆损坏；泊松分布描述的是“固定时间或空间内的随机事件次数”，比如一小时内有多少用户开锁。前者试验次数固定，后者时间长度固定。考试时看题干给的是“试验次数”还是“时间窗口”，就能快速区分。
这类题还会延伸考期望和方差。泊松分布的期望和方差都等于λ，这个性质能用一句话记：既然事件是随机独立发生的，那么平均数和波动性自然都跟着“平均强度”走。如果题目给的是“每辆车的日均骑行次数为3.2次”，问你100辆车的日均总骑行次数的期望和方差，那就是100×3.2和100×3.2，用独立同分布方差可加性得出。现场考试时间紧张，遇到这类计算不要犹豫，直接套性质。
2.3 置信区间与中心极限定理
置信区间题几乎是必考，摩拜这套卷子的考法很朴素：给一组样本数据，让你求总体均值的95%置信区间。看起来简单，但考场上容易在“什么时候可以用正态分布近似”这个点上卡壳。中心极限定理告诉我们，不管总体分布是什么，只要样本量足够大（一般经验是n大于等于30），样本均值的抽样分布就近似正态。所以计算步骤就是：求样本均值、求样本标准差、用标准误乘以1.96（95%置信水平对应的z值），得到上下限。
这里有个细节想提醒大家：如果题目里的样本标准差用的是n-1的样本标准差，那直接用；如果给的是n的总体标准差（罕见），要区分清楚。另外，答题的时候一定要把结论写成业务语言，比如“我们有95%的把握认为，该区域用户平均骑行时长在12.3到15.7分钟之间”，而不是只写一个置信区间完事。数据分析师的产出是给决策者看的，把统计量翻译成业务判断，本身就是考核的一部分。
3. SQL题目解析：从取数到窗口函数
3.1 表结构与基础聚合
SQL模块是整套笔试卷的大头。2018年摩拜笔试给的表结构不算复杂，但非常贴近业务。我根据同类题目还原了下面这两张表，基本能覆盖当年的考点。
-- 车辆表 CREATE TABLE bikes ( bike_id VARCHAR(32) PRIMARY KEY, city VARCHAR(16), bike_type VARCHAR(8), -- 普通车/助力车 launch_date DATE ); -- 骑行订单表 CREATE TABLE ride_orders ( order_id VARCHAR(32) PRIMARY KEY, bike_id VARCHAR(32), user_id VARCHAR(32), start_time DATETIME, end_time DATETIME, start_lng DOUBLE, start_lat DOUBLE, end_lng DOUBLE, end_lat DOUBLE, amount DECIMAL(10,2) );第一道经典题一般是：统计每个城市每天的活跃车辆数，并按城市和日期排序。这题考察两个基础点：一是GROUP BY的分组逻辑，二是对时间字段的处理。很多同学一上来就写GROUP BY city, start_time，结果把同一天不同小时的数据全部拆成多行，这是典型的低级错误。
正确写法是先把时间戳转成日期，再按城市和日期聚合。
SELECT city, DATE_FORMAT(start_time, '%Y-%m-%d') AS ride_date, COUNT(DISTINCT bike_id) AS active_bikes FROM ride_orders GROUP BY city, DATE_FORMAT(start_time, '%Y-%m-%d') ORDER BY city, ride_date;这里有两个容易被忽略的细节。第一，必须要用COUNT(DISTINCT bike_id)而不是COUNT(*)，因为同一辆车一天内可能被骑了十几次，“活跃车辆数”关注的是有多少辆车产生了骑行，而不是产生了多少条订单。第二，DATE_FORMAT是MySQL里的写法，如果笔试环境是PostgreSQL或者SQL Server，函数名要换成TO_CHAR或CONVERT，这个只能靠平时的积累。摩拜这种快速迭代的创业公司，笔试环境一般不会指定数据库，所以把MySQL的常用函数写熟，再了解其他方言的差异是最稳的。
3.2 留存率计算：子查询与时间窗口
留存率在共享单车业务里有个特殊的定义问题：用户昨天注册了，今天来骑车的概率是多少？这就涉及到“活跃”的口径。笔试里给的表结构往往是ride_orders只有骑行订单，没有专门的用户活跃日志，所以需要从订单表里反推用户的活跃行为。
解题思路是先把日期拆出来，用子查询找到每个用户的首骑日期，再和后续的骑行记录做关联。用户首骑日期和某次骑行日期之间的天数差，就是活跃间隔。统计每个首骑日期次日还有骑行的用户数，除以首骑用户总数，就是次日留存率。
WITH first_ride AS ( SELECT user_id, MIN(DATE(start_time)) AS first_day FROM ride_orders GROUP BY user_id ) SELECT COUNT(DISTINCT r.user_id) / COUNT(DISTINCT f.user_id) AS next_day_retention FROM first_ride f LEFT JOIN ride_orders r ON f.user_id = r.user_id AND DATE(r.start_time) = DATE_ADD(f.first_day, INTERVAL 1 DAY);这题考的核心其实不是SQL语法，而是“留存”的口径定义。2018年很少有笔试会考CTE公共表表达式，但这道题用子查询嵌套也能写清楚。我当时的做法是先写注释，把逻辑分成两步，再填SQL，这样即使语法出了小问题，面试官看注释也知道我思路是对的。另外要注意留存率的计算是“第一天注册（或首骑）的用户中，第N天还活跃的比例”，分母是首骑用户数，不是当天活跃用户数，这个口径错了，整个结果都废了。
3.3 窗口函数：调度优先级的决胜题
这套试卷里真正能拉开差距的SQL题，是窗口函数。我印象里有一道题是：找出每个区域骑行量最高的前三个时段，用于指导车辆调度。这个场景非常真实——一个城市的调度员需要知道早高峰哪个区域最先爆量，才能提前把车运过去。
SELECT area, time_slot, ride_cnt, ranking FROM ( SELECT area, TIME_FORMAT(start_time, '%H:00') AS time_slot, COUNT(*) AS ride_cnt, ROW_NUMBER() OVER (PARTITION BY area ORDER BY COUNT(*) DESC) AS ranking FROM ride_orders GROUP BY area, TIME_FORMAT(start_time, '%H:00') ) t WHERE ranking <= 3;窗口函数的写法在2018年并不普及，很多人只听说过没用过。这里把ROW_NUMBER()换成RANK()或者DENSE_RANK()，结果会不一样：如果两个时段的骑行量完全一样，RANK()会并列跳号，DENSE_RANK()并列不跳号，ROW_NUMBER()则是随机或者按物理存储顺序分配一个唯一排名。题目如果只要求“前三个时段”，用DENSE_RANK()更稳妥，因为可以保证把并列的都取出来。这算是笔试里的一个隐藏考点，做对了就是加分项。
3.4 考场SQL答题的时间分配
SQL部分题量大，但分值也最高，所以绝对不能在这儿翻车。我的现场策略是：先花3分钟浏览所有SQL题，把每道题的考察点写在草稿上（join、group by、窗口函数、子查询），然后把会做的、逻辑简单的放在前面做，复杂窗口函数题放在后面。做的时候先写注释，把SQL的执行逻辑拆成几步，再填充具体语法。最后留10分钟从头检查一遍：GROUP BY字段是否完整、JOIN条件是否写了别名、WHERE和HAVING是否搞混、DATE_FORMAT函数是否有拼写错误。
一个真实的教训是，我当年在一道留存率题上卡了太久，结果最后一道窗口函数题只剩7分钟，只能匆匆写个半成品。后来复盘才知道，那道窗口函数题反而是全场最简单的一道。所以考场上的时间管理，有时候比解题能力更影响最终成绩。
4. 业务分析题：用共享单车场景练分析框架
4.1 指标体系：北极星指标的选择与拆解
业务分析题和综合案例分析题是摩拜这套卷子里最“见功力”的部分，不像统计学和SQL有标准答案，它考察的是一个数据分析师有没有形成自己的分析框架。第一类典型题型是给你一个业务目标，让你搭建指标体系，比如“请为共享单车业务搭建一套核心指标体系”。
这题看起来开放，实际上有套路。核心是围绕“北极星指标”展开，共享单车业务的北极星指标，我认为应该是“日骑行订单量”而不是“日活跃用户数”。原因是共享单车的商业模式本质上靠骑行次数产生收入和带动品牌渗透，一个用户一天骑三次和三个用户各骑一次，订单量不同，对平台的价值也完全不同。北极星指标要能反映用户获取的价值，骑行订单量显然比单纯的活跃用户数更贴近收入。
北极星指标定好之后，二级指标要从“供给、需求、匹配效率”三个角度去拆。供给端看可用车辆数、车辆完好率、车辆周转率；需求端看DAU、人均骑行次数、骑行时长分布；匹配效率端看车辆利用率、调度响应时间、无车可骑率。把这几个维度写出来，再配上一句“指标之间需要联动监控，不能只看单一指标”，就是一个让面试官挑不出毛病的答案。
4.2 指标异动归因：某区域订单量下降30%怎么分析
这个场景几乎是共享出行行业的必考题，摩拜2018年的卷子里也出现了。题目一般是这样：某区域最近一周订单量环比下降30%，你作为数据分析师，如何定位原因？
我当时给的答案是先画一个分析框架，从“内部因素”和“外部因素”两个大方向拆：
| 因素类型 | 具体原因 | 数据验证方式 |
|---|---|---|
| 外部-天气 | 连续下雨/降温 | 拉取气象数据，对比该区域历史雨天订单变化 |
| 外部-竞品 | 竞品在该区域投放更多车辆或降价 | 监控竞品App车辆密度，对比价格调整时间点 |
| 外部-节假日 | 区域内有大型活动或放假 | 查看日历，对齐订单下降的时间窗口 |
| 内部-供给 | 该区域车辆被大量调度走，或车辆故障率高 | 统计该区域可用车辆数、故障率和调度记录 |
| 内部-产品 | App在该区域出现定位/支付故障 | 看线上错误日志和用户投诉量 |
| 内部-价格 | 该区域起步价上调或新出了优惠策略 | 对比价格调整前后的订单变化 |
有了框架之后，还有个关键步骤：做“同一时间窗口的多区域横向对比”。如果只有这一个区域下降，其他区域正常，那大概率是区域性问题；如果全城所有区域都在下降，那就是天气、政策、竞品这类全局性因素。这个“对照组”思路，是你和其他候选人拉开差距的地方，一定要写在答案里。
4.3 用户分层与补贴策略
业务分析题还喜欢考用户分层，尤其是和补贴策略结合的场景。经典题目是：运营团队想针对不同用户人群制定差异化补贴策略，请设计一套用户分层方案并说明分层的用途。
摩拜这类共享出行产品，用户分层的框架可以沿用经典的RFM模型，但要结合业务做改造。R是最近骑行时间，F是骑行频率，M是消费金额。共享单车的M值普遍偏低且差异不大，所以F维度要更细，比如分为“高频通勤用户”“周末骑游用户”“羊毛党/流失边缘用户”“新用户”几类。针对不同人群，补贴策略完全不同：高频通勤用户送月卡或次卡折扣，周末骑游用户送周末免费骑行券刺激复用，流失边缘用户做大额回归券并配合Push召回，新用户则做首骑免费和前三单半价的组合。
这题的答题要点是：不要只写分层标准，一定要把“分层之后各用什么策略、预期效果是什么、如何评估ROI”闭环。一个合格的数据分析师，给出的不是标签，而是一套可以立刻落地执行并验收的战术方案。
5. 综合案例分析：校招笔试卷里的“大题”
5.1 车辆调度优化：读懂数据里的城市脉搏
综合案例分析题是整套卷子的压轴，往往是篇幅最长、信息量最大的一道题。摩拜2018年的案例大题，我的印象是给了某城市一周的骑行订单数据，包含时间、地点、骑行时长，让你分析潮汐规律，并设计车辆调度优化方案。
要解这道题，第一步是先做数据画像。把24小时切成若干个时段，按“工作日/周末”“早高峰/晚高峰”分组，统计各时段各区域的骑行流入量和流出量。你会发现一个规律：早高峰时段，住宅区是净流出地，写字楼和地铁站是净流入地；晚高峰则完全反过来。这种“潮汐”现象是共享单车调度的根本原因。
第二步是给调度策略。最基础的是“提前调度”，根据历史数据预测未来一小时各区域的需求，在早高峰来临前把车从住宅区往地铁站方向运；进阶一点的策略是“动态定价”，对逆潮汐方向骑行（比如早高峰从写字楼骑到住宅区）给予奖励，用价格杠杆驱动用户帮忙完成一部分调度；再有就是运维人员的“网格化调度”，把城市划分为500米乘500米的网格，每个网格经理负责自己辖区内的车辆平衡。
答题时一定要量化。比如“早高峰7:30到9:00，地铁A站周边的车辆需求是供给的2.1倍，通过对周边1公里内闲置车辆进行提前预调度，可以覆盖50%的缺口”。用数字驱动结论，才能体现数据分析师的价值。
5.2 新用户转化漏斗与首骑体验
另一道让我印象深刻的案例分析题是关于新用户转化漏斗的。题干大意：新用户从下载App到完成首次骑行，整个转化链路损耗严重，请你分析原因并给出优化建议。
这类漏斗题第一步就是把路径拆出来：下载App、完成注册、进行实名认证、打开地图找车、扫码开锁、完成首骑、支付成功。每一步都会有一个转化率，你需要判断哪个环节损耗最大，并针对性地给优化建议。比如下载到注册环节损耗大，可能是手机号验证流程太复杂；扫码开锁环节损耗大，可能是蓝牙连接不稳定或者车辆二维码损坏；首骑之后没有留存，可能是首次骑行定价过高或体验不好。
这里我特别想说一个很多新人容易犯的错：拿到漏斗题就直接天马行空地给建议，完全不做假设排优先级。正确做法是先说明“我需要拿到每一步的分渠道转化率数据，才能定位最薄弱的环节”，然后给一个通用的分析方法：用布拉德福定律或者帕累托图找出贡献主要损耗的前两个环节，优先优化，再配合A/B测试验证。这样回答既体现了数据分析师的严谨性，又不会因为缺少真实数据而显得空洞。
5.3 案例题通用答题框架：四步走
复盘多次之后，我把摩拜这类综合案例题的所有解法总结成一个“四步走”框架，放到任何业务场景里都能套用：
- 明确业务目标。先跟面试官确认这个案例要解决的核心问题是什么，是提升收入、降低成本还是改善用户体验，目标不清，后面全是白搭。
- 定义数据和口径。列出你想要的数据字段，定义清楚每个关键指标的口径，比如“活跃用户”是按“有骑行行为”还是“打开App”计算。
- 拆解路径和假设。把业务链路拆成若干环节，对每个环节提出可验证的假设，明确用什么数据进行验证。
- 输出可执行建议。结论要用“做什么动作、预期提升什么指标、如何验收”闭环呈现。
这个框架最大的价值是防跑偏。考试时间紧，写着写着思路就容易飞走，四个步骤列在草稿纸上，随时把自己拉回来。我后来带实习生，也一直让他们先写框架再写结论，这个习惯在职场上比单纯的解题能力更值钱。
6. 过来人经验：这套试卷暴露的四个薄弱点
6.1 业务感觉比代码基础更拉分
笔试复盘下来我最大的感受是，摩拜这套卷子真正难得不是SQL语法，而是“业务感觉”。同样的SQL题，套在“统计十大热门骑行区域”和“统计用户增长”上，做起来的感觉完全不同；同样的假设检验，套在“调度策略优化”和“按钮颜色改版”上，分析思路也有差异。很多人技术基础不错，但一遇到需要结合业务场景的题目就露怯，要么答案跑偏，要么逻辑空洞。
准备这种笔试，不能只刷LeetCode和SQL题。我建议每天花半小时去拆解一个你身边产品的数据问题，比如美团外卖的配送时效可以怎么分析、抖音的推荐效果如何评估。看多了、想多了，笔试题里的业务场景对你来说就是老相识，而不是拦路虎。
6.2 答不完题是常态，策略比蛮干重要
以2018年的题量设置，想在90分钟内从头到尾工工整整地把所有题写完，几乎不可能。我当年参加笔试时，周围好几个同学在结束铃声响起时还在写最后一道案例题。所以考场策略从一开始就应该定位为“拿稳能拿的分，再攻坚难题”。
我的建议是：统计学和概率题分值高、答案标准，限时20分钟内务必拿下；SQL题30分钟，先写简单的分组聚合和join题，窗口函数题留到最后；业务题和案例题分值高但没有唯一答案，阅卷看的是框架，所以20到25分钟内输出一个逻辑完整的大纲式答案就够了，不用追求字字雕琢。时间分配这件事，你在模拟练习的时候就要掐表训练，不要指望考场上临时安排。
6.3 纸上写代码的三点避坑心得
校招笔试大部分是纸质试卷或者线上纯文本编辑器，没有本地IDE的自动补全和校验，这时候写SQL的失误率会明显上升。我整理了三个高频踩坑点：
第一，SQL关键字大小写和分号。平时在IDE里怎么都能跑通，手写时经常漏分号，或者把GROUP BY写成GROUPBY，这种低级错误在判卷时特别扎眼。第二，表名字段名记不清。尽量在草稿纸上先把表和字段画出来，写SQL时直接对照，别凭记忆。第三，函数拼写错误。DATE_FORMAT、ROW_NUMBER这些函数名，建议平时每次练习都完整手写一遍，形成肌肉记忆。
还有一个很多人忽视的细节：笔试时写的SQL如果跑不出来，一定要在答案旁边用文字简述你的逻辑。比如“第一步先找出每个区域当天总骑行量，第二步再取Top3时段”。阅卷官看到逻辑是正确的，即使个别语法不对，也会酌情给分。
6.4 考后复盘比刷题更重要
考完摩拜笔试后的那个周末，我没有马上投入下一家公司的笔试，而是花了整整一个下午把这份卷子的每一道题重新做了一遍，并给每道题写了一段“复盘笔记”。比如这道题考的是留存率计算，我的问题出在把时间窗口算错了一天；那道案例题，我的框架缺了“指标验收”这一步。正是这种复盘，让我在后来的腾讯、美团笔试里明显感觉顺手了很多。
复盘的具体做法是：先把所有题型分类汇总，统计自己在每个模块的正确率和耗时；然后对每道错题写清错误原因，是知识点不会、审题不清还是时间不够；最后针对薄弱点做专项训练。这套方法现在还在用，它比盲刷十套题的价值大得多。
我个人的体感是，像摩拜2018校招这样一套笔试，考的不是你有没有背过标准答案，而是你能不能在一个紧迫的时间窗口内，用清晰的逻辑把一个模糊的业务问题拆解成可执行的数据分析方案。这种能力，拿到offer之后同样决定你的晋升速度。如果你正在准备数据分析方向的校招，建议把这份复盘当作一次完整的限时模拟——给自己90分钟，不求把每一题都答完美，只求把分析框架和解题节奏练成肌肉记忆。这套功夫下到位了，后面无论遇到什么风格的笔试题，你都不会慌。
