腾讯后端开发面经：一面 3 道算法压 30 分钟，二面开始全是场景题

腾讯后端开发面经一面 3 道算法压 30 分钟二面开始全是场景题腾讯后端的面试压强来得很快。很多公司的节奏是先聊项目再问八股最后来一道算法题。腾讯不是。这次整理到的一份真实面经里一面上来就是 3 道算法题限时 30 分钟。不是热身题是真做题。做完之后也没有立刻切到常规八股而是继续往项目底层和基础原理上追。二面更直接。商品表、订单表、索引、事务、Redis 一致性、大表查询一整轮几乎都在问业务场景。所以如果要用一句话概括腾讯后端的面试风格我觉得是先看你能不能在压力下把题写出来再看你能不能把技术真正用到业务里。这篇文章不讲空泛方法直接把这次整理到的腾讯后端真实面经内容摆出来再补一点简单解析。你看完之后至少会知道腾讯后端到底会怎么问。校招大礼包获取入口一面3 道算法题30 分钟先看最核心的部分。这是一场企业微信后端一面的真实题目算法 3 题限时 30 分钟LeetCode 198 打家劫舍LeetCode 199 二叉树的右视图三个有序数组的交集只看题面其实不算特别偏。真正难的是时间。30 分钟做 3 道平均每道题 10 分钟。你不只是要会还得很快进入状态。中间只要有一道题卡壳后面两道的节奏就会立刻乱掉。1LeetCode 198 打家劫舍这是很经典的动态规划题。题本身不难关键是你能不能一眼反应过来状态转移偷当前这家那前一家就不能偷不偷当前这家就继承前面的最优解所以核心就是dp[i] max(dp[i - 1], dp[i - 2] nums[i])简单解析腾讯把这题放在一面的前面不是因为它有多难而是因为它很适合看基本功。你如果平时刷题只是“看懂了题解”现场很容易卡在两个地方状态定义说不清边界条件写不稳比如数组长度是 1 或 2 怎么处理滚动数组怎么优化很多人平时觉得自己会真到白板上就开始停顿。这题面试官想看的不是炫技而是你能不能快速把一个标准 DP 模型落成代码。2LeetCode 199 二叉树的右视图这题常规解法有两种BFS层序遍历每层取最后一个节点DFS优先遍历右子树每层第一次到达的节点记下来简单解析这题很适合面试场景因为它能顺手看出你好几个基本功二叉树遍历熟不熟BFS 和 DFS 会不会都讲代码能不能写得干净如果你用 BFS面试官往往会看你对“按层处理”的模板熟不熟。如果你用 DFS面试官会看你是不是能自然地说出为什么要先递归右子树为什么每层第一次访问到的节点就是答案。这类题的难点不在算法本身而在表达。你越是能把“为什么这样写”讲得自然越像是真的刷透了而不是临时背过一遍。3三个有序数组的交集这题不是最常见的标准题但很符合面试官的口味。因为它会逼你在两种思路里选用哈希表做写起来直接利用“有序”这个条件用多指针做空间更省简单解析这道题其实在看两件事。第一你会不会抓题目条件。很多人看到“交集”两个字就直接想到哈希。没错但题目里给了“有序数组”这个信息它不是白给的。说明面试官想看你能不能顺着条件往更优的方向想。第二你能不能处理好多指针题的边界。三个数组一起走指针代码不难但一旦边界没处理好或者某个指针更新逻辑写乱很容易错。尤其在限时环境下这类题非常考验手感。一面不只考算法还会追项目底层这场一面里算法之外还追问了不少内容webpack 按需导入原理编译器的词法 / 语法 / 语义分析LLVM IR 是树还是扁平结构光看这几题你会发现腾讯后端的追问范围挺宽。它不是只盯着 Java 后端八股问也不只是 Redis、MySQL、网络那一套。只要你的项目、实习、简历里沾上了某个点面试官就可能顺着往下挖。简单解析这类追问本质上是在判断你写在简历上的东西到底是“做过”还是“真的理解过”。比如你项目里用过 webpack面试官就不一定满足于“做过构建配置”。他会继续问你按需导入为什么能减少包体积背后依赖什么机制。如果你说自己了解编译原理那他就会继续追词法分析、语法分析、语义分析各自做什么。也就是说腾讯一面虽然算法压得很紧但不代表算法做完就轻松了。很多时候真正把人问出汗的是后面这些“你以为不会展开结果越问越深”的追问。二面场景题开始接管整场面试到了二面风格会明显变。这次整理到的是 CSIG 腾讯云后端的真实题目几乎一整轮都围着业务场景打转有两张表商品表和订单表查询时要考虑做些什么商品类型字段适合做索引吗数据库层面如何保证数据原子性如果把订单表放 Redis 里如何保证一致性数据表非常大查询时要做哪些考虑这类题最容易把人问懵。因为它不是标准八股题。你背过“索引是什么”“事务四大特性是什么”“Redis 和 MySQL 要保证一致性”都没用。面试官要的不是定义是你能不能把这些东西放进一个真实业务里讲出一套像样的思路。下面逐个看。1商品表 订单表查询时要考虑什么这道题看起来很宽其实是典型的数据库场景题入口。你不能上来就只说“建索引”。因为面试官很可能马上追问具体查什么字段是按商品查订单还是按订单反查商品是否有分页返回字段多不多数据量大概多大查询频率高不高简单解析这类题回答时最好按顺序来先明确查询目标再看关联字段和 where 条件再考虑索引设计最后补性能优化和缓存策略比如商品表和订单表 join通常会涉及商品 id、订单状态、创建时间、用户 id 这些字段。那你就要想到join 字段要不要建索引条件字段能不能走联合索引返回字段是否可以只取必要列是否要避免深分页这道题真正考的不是你知不知道“索引”两个字而是你有没有基本的查询优化思路。2商品类型字段适合做索引吗这题非常像腾讯会问的风格。因为标准答案不是“适合”或者“不适合”而是“看情况”。简单解析商品类型这种字段很多时候区分度不高。比如只有十几种、几十种类型但表里有几百万条数据。那你单独给这个字段建索引效果往往不一定好。因为筛出来的数据还是太多回表成本不低优化器甚至可能直接放弃索引。所以这题回答时重点不是表态而是把判断依据说出来字段的区分度高不高查询是不是经常带这个条件是单列查询还是和其他字段组合查询能不能设计成联合索引如果你能顺带说到“低区分度字段单独建索引收益有限但放进联合索引里可能有价值”这个回答就会比单纯说“适合”或“不适合”好很多。3数据库层面如何保证数据原子性这题表面上很像八股。很多人会条件反射答事务。没错但只答“事务保证原子性”通常不够。简单解析面试官更想听到的是原子性靠事务边界来保证出现异常时要能回滚底层依赖日志和回滚机制来实现如果只停在“ACID 里的 A 是原子性”这个回答太薄了。腾讯这类场景题的特点就是定义你可以说但一定要继续往下落。比如你可以接着讲一组 SQL 要么都成功要么都失败如果中间某一步异常要通过回滚恢复到执行前的状态真正落地时还要注意事务不要开太大不然锁持有时间长反而影响并发这就比只说一句“事务能保证原子性”更像在做项目而不是在背书。4如果把订单表放 Redis 里如何保证一致性这道题很经典。也是很多后端候选人最容易从“会背”答成“不会用”的题。简单解析你一旦听到这题脑子里至少要先有三个判断Redis 到底是主存储还是缓存MySQL 和 Redis 哪个是真正的数据源更新流程里谁先改谁后删失败了怎么办正常的回答方向通常会把数据库当作最终数据源Redis 更多承担缓存角色。然后再围绕双写一致性展开比如先更新数据库再删除缓存必要时做延迟双删如果业务复杂可以借助异步消息或日志机制做补偿这题最忌讳的回答是上来一句“加锁就行”。锁不是不能说但锁只是手段不是答案本身。面试官更关心的是你有没有先把数据流转关系讲清楚。5数据表非常大查询时要做哪些考虑这题其实是上面几道题的升级版。一旦表大起来很多平时“能用”的方案就不够用了。简单解析这里至少可以往几个方向展开索引是否合理查询字段能不能收缩分页方式是否会导致深分页问题历史数据要不要归档热数据和冷数据是否要拆开单表是否已经到了需要分库分表的规模如果你回答里能自然带到“覆盖索引”“避免select *”“按时间或业务维度拆分数据”会比较加分。因为这说明你不是在机械背诵“数据量大就分表”而是知道查询性能问题是一步一步冒出来的。二面里还补了两道算法编辑距离和 LRU除了上面这些场景题这次面经里二面还出现了两道算法编辑距离LRU 实现这两个放在腾讯后端面试里其实很有代表性。编辑距离这是动态规划里的经典题。它比打家劫舍再绕一层因为你要先把状态定义清楚dp[i][j]表示前i个字符转换到前j个字符的最少操作数。然后再去考虑三种操作插入删除替换简单解析这题很适合考“你会不会把 DP 讲完整”。因为如果你只是刷过题大概率记得“这是 DP”。但现场一旦让你解释初始化为什么这么设转移为什么是这三个分支很多人就开始乱。腾讯拿这题来问不只是看你会不会写更看你能不能把思路讲顺。LRU 实现这题在腾讯后端里很高频这次面经里也出现了。标准思路就是哈希表负责 O(1) 查找双向链表负责 O(1) 插入、删除、移动简单解析面试官一般会重点看两个点第一你能不能把结构写对。尤其是节点删除、移动到头部、淘汰尾节点这些操作很多人平时觉得自己会现场一写就开始指针打架。第二你能不能解释为什么必须是“双向链表”。因为单向链表删除中间节点不方便时间复杂度下不来。所以 LRU 这题不是“写出来就结束”而是你最好能顺手把设计理由也讲清楚。看完这套题至少要记住 4 件事1. 一面先看稳定输出3 道算法题压在 30 分钟里本质上是在看你能不能稳住。不是让你秀多复杂的思路。是基础题和中等题摆在面前时你能不能快速进入状态把代码写完整。2. 简历上的技术点很可能都会被追问webpack、编译原理、操作系统这些追问说明腾讯不会只满足于“你说自己做过”。只要简历里写了面试官就可能顺着往下挖。3. 二面不认只会背定义的人商品表、订单表、索引、事务、缓存一致性、大表查询这些题都不是让你背定义。它们更像工作里会遇到的问题。4. 真正容易卡住的是题型切换一面像做题。二面像上班。很多人不是单点不会而是刚从算法状态切出来下一秒又被拉去讲数据库和缓存一致性节奏一下就乱了。最后这次整理完腾讯后端面经我最大的感受是腾讯后端不是单点难。它难在切换快。一面先用算法把节奏拉满。你刚把三道题做完后面马上又切到项目底层。二面再把你拉进真实业务场景里看你能不能把索引、事务、Redis 一致性这些东西真正讲落地。所以它给人的体感才会很强。不是某一道题特别变态。是整场面试几乎不给你喘气。如果你最近也在准备腾讯后端希望这篇文章至少能帮你先建立一个基本预期它会怎么问。它为什么这么问。你最容易卡在哪。知道这些再准备心里会稳很多。数据说明本文内容整理自公开可查的腾讯后端校招 / 实习面经记录结合已有题目资料汇总信息整理时间截至 2026 年 3 月。