腾讯音乐娱乐集团2023校园招聘技术类岗位的编程题合集这个话题在当年秋招季确实让不少人犯难。我花了很长时间把收集到的笔试回忆题、牛客网讨论帖和身边同学的实战反馈整理到一起又按题型重新做了分类和拆解。这篇文章就当作一份“二手资料整理个人复盘”把我认为值得重点准备的算法方向、解题模板、笔试现场的坑都摊开聊一聊。无论你是准备投后台开发、客户端开发还是算法岗看完之后应该都能对这场笔试的备考思路有一个更清楚的认识。我先把结论放在前面腾讯音乐2023校招技术岗的编程题并没有大家想象中那么偏、那么怪。绝大部分题目都落在常规算法和数据结构范围里重点考察的是编码熟练度、边界条件处理和复杂度分析能力。真正拉开差距的不是谁见过更多“奇葩题”而是谁能在有限时间内把一道中等难度题写得又快又稳。1. 腾讯音乐2023校招编程题先摸清出题套路1.1 题型分布和岗位差异从我整理到的信息来看2023届腾讯音乐的在线笔试主要有两类形态一类是纯编程题一般3到5道需要在规定时间内全部AC另一类是“选择题编程题”组合选择题覆盖操作系统、网络、数据库、计网基础编程题则独立计时。不同岗位之间编程题的难度和侧重点会有一些差别。岗位方向编程题数量典型侧重点后台开发3~4道字符串处理、数据结构设计、动态规划客户端开发3道左右数组、链表、递归、简单图论算法岗4~5道动态规划、二分、滑动窗口、数学建模前端开发2~3道场景模拟、字符串处理、基础算法后台开发几乎必考“设计题”比如LRU缓存、带过期时间的KV结构、TopK问题这类题重在考察你对数据结构组合使用的熟练度。算法岗则更偏好动态规划和二分答案经常把业务场景包装进去比如音乐推荐、用户活跃区间统计。客户端开发岗相对友好一些但链表和二叉树相关题目出现频率不低现场手写时容易在指针和递归边界上翻车。1.2 为什么技术岗笔试绕不开算法题很多人会问我进去之后主要写业务代码为什么笔试非要考算法这个问题我当年也想不通。后来自己参与过一些面试流程才慢慢理解。在线笔试在技术招聘里承担的核心作用不是“选天才”而是“低成本筛掉代码基础不过关的候选人”。一道编程题能在半小时内反映出的信息其实非常多你拿到题目后能不能快速建模能不能把思路转化成代码边界条件想得全不全复杂度分析是否到位代码风格是否干净。这些能力不是靠临时背题能补上的而是长期训练积累的结果。腾讯音乐这种体量的公司每年收到的简历量非常大笔试环节必须有一套统一、可量化、抗作弊的筛选标准。算法编程题刚好满足这些需求所以它才会被反复使用。另外音乐娱乐业务本身也有大量算法场景。比如歌单推荐需要处理用户行为序列直播业务需要实时计算热度榜搜索功能需要处理文本相关性。这些业务场景背后的基础能力归根结底就是数据结构、算法和系统设计。笔试里考编程题其实是在提前模拟你将来要面对的真实问题。1.3 语言选型和环境准备我见过不少同学在笔试前纠结到底用C还是Java其实完全没有必要。腾讯音乐在线笔试平台对主流语言都支持你只需要选择自己最熟的那门。我自己主用Python因为写起来快、不需要管指针和内存释放在笔试这种时间紧张的环境里优势非常明显。当然Python也有一些坑比如递归深度限制、运行速度偏慢遇到大数据量的题目需要谨慎。如果你选择C建议把STL常用容器再熟练一遍尤其是vector、map、unordered_map、set、priority_queue。笔试时不需要你背源码但一定要清楚每个容器的底层结构、时间复杂度和适用场景。比如map底层是红黑树插入和查询都是O(log n)priority_queue默认是大顶堆自定义比较函数时要注意写法。还有一点容易被忽略提前熟悉平台的自测功能和输入输出格式。有些平台要求你处理标准输入有些则直接给你一个函数签名让你实现函数即可。这两种模式差别很大。主攻ACM模式的人如果遇到核心代码模式可能会在main函数上浪费不少时间反过来只练LeetCode的人也可能在scanf和getline上栽跟头。建议考前两种模式都练一遍至少各做十道题形成肌肉记忆。2. 高频题型拆解从字符串到动态规划2.1 字符串模拟与栈笔试中的“送分题”字符串类题目在腾讯音乐2023校招笔试里出现频率非常高但大多不难属于“保分题”。常见变形包括括号匹配、版本号比较、字符串解码、去除重复字符、反转字符串中的单词。这类题只要逻辑清晰基本都能AC。问题在于很多人一看题目简单就放松警惕结果在边界条件上扣分。举个例子字符串解码的经典描述是给定一个编码字符串3[a2[c]]返回解码后的字符串accaccacc。很多人的第一反应是递归处理但如果你用栈来做思路会更直白遍历字符遇到数字就解析完整数字遇到[就把当前字符串和数字入栈遇到]就弹出栈顶并重复拼接。需要注意数字可能不止一位字符串内部可能嵌套多层这些都要在代码里覆盖到。还有一类题是“字符串匹配”的简化版本比如判断两个字符串是否为同源异构词。这种题目最直接的解法是用哈希表统计字符频率再用一个计数器记录差异数量。实际笔试时不要一上来就写KMP先想清楚题目范围和数据规模。如果字符串长度在10^5以内用哈希表通常是足够高效的。KMP虽然经典但除非题目明确要求匹配子串并返回位置否则没有必要给自己增加无谓的复杂度。栈结构在笔试里的定位很明确它擅长处理有“最近相关性”的问题。比如括号匹配、表达式求值、单调栈求下一个更大元素。复习的时候不用把栈的底层实现背得很细但一定要把“什么时候用栈、什么时候用队列”的判断逻辑内化。简单说先进入的元素后处理就用栈先进入的元素先处理就用队列。2.2 链表和树画图是解题的捷径链表题在在线笔试中看起来很吓人实际上套路非常固定。无非是反转链表、合并两个有序链表、寻找链表中点、判断链表是否有环、删除倒数第N个节点。这些题在LeetCode上都有原题刷熟之后笔试基本就是默写。我个人的建议是链表相关的题目一定要养成画图的习惯。尤其是涉及指针交换、节点删除时不画图纯靠脑子想特别容易把 next 指针搞乱。我自己就吃过亏有一次写“反转链表II”只反转指定区间代码写了四十行跑测试用例时发现中间两个节点顺序不对。后来在草稿纸上重新画了一遍指针指向才发现漏了一个 prev 的更新。笔试虽然时间紧张但画图花掉的三十秒绝对能帮你省下五分钟的调试时间。树的问题比链表更灵活但高频考点也就那么几个二叉树的前中后序遍历、层序遍历、最大深度、最近公共祖先、路径总和。腾讯音乐的技术岗笔试里树的题目一般不会出太难最常出现的是“层序遍历”的变体比如按层输出、之字形遍历、统计每一层的平均值。写树相关的递归代码时有一个经验非常有用先定义清楚递归函数的语义再写代码。比如“求二叉树最大深度”这个题递归函数的语义就是“以当前节点为根的子树最大深度”。一旦语义清楚代码自然就是max(leftDepth, rightDepth) 1。不要把递归想得太玄它只是把大问题拆成同构的小问题递归出口想清楚剩下的就是数学归纳法。2.3 动态规划与贪心状态定义比代码更重要动态规划是2023届腾讯音乐笔试的绝对重点几乎每个方向都会考。但很多同学对动态规划的第一反应是“公式记不住”这其实是理解方式不对。我见过太多人刷题时先看题解把状态转移方程抄下来然后感觉自己会了。结果一到笔试换个题目背景就不知道状态该怎么定。动态规划的核心永远只有两步第一步是定义好状态第二步是写出状态转移方程。定义状态时要问自己“当前这个子问题需要哪些信息才能唯一确定”。以最长递增子序列为例状态dp[i]表示“以第 i 个元素结尾的最长递增子序列长度”为什么这样定义因为递增子序列的最后一个元素决定了能不能继续往后面接。如果你从“前 i 个元素的最长递增子序列”这个角度去想反而不容易写对转移。贪心算法在笔试中更多以“区间问题”出现比如会议室安排、区间合并、无重叠区间。区间合并几乎是必考题目后面我会专门用一道完整题目演示。贪心的证明通常不是笔试的重点笔试更看重你能不能快速判断“这题应该用贪心”并给出正确排序方式。一个比较实用的判断经验是如果题目要求最大化数量或价值而且每一步选择不影响后续全局状态大概率是贪心否则就要回到动态规划。2.4 二分、滑动窗口与哈希表优化手段要熟练除了上述题目腾讯音乐笔试里还经常出现一些“基础题型”的进阶版本需要你灵活运用二分、滑动窗口和哈希表来优化。这类题目真正难的不是算法本身而是你能不能识别出“这道题可以套用哪个优化模板”。二分查找的题往往是“最小化最大值”或者“最大化最小值”比如在 D 天内送达包裹的能力、分割数组的最大值。代码模板要背熟但更重要的是理解为什么二分答案可行。很多这类问题都满足单调性如果某个值 X 可行那么比 X 更大或更小的值也可行。只要发现这个单调性就能用二分把“求最优解”转化成“判断可行性”复杂度通常从 O(n^2) 降到 O(n log n)。滑动窗口则主要应对子数组或子串问题尤其是涉及“连续”关键词的题目。比如无重复字符的最长子串、最小覆盖子串、长度最小的子数组。滑动窗口模板的核心是维护左右两个指针右指针负责扩展窗口左指针负责收缩窗口同时用一个哈希表或计数器维护窗口内状态。写代码时最容易出问题的是收缩条件判断经常会出现多收缩一次或少收缩一次的情况。我习惯在每次移动左指针之后立刻更新答案这样不容易漏解。哈希表与其说是一种算法不如说是一种空间换时间的思想。笔试中几乎所有需要O(1)查询的地方都会用到哈希表比如两数之和、字母异位词分组、最长连续序列。需要提醒的是Python里的 dict 和 set 平均复杂度是O(1)但最坏情况下可能退化到O(n)笔试数据一般不会针对这个攻击所以不用过度担心。3. 一套可以直接复现的编程题实操流程3.1 读题两分钟想清楚要输出什么笔试看题也是有技巧的。我看到不少同学键盘敲得飞快结果写了二十分钟后发现题目理解错了只能推翻重来非常浪费时间。我的习惯是拿到题目先不急着写代码先用一到两分钟把题目里的输入、输出、数据范围、边界条件圈出来。具体来说第一遍读题只解决三个问题输入是什么类型输出是什么类型有没有特殊要求。比如“如果数组为空返回0”这种条件题目里往往写在不起眼的位置但恰恰是测试用例的扣分点。第二遍读题就要开始构思算法了。看数据范围是最实用的判断依据。如果 n 在 10^5 量级那么 O(n^2) 大概率超时你需要往 O(n) 或 O(n log n) 的方向想如果 n 在 500 以内可以考虑动态规划或 Floyd 这类 O(n^3) 的算法如果 n 小于等于 20基本上是状态压缩或者暴力搜索的标准范围。很多人容易忽略一个事实在线笔试平台对内存和时间的限制通常比大家想象中严格。尤其在使用 Python 时如果递归深度很大记得设置sys.setrecursionlimit()否则会莫名其妙地栈溢出。另外频繁地在循环里创建列表或字典也会带来不必要的性能损耗。能提前把变量定义好在循环外就尽量提前定义。3.2 经典题完整演练合并播放区间为了让大家更好地理解完整的做题流程我这边模拟了一道和音乐业务相关的笔试题给定多个歌曲的播放时间区间[start, end]其中 start 和 end 都是整数且 start end。现在需要把有重叠的播放区间合并返回合并后的区间列表并按 start 从小到大排序。输入格式为二维数组[[1,3],[2,6],[8,10],[15,18]]输出格式为[[1,6],[8,10],[15,18]]。这道题的本质是“合并区间”面试中出现率极高。先考虑一下如果自己不写代码解题思路是什么先把所有区间按左端点排序然后遍历所有区间维护当前合并区间的左右端点。如果下一个区间的左端点小于等于当前合并区间的右端点说明有重叠更新右端点如果没有重叠就把当前合并区间加入结果并切换成新的区间。这样做的正确性依据是按左端点排序之后所有可能重叠的区间必然在顺序上相邻不需要回头去看更早的区间。这是一个典型的贪心思路。3.3 从伪代码到ACPython实现和测试用例按照上面的思路Python 代码可以写成这样def merge_intervals(intervals): if not intervals: return [] intervals.sort(keylambda x: x[0]) merged [] cur_start, cur_end intervals[0] for start, end in intervals[1:]: if start cur_end: cur_end max(cur_end, end) else: merged.append([cur_start, cur_end]) cur_start, cur_end start, end merged.append([cur_start, cur_end]) return merged print(merge_intervals([[1,3],[2,6],[8,10],[15,18]])) # 输出: [[1,6],[8,10],[15,18]]这段代码有几个细节值得说明。第一intervals.sort(keylambda x: x[0])是必须的不排序整个合并逻辑就不成立。第二在遇到重叠区间时右端点要取max(cur_end, end)而不是直接赋值为end。比如[1,5]和[2,7]合并后应该是[1,7]如果直接用end就可能出错。第三循环结束后不要忘了把最后一个合并区间加入结果。写完代码后不要直接点提交。先自己构造几个测试用例在本地跑一遍。我会习惯性检查这些情况空输入[]答案应为[]只有一个区间[[1,2]]答案应为[[1,2]]完全重叠[[1,5],[2,3]]答案应为[[1,5]]相邻但不重叠[[1,2],[2,3]]题目如果允许end start不计重叠则答案应保持原样完全覆盖[[1,10],[2,3]]答案应为[[1,10]]这些边界测试用例基本就是笔试平台隐藏用例的常见套路。跑一轮发现问题就立刻修比提交之后被扣分要划算得多。3.4 更高阶的变形支持缓存淘汰的LRU结构在合并区间之外“数据结构设计”类题目同样是腾讯音乐2023校招笔试的热门。最典型的就是LRU缓存Least Recently Used Cache。这类题不像纯算法题那样有固定解法它考的是你对哈希表和双向链表两个结构的理解深度。LRU缓存要求实现两个操作get(key)和put(key, value)并且要求 get 和 put 的时间复杂度都是 O(1)。哈希表能实现 O(1) 查询但无法维护“最近使用”的顺序双向链表能维护顺序但纯粹的链表查询是 O(n)。两者结合才是正解哈希表负责 O(1) 定位节点双向链表负责记录访问顺序。每次 get 或 put 都把对应节点移动到链表头部当容量满了就删除链表尾部的节点。这个题我在笔试前专门练过三遍因为它的细节非常多。首次写的时候很容易出现“删除链表节点后没有同步删除哈希表键”的问题或者“节点移动到头部时没有更新头尾指针”。我的经验是先画一张结构图左边一个哈希表右边一个双向链表再看每一步操作会影响到哪几个指针。把图弄清楚了代码就是照着图写。class DLinkedNode: def __init__(self, key0, value0): self.key key self.value value self.prev None self.next None class LRUCache: def __init__(self, capacity): self.capacity capacity self.cache {} self.head DLinkedNode() self.tail DLinkedNode() self.head.next self.tail self.tail.prev self.head def get(self, key): if key not in self.cache: return -1 node self.cache[key] self._move_to_head(node) return node.value def put(self, key, value): if key in self.cache: node self.cache[key] node.value value self._move_to_head(node) else: node DLinkedNode(key, value) self.cache[key] node self._add_to_head(node) if len(self.cache) self.capacity: removed self._pop_tail() del self.cache[removed.key] def _add_to_head(self, node): node.prev self.head node.next self.head.next self.head.next.prev node self.head.next node def _remove_node(self, node): node.prev.next node.next node.next.prev node.prev def _move_to_head(self, node): self._remove_node(node) self._add_to_head(node) def _pop_tail(self): node self.tail.prev self._remove_node(node) return node这个题目考察的算法并不多但它非常考验工程实现能力。如果你能在15分钟内无Bug写出LRU缓存笔试的“设计题”基本就稳了一半。4. 笔试中的常见问题与避坑实录4.1 边界条件空输入、单元素和整数溢出笔试扣分最冤的不是不会做而是没考虑边界。空输入、单元素输入、负数输入、重复元素输入这四类用例我每次都会提醒自己检查。很多题目的主体逻辑没问题但一到空数组就抛异常直接导致运行时错误。整数溢出主要发生在C和Java中。比如链表两数相加、大数相减这类问题如果直接用int接收很可能会溢出。解决方案也很简单要么改用long long或long要么用字符串模拟数字运算。Python 因为整数没有位数限制这个问题相对不明显但仍要注意大数乘除时的性能。边界条件的另一个隐藏坑是数组下标。比如二分查找中left mid 1和right mid - 1如果写错可能导致死循环或越界。我的习惯是所有涉及下标加减的地方都在草稿纸上手动模拟一遍长度为1和长度为2的数组确保循环能正常退出。4.2 时间复杂度和内存为什么“能跑”和“能过”是两回事有些同学本地跑小数据量样例时能通过一提交就超时就是因为时间复杂度太高。在线笔试平台通常会给到 10^5 或者 10^6 规模的数据此时 O(n^2) 的代码基本必挂。遇到这类情况不要急着优化常数先整体把复杂度降一级。我通常按照这个顺序自查第一看循环嵌套层数第二看每次循环内部是否有 O(n) 的查找第三看是否大量使用字符串拼接。Python 里字符串是不可变对象循环里反复拼接会产生大量新对象性能很差。正确做法是把片段存到列表里最后再.join()。内存方面不要总想着把数据都存下来。有些题目看着需要二维数组但实际上用滚动数组就能把空间从 O(m x n) 降到 O(n)。动态规划里最常见的优化就是状态压缩笔试时遇到空间超限先看看当前状态是否只依赖上一层的值。4.3 在线笔试平台的使用细节在线笔试平台和本地IDE差别很大我见过太多人死在平台操作上。第一确认自己的代码是在“核心代码模式”还是“ACM模式”。牛客、赛码和一些企业自研平台都有区别。核心代码模式只需要你实现一个函数输入参数已经给好ACM模式需要你自己从stdin读取输入并按照格式打印输出。如果不确定先看题目描述里有没有给出函数签名或者看示例代码的模板。第二学会用平台自带的自测样例。写完代码后先跑一遍题目给的示例再跑自己构造的边界用例。如果平台支持在线调试尽量利用起来。不要因为紧张就直接提交那样你会浪费宝贵的提交次数。第三注意平台禁用的某些功能比如system(pause)不要出现在代码里C的using namespace std没问题但尽量不要用一些容易引起歧义的宏定义。还有一点代码中不要包含文件读写操作在线评测系统通常不吃这一套。4.4 时间分配与调试技巧编程题通常是3到5道总时长90到140分钟。我建议拿到题先按难度快速排序优先做自己最有把握的题目。把保分题AC之后心理压力会小很多再去啃难题。很多同学喜欢从头到尾按顺序做结果在第二道难题上卡了四十分钟最后简单题没时间写非常可惜。如果真的卡住了我有一套实用的“小数据调试法”。第一拿题目示例跑一遍看结果是否一致第二在代码里加几个print输出关键中间变量定位到底是哪一步逻辑出了问题第三如果发现某一步结果偏离预期直接在草稿纸上手算这个中间结果判断是代码问题还是思路问题。不要一上来就怀疑算法不对很多时候只是下标差一或者条件判断反了。调试时还要注意控制时间。如果一道题想了20分钟还没有明确思路我的建议是暂时放弃先写一个朴素暴力解。拿到部分分数也好过零分。笔试不像面试不会因为你“最终没写出来”就给你同情分能AC就是硬道理。5. 关于刷题方法最后说几句实在话5.1 按专题刷比按题库顺序刷有效很多人打开LeetCode从第一题开始一道一道刷这种刷法效率太低。腾讯音乐2023校招编程题真正需要掌握的专题其实并不算多字符串、栈与队列、链表、二叉树、哈希表、二分查找、滑动窗口、动态规划、贪心。建议每个专题集中刷10到15道题刷完再换下一个。这样能让你在短时间内建立对同类题型的敏感度下次看到题目就知道该往哪个方向套。还有一个习惯非常推荐每道题AC之后花五分钟看评论区或者题解里更优的解法。笔试不是“能跑就行”如果你的解法复杂度明显劣于最优解换个数据规模就会被卡。看别人是怎么设计状态、怎么优化空间的这些增量知识才是刷题最大的价值。5.2 复盘比做新题更重要说实话我自己刷题时最容易犯的错误就是“题目做了一道忘一道”。后来我给自己定了一个规矩每道题做完了必须写一个简短的复盘笔记记录三件事题目考察的知识点是什么、我的初始思路是什么、最优解和我的思路差异在哪里。这样坚持一个月后明显感觉到遇到同类题目时反应速度快了很多。复盘时还要习惯自动归类。同样是二分有的题是直接查找目标值有的题是查找边界有的是二分答案。你不需要记住每道题的代码但一定要能说出“这道题为什么能二分”。这种抽象总结能力才是笔试中真正稀缺的东西。5.3 用模拟笔试的心态来练习考前两周建议进入模考模式。设定一个完整时间段比如两个小时找一套难度接近企业校招的题目集严格按照考试状态去写。把手机关掉不许查资料不许中途看题解。模考完不要只看分数还要统计自己在每道题上消耗的时间找出哪些环节拖慢了速度。比如有些人读题特别慢有些人代码调Bug特别久有些人总是漏边界条件。这些问题在平时单题练习中暴露不出来模考会原形毕露。提前发现问题比笔试当天发现要好得多。最后再分享一个小技巧笔试前把常用算法的模板代码重新默写一遍不需要运行就在纸上写。合并区间、快速排序、二分查找、前中后序遍历、滑动窗口、01背包、最长递增子序列这些基本结构如果都能做到条件反射笔试的底就已经很厚了。祝大家都能拿到满意的offer。