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

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

---

腾讯后端的面试，压强来得很快。

很多公司的节奏是：先聊项目，再问八股，最后来一道算法题。

腾讯不是。

这次整理到的一份真实面经里，一面上来就是 3 道算法题，限时 30 分钟。不是热身题，是真做题。做完之后，也没有立刻切到常规八股，而是继续往项目底层和基础原理上追。

二面更直接。

商品表、订单表、索引、事务、Redis 一致性、大表查询，一整轮几乎都在问业务场景。

所以如果要用一句话概括腾讯后端的面试风格，我觉得是：

先看你能不能在压力下把题写出来，再看你能不能把技术真正用到业务里。

这篇文章不讲空泛方法，直接把这次整理到的腾讯后端真实面经内容摆出来，再补一点简单解析。你看完之后，至少会知道腾讯后端到底会怎么问。

---

校招大礼包获取：入口

---

一面：3 道算法题，30 分钟

先看最核心的部分。

这是一场企业微信后端一面的真实题目，算法 3 题，限时 30 分钟：

1. LeetCode 198 打家劫舍
2. LeetCode 199 二叉树的右视图
3. 三个有序数组的交集

只看题面，其实不算特别偏。

真正难的是时间。

30 分钟做 3 道，平均每道题 10 分钟。你不只是要会，还得很快进入状态。中间只要有一道题卡壳，后面两道的节奏就会立刻乱掉。

1）LeetCode 198 打家劫舍

这是很经典的动态规划题。

题本身不难，关键是你能不能一眼反应过来状态转移：

• 偷当前这家，那前一家就不能偷
• 不偷当前这家，就继承前面的最优解

所以核心就是：

dp[i] = max(dp[i - 1], dp[i - 2] + nums[i])

简单解析：

腾讯把这题放在一面的前面，不是因为它有多难，而是因为它很适合看基本功。

你如果平时刷题只是“看懂了题解”，现场很容易卡在两个地方：

• 状态定义说不清
• 边界条件写不稳

比如数组长度是 1 或 2 怎么处理，滚动数组怎么优化，很多人平时觉得自己会，真到白板上就开始停顿。

这题面试官想看的不是炫技，而是你能不能快速把一个标准 DP 模型落成代码。

2）LeetCode 199 二叉树的右视图

这题常规解法有两种：

• BFS：层序遍历，每层取最后一个节点
• DFS：优先遍历右子树，每层第一次到达的节点记下来

简单解析：

这题很适合面试场景，因为它能顺手看出你好几个基本功：

• 二叉树遍历熟不熟
• BFS 和 DFS 会不会都讲
• 代码能不能写得干净

如果你用 BFS，面试官往往会看你对“按层处理”的模板熟不熟。

如果你用 DFS，面试官会看你是不是能自然地说出：为什么要先递归右子树，为什么每层第一次访问到的节点就是答案。

这类题的难点不在算法本身，而在表达。

你越是能把“为什么这样写”讲得自然，越像是真的刷透了，而不是临时背过一遍。

3）三个有序数组的交集

这题不是最常见的标准题，但很符合面试官的口味。

因为它会逼你在两种思路里选：

• 用哈希表做，写起来直接
• 利用“有序”这个条件，用多指针做，空间更省

简单解析：

这道题其实在看两件事。

第一，你会不会抓题目条件。

很多人看到“交集”两个字，就直接想到哈希。没错，但题目里给了“有序数组”这个信息，它不是白给的。说明面试官想看你能不能顺着条件往更优的方向想。

第二，你能不能处理好多指针题的边界。

三个数组一起走指针，代码不难，但一旦边界没处理好，或者某个指针更新逻辑写乱，很容易错。尤其在限时环境下，这类题非常考验手感。

---

一面不只考算法，还会追项目底层

这场一面里，算法之外还追问了不少内容：

• webpack 按需导入原理
• 编译器的词法 / 语法 / 语义分析
• LLVM IR 是树还是扁平结构

光看这几题，你会发现腾讯后端的追问范围挺宽。

它不是只盯着 Java 后端八股问，也不只是 Redis、MySQL、网络那一套。只要你的项目、实习、简历里沾上了某个点，面试官就可能顺着往下挖。

简单解析：

这类追问本质上是在判断：

你写在简历上的东西，到底是“做过”，还是“真的理解过”。

比如你项目里用过 webpack，面试官就不一定满足于“做过构建配置”。他会继续问你按需导入为什么能减少包体积，背后依赖什么机制。

如果你说自己了解编译原理，那他就会继续追词法分析、语法分析、语义分析各自做什么。

也就是说，腾讯一面虽然算法压得很紧，但不代表算法做完就轻松了。很多时候，真正把人问出汗的，是后面这些“你以为不会展开，结果越问越深”的追问。

---

二面：场景题开始接管整场面试

到了二面，风格会明显变。

这次整理到的是 CSIG 腾讯云后端的真实题目，几乎一整轮都围着业务场景打转：

1. 有两张表，商品表和订单表，查询时要考虑做些什么？
2. 商品类型字段适合做索引吗？
3. 数据库层面如何保证数据原子性？
4. 如果把订单表放 Redis 里，如何保证一致性？
5. 数据表非常大，查询时要做哪些考虑？

这类题最容易把人问懵。

因为它不是标准八股题。

你背过“索引是什么”“事务四大特性是什么”“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 月。