滴滴校招数据挖掘笔试解析：算法、SQL与业务场景全攻略

看到“滴滴出行2018校园招聘网申笔试-数据挖掘工程师(第一批）”这个标题，估计不少人第一时间会去翻当年的面经，想看看有没有原题。但我今天想聊的，是比原题更值钱的东西：这场笔试到底在筛什么人，数据挖掘工程师这个岗位在校招笔试阶段看重什么，以及你用什么样的复习策略能稳稳吃下这类考试。

2018年那会儿，正是网约车平台精细化运营竞争最凶的阶段，数据挖掘岗位在校招里的定位非常明确——不是招一个会调包跑模型的算法研究员，而是招一个能直接上手处理海量订单数据、从用户行为里挖出规律、能落地策略的人。所以那批笔试题目（第一批）的知识点分布、出题风格、考察深度，放到今天依然有很强的参考价值。不管你准备的是大厂的数据挖掘、机器学习，还是数据分析岗，这套笔试的考察逻辑都值得你花时间拆解一遍。

我结合当年考生回忆版的题型结构、同类互联网公司校招数据岗的通用考法，以及我自己带人准备这类笔试的经验，把这场笔试的核心考点、每类题背后的真实意图、复习优先级都整理出来了，后面还附了一套可以照做的备战时间表和踩坑实录。

1. 这份笔试在筛选什么样的人——岗位定位与题型总览

1.1 数据挖掘工程师的日常职责决定了笔试考点

先别急着刷题，你得先搞清楚滴滴这类公司里的数据挖掘工程师，日常工作到底是什么样的，不然你连考点为什么这么设计都看不透。

出行平台的数据挖掘工程师，核心任务基本是这几块：用户画像搭建（判断一个用户是通勤族还是夜猫子）、价格敏感度分析（调到什么折扣能激发叫车需求）、订单供需预测（预估某个区域未来半小时的用车需求）、司乘匹配策略优化（让司机少空驶、乘客少等待）、以及风控相关的异常行为识别（刷单、虚假注册）。这些任务听起来高大上，但落到笔试题目上，就是基础算法、SQL取数、统计概率、机器学习基础、业务场景题这几大块。

换句话说，这场笔试不是要你背出某个深度模型的公式推导，而是要看你在拿到一堆真实业务数据时，能不能用最基本的工具和思维把问题拆开、算出可用的结果。我见过太多简历上写“精通TensorFlow”的同学，一考SQL和概率题就露馅。笔试出题人很聪明，他们知道基础题才能真正拉开差距。

1.2 笔试的整体题型结构与时间分配

从当年参加过的同学反馈看，滴滴2018校招数据挖掘工程师的第一批笔试，整体结构偏向“算法题+基础题”混合卷，线上笔试系统统一计时，时间压力给得比较足。

综合同类互联网公司（美团、京东、头条等）同年数据岗笔试的通行结构，我还原一个高概率的题型分布框架，你可以对照着看自己的薄弱项：

注意，这里说的题量和占是参考常模，不同批次会有浮动。但权重方向是明确的：算法题权重最大，这道关过不了，后面基本没戏。我后面会挨个模块拆解具体考点。

1.3 从考点倒推岗位能力地图

如果你把上面这个题型分布和“数据挖掘工程师日常任务”对应起来看，会发现一条清晰的能力链路：

• 算法编程题 → 考察的是你写代码解决问题的底子，因为真实业务里你要写的可不止是模型脚本，还有各种ETL逻辑、特征处理代码；
• SQL题 → 考察的是你面对一张张原始订单表时，能不能快速提取出建模和复盘要用的数据；
• 概率统计 → 考察的是你能否理解用户行为里的不确定性，能不能用AB实验判断一个策略到底有没有效；
• 机器学习基础 → 考察的是你会不会在真实场景里正确选择和使用模型，而不只是会调包；
• 业务题 → 考察的是你有没有“指标思维”，能不能把一个含糊的问题翻译成可计算、可验证的数据问题。

这五条链路，本质上是一个数据挖掘工程师从“取数—理解数据—建模—落策略—评估效果”的完整工作流。笔试的所有题目，都是在用一套考试语言模拟你未来半年的工作内容。所以复习的时候千万别割裂地学，要把这些考点串成一条线。

2. 算法与数据结构：笔试的基础盘，决定你能不能进下一轮

2.1 为什么数据挖掘笔试要先过算法关

很多同学不理解：我投的是数据挖掘岗，又不是后端开发，为什么要花一大半时间做算法题？这个问题我当年也困惑过，直到自己工作后带实习生才彻底想明白。

原因有三个。第一，算法题是筛选效率最高的方式，线上笔试系统一次要判几千份卷子，编程题能机器判分、能快速看代码风格，是性价比最高的筛选项；第二，数据挖掘工程师虽然名义上做算法，但日常有大量时间在写数据处理代码，很多特征逻辑写不好就会引入数据泄漏、内存溢出这类问题，代码功底差的同学根本接不住；第三，算法能力某种程度上反映了你的逻辑思维严密性，连经典动态规划都想不明白的人，很难指望他能把复杂的业务问题抽象成数学模型。

所以我的建议是：别抱怨，老老实实刷题。这不是滴滴一家的问题，全行业的数据岗都这么考。

2.2 高频题型与解题套路

具体到滴滴笔试这个批次，结合2018年前后各大厂数据岗笔试的高频题库，以下几类算法题型值得重点准备：

• 数组与遍历类：这类题最简单，但最容易出细节坑。比如“求数组中连续子数组的最大和”“合并两个有序数组”“寻找数组中的众数”。核心套路是双指针、前缀和、哈希表辅助记录，别一上来就暴力循环。
• 字符串处理类：数据岗的字符串题往往和实际数据清洗有关。比如“判断括号是否有效”“字符串去重保序”“最长无重复子串”。这类题要做熟，因为实际业务里处理用户埋点数据、日志数据时，字符串操作占大头。
• 动态规划类：这是拉开差距的地方。常考的有“爬楼梯”“最小路径和”“最长公共子序列”“编辑距离”等基础DP，进阶一点会考“背包问题”变种。数据挖掘里很多优化问题本质是DP，比如司乘匹配里常用的匈牙利算法思想就和DP有交集，所以笔试偏爱DP不是没道理。
• 贪心与排序类：比如“会议室安排”“根据身高重建队列”“最大数”。这类题技巧性强，想明白贪心策略后代码往往很短，考察的是你分析问题本质的能力。
• 树的遍历：相对高频的是二叉树的前中后序遍历、层次遍历、最近公共祖先。虽然数据岗日常写树的机会不多，但它是算法基础的一部分，属于必须会的内容。

2.3 一道典型题的完整推演

我拿一道当年笔试同级别难度的题目举例——最长无重复子串，要求给定一个字符串，找出其中不含重复字符的最长子串长度。看着简单，但真写起来很多人第一反应是三层循环暴力枚举，复杂度直接O(n^3)，在笔试系统里只能拿部分分。

正确思路是用滑动窗口加哈希表，维护一个窗口，窗口内保证没有重复字符。右指针每次往前走一步，如果在哈希表里发现了重复字符，左指针就跳到重复字符上次出现位置的下一位。这样每个字符最多被访问两次，时间复杂度降到O(n)。

这类题的核心套路我总结成一句话：遇到“子串”“子数组”这种连续区间问题，优先想滑动窗口能不能解，不要把暴力枚举作为默认方案。面试官看的是你的复杂度分析意识，代码能跑只是及格线。

3. SQL与数据操作：数据工程师的基础生存技能

3.1 笔试中SQL考的其实是什么

SQL题在整张卷子里占比不算最高，但它是最容易被忽视的送分区域。为什么说是送分？因为SQL语法本身不难，只要练习过几个核心场景，基本都能写出来。但为什么又有大量同学在SQL题上丢分？主要是没读懂考察重点。

笔试里的SQL题，从来不是让你查个单表数据就完事，而是会模拟一两张业务表，让你做维度拆解。比如滴滴的场景大概率会给你一张订单表和一张司机表，让你算某个城市每个时段的完单率、不同品类订单的平均应答时长这类指标。这背后的核心考察点有三个：多表关联的准确度、分组聚合的逻辑清晰度、以及对业务指标口径的理解。

3.2 高频SQL场景与写法

结合出行行业和数据岗通用的SQL考察方式，这几个场景你必须在笔试前练熟：

• 分组聚合：求每个品类下的订单量、GMV、完单率，这是最基础但最稳的考察点。核心是GROUP BY配合COUNT、SUM、AVG，别忘了HAVING和WHERE的区别。
• 多表关联：订单表和用户表关联查用户等级分布，司机表和城市表关联查不同城市的运力情况，核心是JOIN的语义。最容易被扣分的地方是把INNER JOIN和LEFT JOIN搞混，导致结果行数不对。
• 窗口函数：按用户分组求最近一次下单时间、按城市排名。当时窗口函数还不是所有考生都会，会的人就能拉开差距，现在几乎成了笔试标配，ROW_NUMBER、RANK、LAG这几个必须熟练。
• 去重与去脏数据：求去重后的活跃用户数，排除异常订单。这类题考察你处理真实数据的意识，写的时候记得考虑DISTINCT语义和数据过滤条件。

我列一个典型的SQL题示例，你可以感受一下考法和思路：

有一张订单表orders，字段包括order_id、user_id、city_id、order_amount、order_time、order_status（1完成，0取消）；请统计各城市完成订单的总金额以及订单量。

这个题看起来简单，但第一坑是order_amount要不要乘以订单状态？注意题干要求“完成订单的总金额”，所以必须在WHERE里加order_status = 1，或者用SUM(CASE WHEN ...)处理。第二个坑是“订单量”，如果题目没明说，一般指完成订单的笔数，那就和金额同口径。这类细节很容易因为审题不细丢分。

3.3 容易翻车的细节

SQL题还有几个容易被判错的地方：一是别名问题，多表关联时两个表如果有同名字段，必须用表别名限定，否则直接报错或结果错乱；二是聚合与非聚合列混用，SELECT里出现了既不在GROUP BY里、也没有被聚合函数包裹的列，这在MySQL那套严格模式下直接报错，笔试系统判分也会扣；三是NULL值处理，做COUNT时NULL不计入，做SUM时NULL不影响，但如果你用COUNT(列名)和COUNT(*)搞混，结果会差很多。

这些都是靠刷题能够避开的坑。我的建议是笔试前至少把SQL zoo之类的在线练习刷一遍，重点练窗口函数和复杂JOIN，别把时间花在最基本的SELECT上。

4. 统计与机器学习：从公式到业务的跳跃能力

4.1 统计基础题背后的工程意义

统计和概率题看着像数学考试，实际是在考察你面对业务不确定性时能不能做量化判断。比如去重活跃用户数按泊松分布近似估计、用户留存率按二项分布建模、策略上线后的销量变化做显著性检验——这些都会以选择题或填空题的形式出现。

我见过不少复习资料把这些题归为“送分题”，但我强烈不同意。恰恰是这类题，最能区分一个人是“背过公式”还是“真理解分布”。滴滴这种业务里，叫车需求在时间和空间上高度波动，一个合格的数据挖掘工程师得能判断什么场景该用泊松分布近似、什么场景该上负二项模型、什么时候直接用经验分布更稳。

复习统计基础时，这五个知识点优先级最高：古典概型与条件概率（贝叶斯公式的简单应用）、常见分布（二项、泊松、正态、指数）的期望方差、大数定律与中心极限定理、参数估计与置信区间、假设检验的流程和两类错误。别去啃复杂的数理统计推导，重点放在“给定一个业务场景，知道套哪个公式、算出来怎么解读”。

4.2 机器学习考点：懂原理更要懂场景

机器学习基础题通常是选择题相对多的部分，但也有问答或简单计算题。考察范围以经典模型为主：线性回归、逻辑回归、决策树、随机森林、GBDT、K-Means、KNN、朴素贝叶斯、SVM的基础原理。

这里我想特别提一句，很多同学复习机器学习喜欢死抠公式推导，但笔试考察的往往是更“工程”的方面：过拟合怎么检测和缓解、训练集和测试集怎么划分、特征标准化和归一化的区别、样本不均衡怎么处理、模型评估指标该选哪个。举个例子，分类问题里正负样本严重失衡，准确率这个指标会失真，应该看AUC还是F1？这个问题你答不上来，说明你对模型的工程使用还没建立直觉。

还有一个高频考点是“为什么逻辑回归要做特征离散化”。这题看起来偏理论，实际上是因为在工业界，特征离散化之后模型会更稳定、更抗噪，还能做特征交叉，这是数据挖掘工程师在日常特征工程中的真实操作。

4.3 业务场景题的作答思维

业务场景题是整张试卷里最像“工作内容”的题目，通常给一个具体业务场景，比如“滴滴某城市夜间订单量突然下降，请你分析可能的原因并给出排查思路”或者“如何评估一个司机激励策略是否有效”。这类题没有标准答案，但阅卷人有非常清晰的评分点。

正确的作答框架是五步走：第一步，明确核心指标，把“订单量下降”翻译成“完单量下降=发单量×应答率×完单率”这类指标拆解；第二步，列出可能原因维度，比如时间维度（是否为节假日前后）、空间维度（是否某个区域特别严重）、用户维度（是否某个用户群体流失）、竞品维度（是否存在其他出行平台抢占）；第三步，给出数据验证方案，说明需要取哪些表、算哪些指标来验证每个假设；第四步，针对确认的原因给出策略建议；第五步，说明如何评估策略效果，也就是设定实验组和对照组、确定核心观测指标和实验周期。

这个框架如果你提前练熟，业务题基本不会慌。阅卷人想看的不是你给出一个“标准答案”，而是你遇到一个模糊问题时，能不能结构化地拆解它，并且站在“能落地”的角度提出方案。这和平时做实践项目的思路完全一致，多练几次就能找到感觉。

5. 从这场笔试反推：备战数据挖掘笔试的完整策略与踩坑实录

5.1 按考点拆解复习优先级

很多人备战此类笔试的通病是平均用力，觉得哪里都要复习，结果最后哪里都没复习透。根据这场笔试的权重分布和通过难度，我的优先级建议是这样的：

第一优先级是算法编程题。每天至少两到三道LeetCode中等难度题，重点刷数组、字符串、动态规划、滑动窗口、双指针。坚持三周以上，基本能覆盖笔试中出现频率最高的题型。别贪多，把一类题型做透比刷十道不同题型更有用。

第二优先级是SQL。这块投入产出比极高，每天花半小时专门做一道多表关联或窗口函数的题，连续两周就有明显提升。重点是把JOIN语义、GROUP BY细节、窗口函数语法练成肌肉记忆，考场上才能快速写对。

第三优先级是机器学习基础和统计概率。这两块不适合突击，更适合用小本本做知识卡片，每天早晚翻看。核心是理解概念和场景，不用陷入公式推导的泥潭。

第四优先级是业务场景题。这个靠的是“行业理解+框架思维”。我会在考前一周集中看几篇关于出行行业指标体系的文章，同时练习“指标异动分析”的答题框架，做到任何业务题都能快速套进“拆指标—列原因—给验证方案”的三段式里。

5.2 一个月复习节奏表

如果你离笔试还有一个月，我建议你按下面这个节奏来，亲测效率最高：

这个节奏的核心逻辑很简单：前面以“练题量”建立手感，后面以“模拟真实考试节奏”来发现问题。千万别在最后一周还在学新知识点，那是无效焦虑，不如把已学内容巩固牢。

5.3 个人踩过的坑与应试技巧

最后分享几个我在实际准备和带人过程中反复遇到的经验，希望你绕着走：

第一个坑是审题粗心。笔试题目里经常有一句话决定整个题目方向，比如“完成订单”的“完成”二字、“用户数”是要去重还是不去重。我在模拟考中见过太多代码和SQL写得完全正确但白费功夫的case，就是因为在审题上抢了十几秒。

第二个坑是死磕难题浪费时间。笔试的题量决定了你不可能每道题都完美解答。我的策略是：碰到一道题三分钟内没有明确思路，立刻跳过做下一题，把所有题目第一遍扫完，再回来啃难题。这样至少保证基础题的分都拿到，而不是在某一道20分的题上耗到最后连送分题都没时间写。

第三个坑是不写注释和代码规范。笔试系统虽然机器判分，但部分题目面试官会调出你的代码回看。代码里变量命名随意、逻辑分支混乱，哪怕跑通了也会让面试官对你的代码素养打折扣。写代码时养成写注释、用有意义的变量名的习惯，这属于“隐形加分项”，但很重要。

第四个坑是忽略本地自测。很多笔试系统判分严苛，要求代码通过全部测试用例才算满分。我建议在提交前自己设计几个边界测试用例跑一遍，比如空字符串、数组只有一个元素、全重复字符等。别小看这个步骤，能帮你躲掉大量线上判分的扣分点。

第五个坑是心态上的“我不会”。我见过太多考生一看到业务场景题就懵，觉得没标准答案就不敢写。实际上这种题只要你按照框架写出一套有理有据的分析逻辑，哪怕不是最优解，也能拿大部分分数。你可以写得糙一点，但不能空白交卷。考场上的“完成比完美重要”这句话，在业务题面前体现得淋漓尽致。

回顾这场滴滴2018校园招聘网申笔试，它的考察范围和老套的“八股”考试不一样，所有知识点都能在未来实际工作中找到对应场景。数据挖掘工程师的笔试从来不是为了为难你，而是用最快的速度找到“最能直接上手解决问题”的人。理解了这一点，你再去复习的每一个公式、每一道算法题，都不会觉得是在做无用功。

我个人的体会是，笔试是最公平的一关：简历上的水分在代码面前无所遁形，但只要基本功够扎实，跨专业、没实习经历的人照样能高分通过。把上面这些考点按优先级消化掉，按节奏练习，你能拿下的远不止这一场笔试。