2023年秋招腾讯音乐研发岗笔试，我是在赛码网上完成的。整场下来最大的感受是：算法题占了绝对主导，题型不算偏，但时间紧、输入输出处理容易出意外，稍不注意就容易在环节上丢分。这篇文章就把我实际参加这场笔试的完整经历、题型拆解、赛码网环境下的做题技巧，以及几道接近原题的解题思路全部写出来，给准备投腾讯音乐以及其他大厂研发岗的同学一个真实参考。
先说结论：腾讯音乐研发岗笔试的核心考察点，本质上是三件事——数据结构和算法的基本功、边界条件的敏感度、以及在ACM模式下处理输入输出的熟练度。这和你在牛客上刷题用函数签名做题的习惯完全不同，赛码网要求你自己处理输入输出，不熟悉这套流程的人，第一题就可能卡住。
1. 先说题目：三个环节的顺序千万别颠倒
1.1 我拿到的试卷长什么样
腾讯音乐2023秋招研发岗笔试一共三大块：第一部分是20道选择题，涵盖C++/Java基础、数据结构、操作系统、网络和数据库；第二部分是2道算法编程题；第三部分是1道业务场景设计题。
整体时长120分钟。选择题占比不小，但真正拉分的是算法题。我估算了一下：如果选择题控制在40到45分钟内完成，剩下75分钟留给两道算法题和一道设计题，时间基本够用；要是选择题磨蹭了超过一个小时，后面就会非常被动。
题目难度跨度挺大。选择题里基础题偏多，比如“哈希表冲突解决方法”“TCP三次握手状态变化”“死锁的四个必要条件”这种，属于八股文里最基础的东西。但有几道题绕了弯子，比如问“vector扩容时元素移动次数的均摊复杂度”，需要你真正理解动态数组的扩容机制，而不是死记结论。
算法题两道，第一道是模拟题，给一个音乐播放列表的切换规则，让你计算最终停在哪个位置；第二道是动态规划，类似“最长有效括号”的变体，但套了一层会员成长体系的壳，核心还是DP状态转移。业务场景设计题给的是“如何为评论区设计一个高并发下的敏感词过滤方案”，不要求写代码，只要求写思路和架构设计。
1.2 为什么腾讯音乐要这样设计笔试
站在出题人的角度想，这三部分考察的目标其实是完全不同的。
选择题考的是基础知识的宽度。研发岗不是只写业务代码，系统底层机制、网络协议、操作系统调度这些基本功，决定了后续能不能快速上手复杂模块。腾讯音乐的业务场景里，客户端和服务器之间频繁交互，网络协议这块不扎实，后面排查线上问题会非常吃力。
算法题考的是编码能力的深度。两道题一模拟一DP，覆盖了研发岗日常最常用的两类思维：模拟题考察你把文字规则翻译成代码的能力，这个对应的是接需求、理解产品逻辑的日常；DP题考察状态抽象和转移方程的推导，这个对应的是遇到复杂问题能不能拆解成子问题。
设计题则是考系统思维。敏感词过滤在评论区场景下是必须的，出题人想看看你有没有基本的服务分层意识、缓存意识、以及方案取舍能力。
所以这三个环节不是随便堆上去的，它暗含了“基础扎实—编码过关—系统有设计”这条能力链路。如果你只准备了算法题库，而忽视了选择题里的基础知识和设计题的系统思路，成绩可能不会理想。
1.3 不同岗位的题目差异
腾讯音乐研发岗笔试不是一套卷子打天下。我身边一起笔试的朋友，投的是C++后台开发和Java后台开发，题目就有区别。C++卷里选择题涉及内存布局、虚函数表、智能指针引用计数的题目明显更多；Java卷则偏重JVM内存区域、垃圾回收算法、Spring Bean生命周期这些。
算法题两边倒是基本一致，至少我了解到的题面是相同难度级别。另外还有投客户端和前端方向的，他们也会考算法，但选择题侧重会偏向UI渲染、网络请求、跨端通信这些内容。
所以准备的时候别只盯着通用题库做，要先确认自己投的岗位方向，把对应语言的基础题多刷两遍。我当时吃了个小亏，选择题里有几道C++多继承和虚基类的问题，我是Java方向，题目是做对了，但花了不少时间在回忆语法细节上，耽误了整体节奏。
2. 赛码网这批报名平台：环境和不适应要提前适应
2.1 ACM模式到底是什么
腾讯音乐这场笔试用的是赛码网，不是力扣那种函数补全模式。赛码网的编程题是ACM模式：你自己读输入、自己解析、自己输出，所有的输入输出都得通过标准输入输出流来做，代码模板最多给你一个空的main函数。
很多同学第一次用赛码网，天然不适应。在力扣上写习惯了，函数的参数都是框架帮你解析好的，你要做的只是填函数体；到了赛码网，你得自己处理“输入第一行是整数n，第二行有n个整数”这种格式。别看这个差异不大，实际做起来非常影响心态。我用一个具体的例子说明：
你需要计算数组中连续子数组的最大和。力扣上你只需要写：
int maxSubArray(vector<int>& nums) { // 你的逻辑 }赛码网上你得自己写完整的输入输出：
#include <iostream> #include <vector> #include <sstream> using namespace std; int main() { int n; cin >> n; vector<int> nums(n); for (int i = 0; i < n; i++) { cin >> nums[i]; } int cur = 0, maxSum = INT_MIN; for (int num : nums) { cur = max(num, cur + num); maxSum = max(maxSum, cur); } cout << maxSum << endl; return 0; }就多了这几行读输入、写输出的代码，放在真实笔试的紧张环境下，很容易写错。比如cin读取遇到空格会截断、第一行有个换行符需要处理、多组测试用例时要用while(cin >> n)循环来读，这些细节不提前练，考场上就很伤。
2.2 赛码网的几个具体坑
赛码网的编辑器默认是不带语法高亮自动补全的。这个非常要命，因为在力扣或者本地IDE里写习惯了，突然换到裸编辑器，心态会受影响。但好消息是它支持你本地写、本地测，然后把代码贴回去。
我建议的策略是：考前用赛码网的模拟题库练两到三次，熟悉这个编辑器的手感。如果实在没有模拟题，就用本地IDE写代码，提交前留五分钟检查格式。另外有一个非常实用的技巧：赛码网的在线编译器对#include的处理比本地编译器严格，一些在本地能通过的代码贴上去可能编译报错，尤其是C++的万能头文件<bits/stdc++.h>，有的版本支持有的不支持，保险起见还是老老实实列具体的include头文件。
还有一点是关于cin和cout的性能问题。当输入规模超过十万级别时，cin/cout默认的同步机制会导致读取速度变慢，可能触发超时。我当时在第一道模拟题上就遇到过这个问题，数据量大约几十万，用cin读入没加优化，边读边处理勉强过了。如果是第二道DP题需要读入大量数据再做二维DP，不加这行代码很容易超时：
ios::sync_with_stdio(false); cin.tie(0);这两行放在main函数最前面，能有效提升读写效率。这是赛码网和牛客这类ACM模式笔试最实惠的经验之一。
2.3 选择题和设计题的答题体验
赛码网的选择题部分是可以往前翻的，建议遇到不确定的先标记，整体过完再回头思考。我当时做选择题的时候在两道操作系统题上犹豫了很久，一个是关于页面置换算法，一个是关于进程间的通信方式比较，后来发现后面算法题时间紧张，回头看那两道题也不过是2分一题，性价比很低，最后草草选了答案。
设计题的文字量比较大，赛码网上的作答区域是一个大文本框，支持简单的Markdown格式，但最好不要用太复杂的分级标题和表格，系统未必能正常展示。我当时写的是分点思路，用了编号列表和短段落，清晰就好。别在这个环节花大量时间堆砌华丽的文字，关键是逻辑框架清晰。
3. 算法题还原与解题思路拆解
3.1 第一题：播放列表模拟
题目大致意思是：有一个包含n首歌的循环播放列表，给你一个初始位置和一个操作序列，操作有“下一首”和“上一首”，另外还有“跳到指定位置”，最后问执行完所有操作后的歌曲位置。
这是典型的大模拟题。解题思路很直接：用一个变量cur记录当前位置，遇到next就是(cur+1)%n，遇到prev就是(cur-1+n)%n，遇到跳转就直接更新cur。唯一需要注意的是“上一首”操作在cur等于0时要特殊处理，不能出现负数取模。
我当时的写法：
#include <iostream> #include <string> using namespace std; int main() { ios::sync_with_stdio(false); cin.tie(0); int n, m, cur; cin >> n >> m >> cur; cur--; // 转成0-based string op; int pos; for (int i = 0; i < m; i++) { cin >> op; if (op == "next") { cur = (cur + 1) % n; } else if (op == "prev") { cur = (cur - 1 + n) % n; } else if (op == "jump") { cin >> pos; cur = (pos - 1 + n) % n; } } cout << cur + 1 << endl; return 0; }这道题本身不难，但有两个坑：第一个是把题目给的1-based位置和代码里的0-based下标搞混，导致越界或者错位；第二个是操作序列的第二行可能存在多组输入，如果你用的是固定读法而不是按行处理，容易读取错位。
3.2 第二题：会员成长值动态规划
第二题套了一个会员成长体系的计算规则：系统每天结算成长值，玩家可以累计连续签到获得额外加成，中断后会重新计算。要求给定一个长度为n的0/1数组，1代表当天签到了，0代表没签到，再给一个参数m表示连续签到的加成周期，求出最终累计的最大成长值。
这题核心是动态规划，但状态设计有一定技巧。如果只是计算总和，直接遍历一遍就行；但题目里的加成规则是“连续签到每满m天，则额外加一个基础成长值b”，所以你需要关注连续签到天数的状态。
我定义的DP状态是dp[i][j]，表示处理到第i天且当前连续签到天数为j时的最大成长值。j的范围是0到m-1，超过或等于m时统一按m处理。转移的时候分两种情况：第i天签到，则当前连续天数加1，成长值增加基础值a，如果连续天数达到m，额外加b；第i天没签到，则连续天数清零，成长值不变。
更简单的做法是压缩状态，只用一维数组加一个记录连续天数的变量，因为第i天的状态只依赖第i-1天的状态。但笔试时为了保险，我直接开了二维数组，确保转移不会出错，反正我看了下n的规模是10^5，二维数组10^5乘以m如果m很大，内存可能超限，所以这里m数据范围其实是10，也就是说dp是n*11的数组，可以接受。
状态转移的核心伪代码：
n, m, a, b = map(int, input().split()) days = list(map(int, input().split())) dp = [[0] * (m + 1) for _ in range(n + 1)] for i in range(1, n + 1): for j in range(0, m + 1): # 今天不签到 dp[i][0] = max(dp[i][0], dp[i-1][j]) # 今天签到 if days[i-1] == 1: new_j = min(j + 1, m) gain = a + (b if new_j == m else 0) dp[i][new_j] = max(dp[i][new_j], dp[i-1][j] + gain) print(max(dp[n]))这个状态转移的关键点是连续天数到m之后的处理：只要达到m就封顶保持，每满一次m就额外加b，但不需要把连续天数清零重计。这是题目里隐藏的逻辑，要仔细读题才能判断。我做题时在这个边界上迟疑了很久，后来通过自己构造的小样例验证后确认了逻辑是对的。
3.3 算法题的做题顺序建议
拿到算法题先别急着敲代码。花两三分钟把题读三遍，特别是输入输出格式和数据范围。数据范围决定了你的算法复杂度能不能过。比如上面第二题，如果n是10^5，m是10，用O(n*m)的DP是完全可以的；但如果m是10^9，那二维DP直接爆内存，就得换思路。
我自己的习惯是：先看一眼数据范围，再判断这题考的是模拟、DP、贪心、还是图论。如果五分钟没有思路，跳过做另一道。两道题都卡住了，就把想到的暴力解法写出来，能过多少用例算多少。赛码网的判题规则是部分用例通过也能得分，所以暴力解法绝对不是零分。
4. 考后的复盘与秋招笔试横向对比
4.1 腾讯音乐笔试和其他大厂的差异
2023年秋招我也陆续参加了其他几家互联网大厂的笔试，横向对比下来腾讯音乐的题目难度属于中等偏上，计算量和思维量都不算极端，但有两个特点是其他厂不太一样的。
一个是对基础知识的重视程度非常高。选择题占比20道，比很多厂子的10到15道多出不少。其他厂笔试经常只有算法题，偶尔加几道选择题意思一下，腾讯音乐这个选择题的量说明它确实看重基本功的广度。另一点是它的业务设计题出得比较具体，不是那种泛泛的“设计一个秒杀系统”，而是会结合音乐产品里的实际场景。这个特点对后续面试是个信号：面试官大概率会深挖项目经历和系统设计能力，笔试里的设计题就是一面预演。
拼多多、微众银行这些厂我也考过。拼多多的笔试更侧重算法，而且难度更大，题量也多，典型的高压筛选风格；微众银行的数据分析岗位则是SQL、统计学和业务分析题混搭，和我这次考的方向完全不同。所以不同公司、不同岗位的笔试风格差异很大，准备校招的时候不能拿一套方案去应付所有笔试，得针对每家公司的特点做调整。
4.2 复盘时我重新思考的两道关键题
选择题里有一道关于“哈希表在Java中的扩容机制”的题，我考场上选对了，但后来复盘时发现理解得不够深。Java的HashMap在负载因子超过0.75时会触发扩容，每次扩容是翻倍容量，然后把旧数据重新计算哈希位置放进去。这个过程不是简单的拷贝，而是每个元素都要重新定位，因为数组长度变了，hash & (n-1)的结果也会变。这个知识点结合“为什么容量是2的幂次方”一起理解会更深。
另一道是TCP的TIME_WAIT状态。题目问的是主动关闭方在TIME_WAIT状态持续多久，答案通常是2MSL。考后我仔细想了一下这题的考察意图：TIME_WAIT存在的意义是确保最后一个ACK能到达对方，如果丢了可以重发；同时防止旧连接上的延迟报文影响新连接。理解了这两个原因，就不容易和被动关闭方的状态搞混。
这种复盘比刷题本身更有价值。笔试不只是为了拿一个成绩，它暴露出来的知识点盲区，就是接下来几周准备面试的复习重点。我把自己错的和蒙的题都记到了单独的文件里，后续面试复习时直接翻这部分笔记，效率很高。
4.3 给下一届同学的建议清单
结合这次笔试和后续秋招的经验，我整理了一个简短的准备清单，希望能帮到准备投腾讯音乐研发岗的同学：
- 赛码网模拟题至少刷三套，重点练习输入输出处理和超时优化，别让环境问题拖后腿。
- 选择题覆盖范围明确：C++/Java基础、数据结构、操作系统、网络、数据库各占一定比例，按自己投的岗位取舍。
- 算法题高频类型是模拟、DP、贪心，字符串处理和二叉树也出现过。特别是模拟题，读题后先理清规则再写码，别边写边猜。
- 业务设计题要提前准备一套自己的分析框架：场景约束、核心流程、方案选型、容错降级、数据一致性。所有问题都往这个框架里套。
- 时间分配：选择题不超过45分钟，每道算法题留25到30分钟，设计题15分钟，最后留5分钟检查格式和提交。
5. 赛码网选择题的答题细节与冲刺方法
5.1 选择题不是单纯的知识点记忆
这次笔试的选择题里，有一部分不是只靠记忆能答对的。比如一道关于“数据库索引失效场景”的题，给的选项里有“对索引列使用函数”“隐式类型转换”“前导模糊匹配”“索引列参与计算”，你得对索引的B+树结构有基本理解，才知道为什么这些操作会破坏索引的有序性，从而放弃索引扫描。
所以准备选择题的时候，我是按照模块来整理的：C++/Java语言特性、数据结构、操作系统、计算机网络、数据库。每个模块先过一遍基础概念，然后刷对应模块的题库，遇到不会的题目，回看知识点再加深理解。说实话这个方法不新鲜，但很有效，关键是坚持。
还有一个实用技巧：多选题如果没有十足把握，只选一个最确定的选项，也比全选然后拿零分要强。这是我考场上反复权衡后总结出来的策略，虽然有些平台写的是“少选得部分分，多选不得分”，但也不一定所有平台都这样，需要提前看考试说明。
5.2 冲刺阶段的时间规划
如果是考前一个月开始准备，前两周用来过基础知识和刷分类题，后两周集中做整套模拟题。整套模拟的目的有两个：一是训练时间分配，二是适应长时间集中注意力的状态。笔试两个小时看似不长，但真正做起来，心理压力会加速消耗精力，不在考前适应这个节奏，考场上容易犯困。
我在考前一周把节奏调整为：每天上午9点到11点做一套模拟笔试，严格按照考试时间执行，闹钟一响就停笔，然后花一个小时复盘错题。这样到了真正笔试的那一天，身体和大脑已经形成了一套自动的运行模式，心态稳定很多，做题手感也是热的。
5.3 做题节奏的现场控制
笔试开始后，我建议先花两分钟把整张卷子扫一遍，特别是算法题的题面，先了解难度分布。如果发现第一道算法题完全没有思路，不要死磕，先去做第二道，把能拿的分拿到，再回头啃第一道。
选择题控制在45分钟以内，遇到模棱两可的先标记跳过，最后如果还有时间再回头思考。不过说实话，留到最后回看的选择题，大概率还是靠第一感觉选的答案。与其反复纠结，不如把时间留给算法题。
6. 业务设计题：评论区敏感词过滤方案
6.1 出题意图和答题框架
业务设计题给的是“如何为评论区设计一个高并发下的敏感词过滤方案”。这题没有标准答案，但有几个要点是面试官希望看到的：分布式服务的分层思想、敏感词匹配算法本身的选型、缓存和异步处理对性能的优化、以及发布和审核两条链路的设计。
我当时按这个结构写的：流量入口先经过网关和负载均衡，评论发布请求进入应用服务；应用服务先查本地缓存（Caffeine）里的敏感词列表，没有命中再查分布式缓存（Redis）；匹配算法用Trie树（字典树）+ AC自动机做多模式匹配；如果检测到敏感词，直接拦截或进入人工审核队列；最后通过消息队列异步通知审核系统。
最后加了一下降级方案：如果检测服务压测发现超时率升高，就关闭实时拦截、改为纯异步审核，优先保证用户能正常发评论，审核通过后再显示。这个“先保证可用性，暂缓一致性”的思路明显能引起面试官好感。
6.2 为什么先用Trie树和AC自动机
敏感词过滤的核心是字符串匹配。最简单的方法是维护一个敏感词列表，然后每次评论过来都遍历所有敏感词做子串匹配。如果敏感词数量有几千个，评论内容几百字，那每次匹配的时间复杂度就是几千乘以几百，高并发下肯定扛不住。
Trie树把所有敏感词塞进一个树形结构，匹配时从根节点顺着字符往下走，单次匹配的时间只跟评论长度有关，跟敏感词数量无关。这就是从“词数×文本长度”的复杂度降低到“文本长度”的复杂度。AC自动机更进一步，在Trie树上加了失配指针，让匹配过程可以一次扫描文本完成所有敏感词的查找，不需要回溯，性能进一步提升。
如果只用Trie树而不上AC自动机，在高并发场景下还是会有性能风险，因为最坏情况每个位置都需要重新从根节点匹配。AC自动机是Trie树的高并发形态，这两者必须配套讲，才能体现你对这个领域的理解深度。
6.3 设计题里容易丢分的点
设计题丢分常见的三个问题是：第一，只讲方案不讲为什么，直接说“用Redis缓存敏感词列表”但不说为什么不用本地缓存；第二，不考虑异常场景，比如审核服务挂了怎么保证评论数据不丢；第三，没有量化概念，不估算QPS、不评估缓存命中率，导致方案完全不可落地。
回答设计题时，一定要给出几个关键数字来佐证你的方案。比如“这个系统估算QPS在5000左右，敏感词列表大小约1MB，所有节点本地缓存可以完全容纳，命中率理论上可以做到95%以上，因此大部分请求可以走本地缓存，不会打到Redis”。这种描述比“用缓存提高性能”有说服力得多。
还有一点：设计题不要只写技术方案，要提一下上线后的监控指标。我当时写了“审核接口的TP99响应时间”“敏感词命中率”“拦截误判率”这三个指标。这种监控意识在面试官那里是加分项，说明你想的不只是“怎么实现”，还包括“上线后怎么判断系统是否正常”。
7. 笔试当天的状态管理与意外应对
7.1 提前的设备测试真的不能省
腾讯音乐这次笔试明确要求使用Chrome浏览器，并且需要提前半小时进入考试系统做设备检测。我在考前认真做了摄像头、麦克风、网络速度的测试，确认没问题才开始。这个步骤看起来繁琐，但非常重要。有一场其他公司的笔试，我认识的同学没提前测试，结果进去后摄像头无法开启，折腾了十分钟才解决，白白浪费了宝贵的答题时间。
另外，赛码网的系统对浏览器版本有要求，最好提前确认自己装的版本是官方支持的。如果有条件，准备一台备用电脑和备用网络，防止考试中途电脑死机或者断网。大厂笔试一般都有严格的在线监考规则，频繁切换窗口会被记录，所以切记不要开着其他聊天工具或者代码编辑器作弊，一旦被判违规成绩作废，后续再申述也基本没用。
7.2 做题中的心态控制技巧
笔试过程中遇到不会的题，最大的敌人是恐慌。2023年秋招我参加了多场笔试，一个很重要的经验是：不会做的题先把题目里能提取的信息记下来，哪怕只能写一个暴力的框架，也能拿部分分。不要直接放弃空着不写，赛码网判题是按通过用例数量给分的，空着等于零，写了至少还有机会。
当两道算法题都卡住的时候，去做设计题反而是调整心态的捷径。设计题没有标准答案，以你的知识储备能写多少就写多少，写完了心态会平稳很多，再回头做算法题可能就有了新的思路。这个“跳题缓冲”的策略帮我拿下了不止一场笔试的算法题分数。
7.3 考完必做的三件事
笔试提交后，第一件事是把能回忆起来的题目记录下来。不用写得很详细，记下题型、考点、关键边界条件即可。尤其是规定时间内没做出来的题目，一定要标记出来，因为这代表你的知识盲区。第二件事是当晚复盘选择题里的每一道错题，哪怕只是蒙对的选择题也值得重新看一遍知识点。第三件事是根据笔试暴露出的问题，调整后续复习计划，把投递其他公司之前的查漏补缺清单重新排一个优先级。
如果时间充裕，把腾讯音乐笔试这道设计题写一篇完整的设计文档保存下来。后续面试如果被问到类似场景，直接拿出来用。这个复盘的习惯可能比多做三套题更有价值。
我在整个秋招过程中一共参加了超过十场笔试，腾讯音乐这场是其中题型配置比较均衡的一场，选择题量足，算法题难度适中，设计题贴近业务。准备校招笔试时，与其盲目追求刷题数量，不如针对目标公司的笔试风格做专项训练。把赛码网环境踩熟、选择题模块吃透、算法高频题型练稳、设计题准备一套分析框架，这四件事做好，腾讯音乐的笔试就成功了一大半。
