先说一句可能有点得罪人的话很多人把秋招笔试当成“数据结构期末考试的互联网版”背题型、刷脸熟但真正到滴滴这种量级的笔试里拉开差距的往往不是那道最难的题而是你对时间、边界条件和输入输出的掌控力。尤其是2024年秋招整体投递量大、笔试场次密我做滴滴研发岗这套卷子的时候最直观的感受是题目本身并不偏怪但它考查的方式非常“生产环境”——你以为在考算法其实它在模拟一个真实业务里拆解问题、快速落地的全过程。这篇文章就围绕我实际参加的“2024年秋招-滴滴-研发岗笔试”展开从题型分布、高频考点、典型题解到考场的时间分配策略把整套卷子的底层逻辑拆开聊一聊。无论你准备的是网约车、数科还是地图相关的研发岗位这套思路都能复用。1. 2024年秋招滴滴研发岗笔试整体印象与核心情报1.1 这场笔试的三个关键词算法、工程感、反套路我当时是在牛客网完成的在线笔试整个流程走下来发现滴滴这套题的风格可以总结成三个词。第一个词是“算法”。这是研发岗笔试永恒的主旋律滴滴也不例外。整套卷子的核心区分度全部压在两道编程大题上而且难度呈阶梯状一道是绝大多数刷刷题就能做出来的中档题另一道则是需要结合业务场景做建模优化的综合题。选择题部分则覆盖了数据结构、操作系统、网络、数据库等基础八股但占比不算太大。第二个词是“工程感”。这是我个人觉得滴滴笔试区别于很多纯刷题厂的地方。它的题目描述经常带着业务包装比如调度、路径、订单分配、运力预测之类的背景需要你先剥离业务外壳、抽象出数据模型再动手写代码。这其实是一个非常典型的“需求分析→抽象建模→编码实现”链路也是研发岗日常工作中的核心能力。第三个词是“反套路”。网上流传的所谓“滴滴题库”其实意义不大。笔试反套路的地方在于它会把一些经典题型包装成你一眼认不出来的样子。比如一道看起来像图论最短路的题实际解法可能是滑动窗口一道看似是区间合并的题真正的考察点却是差分数组。如果你只会按标签刷题遇到这种“换皮题”很容易被带到沟里去。1.2 笔试基本信息与核心数据先把大家最关心的硬信息列出来都是我当时亲测的实际安排不同批次可能有微调但大体框架是一致的项目具体情况笔试平台牛客网在线笔试系统考试时长120分钟部分批次可能为90分钟以邮件通知为准题型构成单选题 不定项选择 2道编程题部分批次可能有3道编程题语言C / Java / Python 均可牛客默认支持编程题模式ACM模式需自行处理输入输出监控方式摄像头监控 屏幕录制部分场次有切屏限制整体题量不算大但时间并不宽裕。120分钟看着多实际分配下来选择题控制在30到40分钟剩下80到90分钟全部给编程题才算一个比较健康的时间预算。1.3 这套题适合谁来参考如果你是以下几类人这篇文章的参考价值最大2025届及之后准备投递滴滴研发岗的在校生直接了解笔试风格和备考方向。准备其他互联网大厂研发岗但还没做过“业务包装型”算法题的人滴滴这套题的风格在行业内很有代表性值得一练。刷了很多题但一到ACM模式就手足无措的人这篇文章会专门讲输入输出的处理和调试技巧这部分恰恰是很多刷题党的盲区。2. 题型构成与分值分布为什么选择题反而不能丢2.1 选择题部分覆盖面广但深度有限拿到的这套卷子选择题大约有20道题型包括单选题和不定项选择题。考点范围很常规基本就是计算机基础四大件的排列组合数据结构栈与队列的特性对比、二叉树遍历序列的还原、哈希冲突的解决方法、堆的调整过程。操作系统进程与线程的区别、死锁产生的四个必要条件、虚拟内存与页面置换算法、进程调度策略。计算机网络TCP三次握手与四次挥手的状态变迁、TCP与UDP的区别、HTTP与HTTPS的差异、DNS解析流程。数据库SQL语法基础、索引失效的场景、事务的ACID特性、隔离级别与对应的问题。语言基础Python可变对象与不可变对象的区别、C虚函数机制、Java的HashMap底层实现等取决于你选的主语言。我印象比较深的一道题是给定一棵二叉树的前序遍历和中序遍历序列要求还原后序遍历序列。这类题非常经典但不定项选择的形式增加了一点迷惑性它会给你多个选项其中有一些是“看似正确但遍历顺序差一步”的干扰项。复习的时候如果只是“看过”而没有真正动手推导过几遍考场上很容易选错。2.2 分值分布选择题决定下限编程题决定上限从分值占比来看编程题是绝对的大头每道编程题的分值往往是一道选择题的好几倍。但我想强调的是选择题虽然单个分值不高却是决定你能不能进面试的“基本盘”。原因很简单编程题大家都会做一部分除非你是那种轻松AK的大佬否则大多数人的编程题得分是拉不开绝对差距的。这时候20道选择题的正确率就成了排名的关键因素。我个人建议是选择题不能有“放弃”的念头遇到不会的标记一下先跳过最后再回来蒙但绝不能空着不做。2.3 材料题/附加题的应对思路滴滴的笔试偶尔还会附带一道“材料阅读题”给你一段关于某个业务场景的描述然后提出几个与业务逻辑相关的问题。这类题的目的不是考察你对该业务有多熟悉而是考察你在信息不完整的情况下能不能条理清晰地拆解问题表达自己的分析思路。我在做这类题时的心法是先定义问题边界再给出解决路径。比如描述一个“高峰期司机接单率下降”的问题不要上来就写“调价”而是先拆解可能的原因运力供给不足订单分发效率低司机端体验差再针对每个原因给出一个可落地的方案和对应的验证指标。这种结构化表达的能力比正确答案本身更重要。3. 编程题的高频考点拆解从业务包装里识别真实模型3.1 第一类高频题调度与贪心滴滴的业务基因决定了它的笔试题目里很容易出现“调度”这个主题。典型的表现形式是给定一批任务或订单每个任务有开始时间、结束时间或优先级要求在某种约束下优化一个目标值比如最大化完成数量、最小化总等待时间。这里要说一个非常重要的判断技巧只要题目里出现“最多能完成多少”“最少需要多少时间”这类字眼第一反应应该是排序加贪心而不是动态规划。很多同学一上来就套DP把状态定义搞得极其复杂结果发现排序之后用优先队列一个扫描就搞定了。以一道典型的“司机接单”题为例题面大概是有n个订单每个订单有发布时间和截止时间完成每个订单需要1个单位时间问最多能完成多少个订单。这个题的本质就是经典的任务调度问题。核心解法是import heapq def max_orders(orders): # orders: list of (start_time, deadline) orders.sort(keylambda x: x[1]) # 按截止时间排序 pq [] current_time 0 for start, deadline in orders: if current_time start: current_time start heapq.heappush(pq, deadline) if current_time deadline: heapq.heappop(pq) return len(pq)这种代码量并不大核心考点是你能否识别出“按截止时间排序 最小堆维护已选任务”这个经典模型。如果你之前只刷过纯LeetCode风格的题目第一次遇到这种带业务包装的题很容易在题意理解上浪费时间。3.2 第二类高频题路径与图论作为一家出行平台滴滴的笔试出现图论题几乎是必然的。最常考的是最短路径算法但它的考法通常不会直接给你一张邻接矩阵让你写Dijkstra而是把图藏在题目描述里。比如给你一个城市的地铁线路和行驶时间问从A站到B站的最短时间再比如给你一组依赖关系表示某任务的前置任务问完成所有任务的最短时间这种本质是拓扑排序加关键路径。做这类题有一个关键提醒用Dijkstra还是SPFA、用邻接表还是邻接矩阵这些不是考点真正的考点是状态设计。滴滴的图论题经常在“状态”上做文章比如“允许最多k次免费换乘”“经过某些节点需要额外的时间”这时候普通的单源最短路就不够用了需要把“剩余免费次数”或“累积额外时间”也作为状态的一部分。我当时遇到的一道题就需要拆点建图。我给出的建议是在图论题的调试上千万不要只盯着代码看画一张小图手动推一遍比任何静态检查都高效。很多状态转移的错误用草稿纸走一遍就能暴露。3.3 第三类高频题滑动窗口与前缀和数组类的题目在滴滴笔试里通常是保底送分题但也有可能成为拉开差距的关键。它有两种常见的变化第一种是“连续子数组”类问题。比如给定一个数组求满足某种条件和等于target、所有元素不重复、最大长度等的连续子数组数量。这类题的标准解法就是滑动窗口加哈希表。第二种是“区间修改与查询”类问题。比如给定一个数组和多次区间加操作最后输出整个数组。这类题如果老老实实模拟复杂度很容易超时正确思路是差分数组把区间操作降成O(1)最后做一次前缀和还原。3.4 高频考点全景表考点方向常见包装方式核心解法复杂度要求调度/贪心订单完成、任务安排、会议室预订排序 优先队列/最小堆O(n log n)路径/图论地铁换乘、配送路径、任务依赖Dijkstra 状态扩展 / 拓扑排序O((VE) log V)连续子数组订单金额区间、时间段计数滑动窗口 哈希表O(n)区间操作价格调整、批量更新差分数组 前缀和O(n m)字符串处理号码匹配、文本清洗双指针 / 状态机O(n)动态规划收益最大化、路径计数线性DP / 背包 / 区间DPO(n^2) 以内这个表格基本对应了滴滴笔试编程题的出题池。把它们练熟不敢说稳过但至少不会出现“看到题目完全不知道从哪下手”的情况。4. 实战复盘两道典型的编程大题从读题到AC的完整过程4.1 真题还原出租车订单调度优化这道题我印象非常深因为它是典型的“业务包装型”题目。题面大概意思是某个区域内有一批出租车和一批订单每辆出租车有一个接驾位置和一个当前位置每笔订单有一个起点和终点需要你为每笔订单分配一辆车使得所有订单的平均接驾时间最短或者使得总接驾时间最小。说实话刚看到这个题的时候我的第一反应是“这是什么运筹学题”但细看约束条件就能发现题目其实做了大量简化每辆车在同一时间最多只能接一个订单且接驾时间等于两点之间的曼哈顿距离。这就变成了一个很经典的“最小匹配”问题。但这里还有一个关键的坑数据范围。如果n和m都在10的3次方左右那么直接用KM算法或者最小费用最大流都会超时。这时候题目通常会有一个隐藏的提示——比如“每辆车的接驾位置在一条直线上”——意味着曼哈顿距离可以简化为一维距离从而把最短路匹配变为排序后直接计算。我当时的解题思路是读题后先画图把出租车和订单在坐标轴上标出来。观察约束发现是一维坐标上的匹配问题。把出租车位置和订单位置分别排序贪心地按顺序匹配最小距离。如果你在考场上遇到类似“二维坐标”的题目千万不要慌先想想能不能降维。很多题目设计时都预留了这种降低难度的口子就看你能不能发现。4.2 真题还原带状态限制的最短路径这道题的题面明显带有滴滴地图业务的影子给定一个交通网络每个路口可能拥堵通过时间较长有些路口有充电桩/停车场你开一辆续航有限的车需要判断是否能从起点到达终点并输出最短时间。本质上这是一个带状态的最短路问题。普通的最短路状态是“到达某个节点”这里的状态要扩展成“到达某个节点且剩余电量还有多少”。最直观的做法是把状态定义成二维的dist[node][battery]然后跑Dijkstra每个状态向外扩展时考虑两种动作行驶到相邻节点消耗电量或充电增加电量但花费时间。这里有两个我在实际写代码时踩过的坑值得单独说一说。第一个坑是充电逻辑的松弛条件。充电并不是“加上固定电量”这么简单而是“以某个功率充多久”如果写状态转移时不注意“充到恰好满足需求”这个细节很容易在循环里出不来。我当时处理的办法是把充电动作拆成“单位时间充电增加单位电量”的dijkstra扩展虽然状态数变多了但逻辑清晰不容易错。第二个坑是剪枝。二维状态的Dijkstra在数据范围比较大时不做剪枝一定会超时。我的经验是每次从优先队列里弹出状态时判断一下当前电量是否小于已知最优解中的最小剩余电量如果是就直接跳过另一个好用的剪枝是如果某个节点之前已经以更高的电量被访问过那么当前这个更低电量、更高耗时的状态一定不是最优的直接跳过。我把这道题的简化版写出来作为参考完整的处理逻辑大概是这样import heapq def shortest_time(n, edges, charge_time, battery_capacity, start, end): graph [[] for _ in range(n)] for u, v, w in edges: graph[u].append((v, w)) graph[v].append((u, w)) INF float(inf) dist [[INF] * (battery_capacity 1) for _ in range(n)] dist[start][battery_capacity] 0 pq [(0, battery_capacity, start)] while pq: time, battery, node heapq.heappop(pq) if time dist[node][battery]: continue if node end: return time # 动作一充电单位电量 if battery battery_capacity: nt time charge_time[node] if nt dist[node][battery 1]: dist[node][battery 1] nt heapq.heappush(pq, (nt, battery 1, node)) # 动作二行驶到邻居 for nxt, cost in graph[node]: if battery cost: nt time cost nb battery - cost if nt dist[nxt][nb]: dist[nxt][nb] nt heapq.heappush(pq, (nt, nb, nxt)) return -1这段代码的时间复杂度是O((V * C E * C) log(V * C))其中C是电池容量。笔试中如果数据范围给得不大这种写法是能稳稳AC的。4.3 从真题看滴滴的出题偏好把上面两道真题放在一起你能很明显地看到滴滴研发岗笔试的出题取向不是考你多高深的算法技巧而是考你在有业务背景的题目里能不能快速提取数据模型用最合适的经典算法去解决它。这类题不会像竞赛题那样在数学上设巨坑但会刻意把题目条件藏在业务描述里比如“曼哈顿距离”“同一时刻只能服务一笔订单”“充电需要时间”等等。这时候就需要耐心读题把每个条件映射到算法模型的约束上。我习惯在读题时拿笔在草稿纸上把约束条件全部列出来每个约束对应一个变量或者一个数组这个习惯帮我在考场上省了很多回头重读题的时间。5. 考场实战时间分配、做题顺序与ACM模式的调试技巧5.1 时间分配不要死在第一题在牛客网做笔试有一个很大的坑很多人习惯从第一道选择题开始按顺序做结果选择题耗时太多等到编程题的时候时间已经不够了。实际上选择题的分值密度远低于编程题如果一道选择题卡了3分钟以上就应该先标记然后往后走。我个人的时间分配方案是时间段任务说明前5分钟通读全部题目不答题只看每道题的类型和难度决定做题顺序第5-40分钟选择题每道题不超过1-2分钟不会的先跳过全部做完再回来第40-75分钟第一道编程题选最顺的做稳拿一题AC第75-110分钟第二道编程题尽量拿部分分暴力解法能写就写最后10分钟检查与补漏检查输入输出格式、选择题标记项5.2 ACM模式的输入输出处理滴滴笔试采用ACM模式也就是你需要自己处理输入输出这和LeetCode那种已经帮你封装好函数、只需要填空的核心代码模式完全不同。很多刷题量不小但一直在LeetCode上做题的同学第一次上牛客笔试会非常不适应。我总结了一套应对ACM模式的模板每次笔试前都默写一遍import sys def solve(): data sys.stdin.read().strip().split() # 按需解析数据 idx 0 n int(data[idx]); idx 1 m int(data[idx]); idx 1 arr [] for _ in range(n): arr.append(int(data[idx])); idx 1 # ... 业务逻辑 ... print(result) if __name__ __main__: solve()这个模板的好处是统一用sys.stdin.read()读入全部数据然后用索引逐一解析既不会因为input()读不到空行而报错也方便处理多行数据。另外记得在提交前把所有的临时测试代码删掉只保留核心逻辑否则很容易因为输出多余内容判WAWrong Answer。5.3 本地调试与在线提交的差异牛客的在线编译器在笔试时不支持断点调试所以本地IDE才是主战场。我的习惯是先本地写好代码用题目给的样例测一遍再自己构造几组边界数据测试最后再粘贴到牛客的代码框。很多人忽略了一个细节本地Python和期末考试环境里的Python版本可能不一致。如果你用了dict的合并操作|这种Python 3.9才引入的语法而考试环境是Python 3.8就会直接语法报错。保险起见笔试代码尽量用最基础的语法来写不要追求花哨的写法。5.4 部分分策略暴力解不是丢人的事说一个很多人容易钻牛角尖的点不要试图每道题都会做。研发岗笔试的编程题通常是按测试点给分的。你哪怕是用暴力解法通过了30%的测试点也能拿到不小的分数。所以在考场上如果一道动态规划题短时间内想不出递推式那就直接写一个能处理小数据的暴力搜索把该拿的分拿到。我见过太多同学在一道题上死磕了40分钟最后超时、没做出来还导致后面那道简单题也没时间写。笔试不是考试竞赛分数最大化才是唯一目标。6. 备考节奏与刷题策略考前一个月我做了什么6.1 按“模型”刷题而不是按“标签”刷题很多人准备大厂笔试时喜欢按LeetCode的题目标签刷题——每天刷几道“数组”、几道“字符串”、几道“动态规划”。但经历过滴滴这套笔试我有一个更深的体会按“算法模型”分类刷题效率远高于按“数据结构标签”分类。比如“滑动窗口”“前缀和”“差分数组”“单调栈”这四类模型从数据结构标签上看它们都算“数组”类但它们的解题套路完全不同。如果你只知道一个宽泛的“数组类问题”概念到了考场上根本不知道该用哪种模型去套。我备考时整理了一份模型清单每个模型对应1-2道必刷题滑动窗口找最长不重复子串、子数组最大平均数前缀和连续子数组和等于K的次数差分数组航班预订统计单调栈接雨水、每日温度Dijkstra网络延迟时间、带状态的最短路拓扑排序课程表、任务调度贪心堆会议室II、IPO区间DP最长回文子串、戳气球每个模型练熟2-3道相关题目理解其核心套路比盲目刷200道题在笔试中更能保证下限。6.2 时间规划三轮复习法我的考前复习节奏大致是三轮供参考第一轮考前3-4周全面覆盖高频模型。每天上午做2-3道算法题下午复习计算机基础八股晚上整理错题和模型笔记。第二轮考前2周开始刷牛客网的真题模拟。这一阶段的关键是适应ACM模式和限时节奏。建议每周至少完整模考3套题目模考时严格遵守时间限制不要“想不出来就翻题解”。第三轮考前3-5天回归笔记和错题本。不再刷新题而是把整理出来的高频模型过一遍重点看自己容易犯的边界条件错误以及每个模型的时间复杂度分析。6.3 笔试后的复盘价值比分数更重要的东西最后聊一个很多人会忽略的点笔试结束后的复盘价值远比那封“进入下一轮”的邮件更大。每次笔试结束后我都会把没AC的题重新拿出来尝试不看题解在48小时内做出满分解法并写一篇简短的思路总结。这些题目会成为我在面试里展示“问题解决能力”的最佳素材。面试官问“你最近做过什么有挑战的项目”时与其讲一个实习里的边角料需求不如讲一道你在笔试中卡了2小时、后来通过拆解状态、优化复杂度才AC的算法题——这个叙事更有说服力也更能体现你的技术深度。尤其滴滴这种业务和技术结合度很高的公司面试官大概率会顺着你笔试中涉及的调度、路径、匹配等话题往下问。这时候你把笔试题当成一个“微项目”来复盘在面试里就能形成降维打击。这比多刷50道题带来的收益要大得多。