秋招季刚过后台收到好几个学弟学妹的消息都在问腾讯音乐技术研究岗的笔试到底考什么、难度如何、该往哪个方向准备。我把今年第二批笔试的题目和复盘思路整理了一下结合我自己刷题和带人准备秋招的经验给后面备战的人一个参考。技术研究岗的笔试其实和纯开发岗笔试有区别它更看重算法底子和逻辑推导能力但又不完全是竞赛那种偏门套路整体风格务实和业务场景结合得比较紧。这套题适合正在准备大厂算法岗/研究岗笔试的人看尤其是目标放在音视频、推荐系统、搜索广告这类方向的同学。如果你是刚准备刷题的小白也能从里面看到大厂笔试对基本功的要求到底在什么水位线上。1. 整体考情与题目分布先说结论腾讯音乐秋招技术研究岗第二批笔试一共四道编程题限时两小时满分100分。从题目难度梯度来看前三题属于“只要认真准备过就能做出来”的范畴第四题开始拉开区分度。整体风格和LeetCode中等题比较接近但输入输出、边界条件、数据范围的坑比较多现场容易翻车。我当年做这类笔试的时候有一个感受——大厂的笔试不一定考多难的算法但一定考你在有限时间内把思路转化成代码、并且把边界条件处理干净的能力。四道题分布在数组、字符串、动态规划、图论这四个高频板块和往年题型基本一致。下面是这四道题的概况题号核心考点难度评级建议用时典型错误第一题数组操作 哈希计数简单15分钟忽略负数和重复元素第二题字符串 栈模拟中等偏易25分钟括号匹配边界处理第三题贪心 区间排序中等35分钟排序维度选错第四题树形DP / 最大独立集较难45分钟状态转移方程写错从实际反馈来看前两题是“送分题”但只要有一题没AC基本就和面试说再见了。建议时间分配上前两题控制在40分钟内第三题35分钟剩45分钟给最后一题。如果第四题没有思路优先保证第三题的满分不要恋战。1.1 技术研究岗笔试和开发岗的区别很多人会拿技术研究岗笔试和开发岗笔试做对比我多说两句。开发岗笔试会出现大量面向业务场景的题目比如设计一个秒杀系统、写一个服务端接口或者考察并发编程和数据库索引。但技术研究岗的笔试更纯粹——它几乎只考算法和数据结构原因在于研究岗的日常工作是模型优化、特征工程、系统性能调优这些岗位的核心能力本质上还是“快速理解问题、设计高效解法、用代码验证”这一链路。腾讯音乐的业务主要包括在线音乐播放、直播、K歌、短视频等所以算法团队实际工作中会大量涉及推荐系统、音频信号处理、内容理解这些方向。虽然笔试没有直接考察机器学习理论公式但算法题的底层逻辑——比如贪心、动态规划、图遍历——做推荐和做内容理解都离不开。笔试筛选的是“代码能力过关、后续能直接上手模型实验”的人。1.2 数据范围与输入输出陷阱这次笔试有一个非常明显的特征数据范围给得比较讲究不算是纯粹恶心人但如果你没有根据数据范围倒推算法复杂度很容易写出超时的解法。第一题数组长度到了10^5级别第二题字符串长度到了10^6第三题区间数量是10^5第四题节点数也是10^5。也就是说O(n^2)的解法在第二题和第三题基本必挂必须做到O(n)或O(n log n)。输入输出方面所有题目都是标准输入输出每一题的输入都有多组测试用例。这里有个很多人忽略的点部分题目要求“多组输入”如果不写 while 循环就会只处理第一组数据直接导致大面积 WA。我建议不管题目里有没有明确说多组测试只要在线笔试没有特殊说明都写成循环读取的形式这是一个很稳妥的习惯。2. 四道题逐题复盘这四道题我每一题都详细拆一下给出题目大意、解题思路、复杂度分析以及我认为最容易踩的坑。核心重点是第三题和第四题因为这两题才是真正拉开分数的地方。2.1 第一题数组元素统计与去重后排序这道题近似于“给定一个长度为n的整数数组输出出现次数最多的前k个元素如果出现次数相同则按元素大小升序输出”。第一眼看起来像是堆问题但注意数据范围n是10^5、k通常不超过100所以其实不需要用堆直接排序就足够。很多人第一反应就写大根堆反而把简单问题复杂化了。我的做法是先用哈希表统计每个数出现的次数然后把“元素-次数”的键值对转换成列表按次数降序、元素升序做一次排序取前k个。这里有一个值得注意的细节排序的Compare函数一定要同时写两个条件否则在“次数相同但元素大小不同”的用例上会翻车。我在实际写的时候会定义一个结构体数组重载小于号让排序逻辑在编译期就锁定。复杂度方面哈希统计是O(n)排序是O(m log m)m是不同元素的个数最坏情况下m也是10^5整体在可接受范围内。这道题还会顺带考察你对负数、0、重复元素这些边界数据的处理能力。我在测试的时候会额外加一组“所有元素都相同”和“数组只有一个元素”的用例这两种情况虽然简单但能直接检验代码的鲁棒性。事实上这道题放到LeetCode上就是347号题“前K个高频元素”的变体如果你刷过这道题基本属于白给。但依然有人会因为compare函数写错导致AC不了核心原因是对Comparator的执行顺序不够敏感。我见过不少同学把升序降序写反或者忘了处理次数相等的场景丢分非常可惜。2.2 第二题字符串压缩与栈展开第二题是“给定一个经过编码的字符串返回它解码后的字符串”。编码规则是“k[encoded_string]”其中方括号内的字符串会被重复k次。比如输入“3[a2[c]]”输出应该是“accaccacc”。题目数据范围是字符串长度最多10^6嵌套层数最多10^3这意味着递归解法可能爆栈需要用显式栈做迭代。这道题的核心是维护两个栈一个存数字重复次数一个存字符串当前层已经解析出来的部分。遇到数字就解析完整数字遇到左括号就把当前字符串和数字压栈、重置当前字符串遇到右括号就弹出数字和之前的字符串做拼接。难点在于处理多位数字、嵌套括号、以及边界情况例如“2[abc]”和“abc2[de]”这类混合结构。这里有一个关键优化字符串拼接不要直接用“”循环拼接因为在k很大的时候会产生大量临时对象。我习惯用StringBuilder或列表收集再用join方法一次性拼接能显著减少常数时间。这道题虽然看起来是字符串题但本质是栈模拟考的是对状态迁移的把握。我建议写完代码后一定要跑几个多层嵌套的用例例如“2[2[2[c]]]”和“10[a]”验证数字解析和栈的进出顺序是否对得上。这道题还有一个隐形考点为什么递归会挂字符串长度10^6加上嵌套深度10^3递归调用栈在Java里默认大小约1MB每层栈帧占用几十字节1000层可能就已经接近上限在C里虽然好一些但同样不是最佳方案。所以面试官在后续面试中可能会追问“递归能不能优化成迭代”这题本质上也是在考察你对递归栈帧成本的理解。2.3 第三题会议室与区间排序的贪心变体这道题的描述类似“给定一组区间每个区间代表一个任务的开始和结束时间求最少需要多少个资源才能让所有任务不冲突”其实就是一个经典的重叠区间最大数问题。数据范围是区间数量10^5、开始时间和结束时间都很大所以不能用时间轴上的差分数组必须用排序后扫描的思路。解法是构造一个由“开始时间1”和“结束时间-1”组成的事件列表按时间排序逐个累加过程中的最大值就是答案。这里有一个非常经典的坑同一个时间点上如果一个任务结束、另一个任务开始到底算不算冲突在这个问题描述下结束和开始如果完全同一时刻通常不算资源冲突所以排序时“结束时间”应该排在“开始时间”之前也就是时间相同先处理“-1”再处理“1”。很多人在这里排序维度不对直接导致结果偏大。另一种等价做法是先按开始时间排序所有区间再用最小堆维护当前正在进行的任务的结束时间。每次遇到新区间先弹出所有已经结束的任务再压入当前任务堆的大小峰值就是最少资源数。两种做法复杂度都是O(n log n)但事件排序法常数更小代码也更简洁。我个人更推荐事件法因为它在处理边界条件时更直观。这道题考察的贪心思想在腾讯音乐的业务场景里很常见——比如推荐系统的资源调度、GPU显存分配、离线任务排队都需要通过区间规划来最大化资源利用率。它表面上是算法题但背后是对“全局最优解由局部最优组合而来”这个贪心思维的检验。准备这类题时我建议把LeetCode上“合并区间”“插入区间”“会议室”系列都刷一遍因为出题人总是喜欢在这几个题之间做排列组合。2.4 第四题树上的最大权独立集第四题是压轴题描述是“给定一棵n个节点的树每个节点有一个权值选择若干个节点使得任意两个被选中的节点之间没有边直接相连求选出来的节点权值之和最大值”。这个就是最大权独立集在树上的版本解法是树形DP。状态定义很直接dp[u][0]表示不选节点u时以u为根的子树能获得的最大权值dp[u][1]表示选节点u时以u为根的子树能获得的最大权值。转移方程dp[u][0] sum(max(dp[v][0], dp[v][1]))v是u的子节点dp[u][1] weight[u] sum(dp[v][0])最终答案是max(dp[root][0], dp[root][1])。难点首先在于建树——输入给的是无向边需要先做一次DFS确定父子关系或者直接在DFS时带上父节点参数防止走回头路。然后是递归深度问题n是10^5如果树是一条链递归深度会达到10^5在Python或Java里几乎必爆栈。解决方案有两个一是用sys.setrecursionlimit提高限制但治标不治本二是用栈模拟后序遍历迭代完成DP。在C里递归通常不会炸但也会影响性能。这道题实际上也考验“反向建图”的能力。很多人会直接按照输入顺序把边保存成一个邻接表但在树形DP中需要知道子树方向所以每次DFS都判断当前节点是不是父节点。我建议创建邻接表时用vector 在DFS函数里额外传一个parent参数防止走回父节点这比维护 visited 数组更简洁。从难度梯度来看第四题能AC的人很可能不到20%。但不要因为难就放弃能把基础的状态转移写出来即使有些边界处理不够完美也能拿部分分数。在线笔试很多题是“有部分分”的尤其是这种带有明确子结构的题目即使只跑对了一部分测试点也比交白卷强得多。3. 备考时间线与知识储备针对腾讯音乐这种技术研究岗笔试我给准备秋招的同学一个比较务实的备考规划。不要相信“裸考碰运气”这种话大厂笔试考察的面太固定了完全可以靠针对性训练覆盖。3.1 三个月备考周期的阶段划分第一个月打基础把LeetCode Hot 100里数组、哈希表、字符串、栈、队列、二叉树这些基础题目刷两遍。这一阶段的目标不是刷题量而是熟悉每种数据结构的典型操作和常见题型变形。比如数组的滑动窗口、哈希表的计数排序、栈的匹配问题这些都是腾讯音乐笔试的高频考点。第二个月专题强化按“双指针”“贪心”“动态规划”“图论”四个专题集中刷题。动态规划这块建议从线性DP开始再到背包、区间DP、树形DP。腾讯音乐笔试的第四题就是树形DP如果只刷了线性DP遇到树上问题会很懵。所以树形DP这个专题千万不能跳过至少要练10道以上的题把“选/不选”“父节点/子节点”这种状态定义思路吃透。第三个月模拟实战严格按两小时四道题的标准做模拟笔试题目来源可以是LeetCode周赛、牛客网的企业真题或者自己组合高频题。每场模拟后一定要复盘不光是看哪些题没AC更要分析是思路问题、代码实现问题还是边界处理问题。我见过很多同学算法思路想得很快但写代码时频频出错这类人通常是在模拟实战阶段写得不够多。3.2 笔试前一周的快速回顾清单考前一周不要再大量刷新题了重点应该放在“高频模板代码”的默写上。我列一个清单如果你能把这些代码在10分钟内无差错默写出来笔试基本稳了二分查找的闭区间和开区间两种写法并查集的路径压缩和按秩合并拓扑排序的Kahn算法和DFS实现树形DP的基础模板包括建图和DFS转移滑动窗口的通用框架窗口收缩条件前缀和与差分数组的构造单调栈求下一个更大元素排序的Compare函数写法包括多关键字排序这些模板代码要练到肌肉记忆的程度因为笔试现场心态会有波动如果连模板都要现想时间会非常紧张。我在做腾讯音乐笔试之前把所有模板写在了一个Markdown文件里考前一周每天默写一遍考场上遇到相似题型直接套框架节省了大量思考时间。3.3 针对腾讯音乐业务方向的针对性准备虽然笔试不会直接考推荐系统或音频算法但我建议在准备笔试的同时对腾讯音乐的业务方向做一些了解因为笔试通过后紧接着就是面试面试里大概率会结合业务问算法题。比如推荐系统中常用的协同过滤、矩阵分解、多臂老虎机音频方向常见的MFCC特征提取、语音活动检测这些如果你在笔试复盘阶段提前了解后面面试会轻松很多。我在笔试复盘的时候会把每道算法题和可能的业务场景联系起来。比如区间调度那道题我就联系到推荐系统里的“实时拍卖广告位分配”和“视频转码任务排优先级”树上最大独立集就联想到社交网络中的“最大互不关注用户集合”这类问题。这种延伸思考不一定笔试用得上但能让你在面试聊项目时更有底气。4. 实战中的常见问题与排查技巧很多同学笔试挂掉不是因为题不会做而是栽在一些看起来很蠢的细节上。我总结了自己刷题和帮别人复盘时遇到的典型问题按出现的频率排个序希望你能提前避坑。4.1 多组输入的循环读取问题笔试题如果没说“只有一组测试”一定要习惯性地写成循环读取。有些同学在本地IDE测试的时候只测了一组数据交上去发现跑出来的结果不对就是因为没有处理多组输入。如果是Java用while (in.hasNext())包住主逻辑如果是Python用while True配合try-except处理EOFC就是while (cin n)。这个习惯一定要养成否则可能会直接丢掉一整道题的分数。4.2 数据溢出和取模问题第一题和第三题的数值范围虽然不算大但有的同学在计算区间1/-1差值时如果数组下标直接使用时间戳本身很容易越界。正确做法是把时间戳离散化或者像第三题那样用事件列表而不是时间轴数组。另外如果题目要求输出对10^97取模一定记得在每次加法后都取模不要只在最后取一次。中途溢出在C和Java里不会报错只会给你一个巨大的错误答案排查起来很费劲。这个坑我在第四题的树形DP里也给不少人排过权值累加很容易超出int范围记得用long long或long类型。4.3 栈模拟的“状态遗忘”第二题字符串展开最容易犯的错误是“出栈后忘记把之前的结果接回去”。比如处理完嵌套的一层后当前字符串是“acc”但栈里存的“a”和数字3应该被拼成“a 3*acc”很多人会直接赋值导致外层内容丢失。我建议在写这道题时先把运行过程用纸笔画一遍明确每一步当前字符串和栈的状态再动代码。对于嵌套类问题纸上模拟永远比直接写代码高效。4.4 递归爆栈的替代方案第四题树形DP如果遇到一条链表状的树递归深度会高达10^5在绝大多数编程语言里都会爆栈。一个实用的替代方案是“迭代后序遍历”先做一次DFS把节点按照后序顺序收集到一个列表里然后倒序遍历这个列表依次计算每个节点的dp值因为后序列表保证“子节点一定在父节点前面”倒序访问时子树的dp值已经算好了这个方法本质上就是用一个显式栈模拟递归但完全避免了系统调用栈深度限制。配合邻接表和parent参数代码也不复杂。如果你平时习惯写递归建议在笔试前专门练几道“递归转迭代”的题防止现场遇到深树时手足无措。4.5 时间分配与心理建设最后说一个很多人忽略的点笔试现场的时间分配和心理状态。两小时四道题如果你在前两题就卡了超过50分钟后面基本就没戏了。我的策略是拿到题先通读一遍所有四道题快速判断难度然后按“容易到难”的顺序做。遇到一道题15分钟没思路果断跳过做完了后面的再回头想。有时候你做完第三题回头再看第四题思路反而会更清晰。心理上要有一个预期技术研究岗的笔试最后一题本来就很难不是冲着让大家AC出的而是为了筛选“在难题面前有没有思路、敢不敢动手”的人。你能写出状态转移方程哪怕代码有小bug也比空着强。我见过不少同学因为第四题没AC就心态崩了结果前面简单的题也因为慌乱改了错误答案这才是最可惜的。5. 从笔试到面试的衔接建议笔试只是第一关通过之后还有面试而面试一定会围绕笔试中暴露出来的薄弱点进行追问。我建议每做完一套笔试都要给自己做一个“弱点画像”。比如第四题没做出来那就要确认到底是树形DP的状态定义不会还是会了但不会建树或者是代码实现的时候没处理好int溢出。把这个定位清楚了后面的复习才有针对性。腾讯音乐技术研究岗的面试通常会考一两道算法题同时根据你的简历深挖项目。笔试里的算法题和面试算法题高度重叠尤其喜欢考动态规划、字符串、树的遍历。如果笔试时是参考别人的思路才AC的面试前一定要重新独立做一遍确保“裸写”也能过。面试官很容易通过追问判断你是不是真的理解了这题而不是背了模板。针对腾讯音乐的业务方向我建议面试前专门了解一下“推荐系统召回-排序-重排”的链路、语音相关的基本概念、版权音乐的内容理解等话题。不用研究得很深但至少能说出一些关键术语和大致流程。我身边有认识的人因为对“音频特征提取”有一定了解在面试中讲到项目时明显更占优势。技术研究岗不只要求算法能力强还要能证明你对业务场景有基本认知。我个人在实际操作中的体会是笔试准备最忌讳“只刷题不复盘”。每道题AC之后花10分钟想一下“这题换一个问法还能怎么出”比盲目刷三道新题更有价值。把同一类题目的变体串起来思考你才能在笔试现场那种高压力环境下快速迁移思路。比如第二题栈模拟和第三题事件排序本质上都在考“状态随时间的迁移”理解了这个底层逻辑无论题目包装成什么样都能看穿。最后再分享一个小技巧笔试前一天的晚上不要再看难题了把常用的模板代码和典型题的思路快速过一遍然后早点休息。技术研究岗笔试的硬实力在平时的积累临考前能调整好状态比熬夜多刷几道题重要得多。祝后面参加腾讯音乐秋招的同学都能顺利通过笔试也欢迎大家笔试后一起交流复盘。