“摩拜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.9695%置信水平对应的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分钟不求把每一题都答完美只求把分析框架和解题节奏练成肌肉记忆。这套功夫下到位了后面无论遇到什么风格的笔试题你都不会慌。