2024年春招我投了腾讯音乐的Java后端岗。简历投出去一周左右收到了第一批笔试通知。说实话点开邮件的时候心里还挺平静的因为知道腾讯音乐的笔试向来口碑稳定——不搞偏题怪题但基础考察极其扎实对代码实现能力的要求也比较实在。真正坐到电脑前打开考试系统的那一刻才意识到这场笔试的核心逻辑不是要你做出所有题而是看你在限时压力下能不能把会做的题稳定拿到分。这篇就围绕我这场笔试题型、踩坑细节和对春招节奏的一些看法做个完整复盘。如果你正准备投大厂技术岗或者对腾讯音乐这类业务型互联网公司的笔试风格好奇这篇值得看完。我会尽量还原考场上的真实情况包括选择题的考察方向、三道算法题的完整思路以及那些只有上了考场才发现的坑。1. 笔试前半场选择题的考察方向与得分要点腾讯音乐的笔试用的是牛客网系统技术岗题目构成很固定选择题加编程题总分不一定公布但每个部分的用时自己控制。我当时拿到的卷子是17道选择题加3道编程题总时长90分钟。这个时长设置很有意思——看似宽裕实际上选择题如果每题花超过2分钟后面的编程题时间就会非常紧张。先说说选择题。这部分覆盖范围很广从数据结构、操作系统、计算机网络到数据库、Linux命令、Java/C语言特性都有涉及。整体难度中等偏上不完全是那种看一眼就知道答案的送分题很多题目需要动笔比划一下才能确定。1.1 数据结构与算法题平衡树和哈希是高频点选择题里数据结构占比最大差不多有5-6道。我印象比较深的一道是关于平衡二叉树调整的给出一棵插入过程中失衡的AVL树问旋转之后变成什么形状。这道题考的不只是四种旋转LL、RR、LR、RL的名字更需要在草稿纸上把每个节点的平衡因子算一遍。我的建议是别在脑子里转动手画很快就出来了。还有一道哈希表相关的题给定了哈希函数和冲突解决方式链地址法要求计算平均查找长度。这种题没什么技巧老老实实把每个关键字散列到对应位置画出链表再算。题目本身不难但特别容易被考点在链地址法这个预期带偏——真正的考点其实是散列函数对数据分布的影响。另一个容易丢分的是B树。腾讯音乐这类公司数据库相关的场景非常多B树的叶子节点存储结构、查找路径、范围查询优势这些考点几乎是必出现。选择题里问的是向B树插入一个关键字后叶子节点分裂的细节。这种题如果不熟悉定义很容易选错。1.2 操作系统与网络的几道老朋友操作系统的题目不算多大约3道但很典型。考了进程和线程的对比——这个属于送分题理解了就选得出来。还有一道关于死锁的四个必要条件里选择一个不属于的这个也简单。真正有意思的是一道关于虚拟内存的题给定页面访问序列和物理块数用LRU算法算缺页次数。这题我在草稿纸上画了大概两分钟才确定答案因为访问序列里有两个元素的访问顺序很容易被忽略。网络部分有两道一道TCP三次握手问第二次握手发送的报文标志位一道HTTP状态码给出几个状态码问哪个表示重定向。都是基础问题但如果复习范围只盯着HTTP/1.1而忘了状态码分类还是会卡一下。其实这类题反复考考察的就是你脑子里有没有一张清晰的知识地图而不是死记某个数字。1.3 数据库与Linux业务画像很鲜明这次笔试明显偏业务向数据库相关的选择题出了两三道包括索引失效的场景判断、事务隔离级别和锁机制。索引失效那道题我最喜欢给了一个复合索引(a, b, c)然后给了四个查询条件组合问哪一个会走索引。这属于经典的最左前缀原则但题目里混了一个范围查询一旦b是范围查询c那部分索引就用不上。这种题如果不仔细分析查询条件顺序很容易错。Linux题目比较简单考的是常用命令的执行结果比如在某个目录下找出最近修改的文件用find还是grep还是awk。这其实不是考命令本身而是考你对命令适用场景的理解。建议准备阶段多动手敲别只看文档。1.4 语言特性题多语言混合出现的应对策略腾讯音乐笔试的语言题不限定单一语言Java、C、Python都有可能出现。我当时遇到的有Java的HashMap在JDK 8中红黑树化的阈值链表长度达到8且数组长度达到64也有C的虚函数表和构造函数调用顺序。如果你只熟一门语言这些题也不至于完全不会因为它们实际上考的还是通用概念——哈希冲突解决、继承与多态。这里就涉及到一个小策略遇到语言题不要慌先看它在考什么底层机制再用自己熟悉的语言知识去对号入座。比如C的虚函数题本质上考的是运行时多态的实现方式和你学的Java接口实现是一回事。2. 编程题复盘从业务场景到算法本质的抽丝剥茧编程题是这场笔试的重头戏3道题每道20-30分合计60分以上。拿到题目第一感觉是出题人很懂音乐业务题目都披着一层音乐场景的外衣但剥开之后都是经典的算法内核。这一点其实挺重要的——它不是完全脱离业务的纯算法题也不是只懂业务就能做出来的题而是让你把算法能力映射到真实场景中。2.1 第一题字符串去重变体考的是栈和贪心题目大意给定一个由小写字母组成的字符串模拟歌单名集合要求删除重复字符使得最终字符串中每个字母只出现一次且返回的字符串字典序最小。典型的LeetCode 316去除重复字母变体。我在考场上第一眼就认出来了心里稳了一截。核心思路不是简单去重而是用贪心加单调栈遍历字符串时维护一个栈和每个字符的剩余出现次数当前字符如果小于栈顶字符且栈顶字符在后面还会出现就把栈顶弹出去这样最终字典序会尽可能小。def remove_duplicate_letters(s: str) - str: stack [] visited set() remain {} for ch in s: remain[ch] remain.get(ch, 0) 1 for ch in s: remain[ch] - 1 if ch in visited: continue while stack and ch stack[-1] and remain[stack[-1]] 0: visited.remove(stack[-1]) stack.pop() stack.append(ch) visited.add(ch) return .join(stack)这道题考察的点很集中是否理解单调栈的决策逻辑以及能否处理visited集合维护这个细节。写出框架不难但很容易漏掉remain[stack[-1]] 0这个条件一旦漏掉去重就变成了错误的单调栈。2.2 第二题播放列表合并区间贪心排序没跑了题目大意给出一组歌曲在某个节目单中的播放时间段闭区间要求合并所有重叠的时间段输出合并后的区间列表。这是区间合并的经典题LeetCode 56变体。思路很简单先按区间的起点排序然后遍历所有区间如果当前区间和上一个合并区间的终点有重叠就更新终点否则开启一个新的合并区间。核心点在于排序之后只需要线性扫描时间复杂度O(n log n)空间复杂度O(n)。def merge_intervals(intervals: list[tuple[int, int]]) - list[tuple[int, int]]: if not intervals: return [] intervals.sort(keylambda x: x[0]) merged [intervals[0]] for start, end in intervals[1:]: last_start, last_end merged[-1] if start last_end: merged[-1] (last_start, max(last_end, end)) else: merged.append((start, end)) return merged这类题最大的失分点反而是最简单的部分边界条件。intervals为空、只有一个区间、区间恰好首尾相接比如[1, 2]和[2, 3]都需要仔细处理。合并不是start last_end而是start last_end因为闭区间首尾相接也属于重叠。考场上我看到闭区间三个字就知道这里必须用。2.3 第三题任务依赖调度拓扑排序的经典场景这道题明显是压轴题难度从前两题的LeetCode中等偏下直接跳到偏难。题目场景是模拟一个歌曲制作项目的任务依赖关系给定n个任务以及m对依赖关系a必须在b之前完成要求输出一个合理的执行顺序如果任务之间存在循环依赖则返回特定错误。拓扑排序用Kahn算法实现。先统计每个任务的入度然后把入度为0的任务加入队列依次出队并减少后继任务的入度每当某个任务的入度降为0就加入队列。最终如果处理过的任务数小于n说明存在环。from collections import deque def task_order(n: int, prerequisites: list[tuple[int, int]]) - list[int]: graph [[] for _ in range(n)] indegree [0] * n for a, b in prerequisites: graph[a].append(b) indegree[b] 1 queue deque([i for i in range(n) if indegree[i] 0]) order [] while queue: node queue.popleft() order.append(node) for nxt in graph[node]: indegree[nxt] - 1 if indegree[nxt] 0: queue.append(nxt) if len(order) n: return [] return order这道题真正的难点在于识别出它是拓扑排序。因为题目包装了一层比较复杂的业务描述如果对题感不敏锐很容易被绕进去试图用DFS加状态标记去硬解。实际上不管用什么方法核心都是判断有向图是否有环并给出拓扑序列。我当时的做法是读了两遍题先把依赖关系提取出来画成有向图然后才动手写代码。2.4 编程题的时间分配先把稳的拿下三道题我用了大概55分钟完成。最后的节奏是第一题15分钟含读题第二题10分钟第三题30分钟。这个时间分配相当合理——第一题和第二题都属于有把握的题快速拿下稳住分数把剩余时间全砸在第三题上。这里想多说一句笔试编程题的时间分配比很多人想象的更重要。我见过太多人第一道题反复优化导致第三题连读题时间都没有。最优策略应该是先花1-2分钟快速浏览全部三道题形成一个由易到难的排序然后按顺序解。如果某道题卡了5分钟没有思路果断先跳到下一题。3. 编程题之外的隐藏考点代码风格和边界处理很多人以为笔试只看最终答案对不对其实不然。面试官拿到你的答题记录时会看你的代码风格、变量命名、边界处理思路甚至看你有没有写注释。这些虽然不直接算分但在技术评审环节会对你的印象分产生不小影响。3.1 变量命名和结构设计反映工程习惯我交上去的三道题变量命名都是清晰可读的类型比如remaining_count、visited_set、merge_result而不是a、b、tmp。这一方面是平时写代码的习惯另一方面也是有意为之——我知道面试官会看答题记录好的命名意味着好的工程素养。代码结构上我尽量把逻辑拆成了几个逻辑块每个块之间用空行分隔关键的判断条件旁边会写简短注释。比如在第二题里我在start last_end旁边写了闭区间重叠在第三题里写了拓扑排序完成检查是否有环。这不算额外耗时但对阅读体验的提升是明显的。3.2 边界情况的验证是拉开差距的关键很多时候同样的思路有人AC有人WA差的不是算法本身而是边界情况的处理。以第二题为例intervals为空的情况、单元素情况、首尾相接情况每题我都花了几十秒逐一验证。这几十秒在本场笔试里没有浪费——因为一旦某个隐藏边界没处理整道题一分不得。第三题的边界更隐蔽依赖关系里可能包含重复的边比如(a, b)出现两次这时候indegree[b]会重复加二导致入度永远不会降到0最终误判为存在环。我当时在构图时特意用集合去重了一下把重复边过滤掉。这个细节题目没明说但现实中任务依赖清单确实可能出现重复记录所以考虑到这一点是合理的。3.3 递归和循环的选择能迭代就别递归用递归处理拓扑排序或者数组遍历写起来很简洁但在笔试环境里有一个隐患递归深度过大可能导致栈溢出或超时。我通常优先使用迭代写法少写递归。第三题用队列实现的Kahn算法就是迭代思路完全不担心递归层级问题。这也是一种工程判断——面试官会倾向于看到你在写代码时主动规避风险。4. 考前一周的有效准备刷题之外还做了什么腾讯音乐笔试的考察风格整体来说比较正统。如果你问我考前一周该怎么准备我的建议是不要盲目刷题先明确考察范围再有针对性地查缺补漏。4.1 按出题概率给知识点排优先级我在笔试前一周把常见的算法知识点按出题概率排了个序大概是这样的优先级知识点典型题型准备方式高数组/字符串处理双指针、滑动窗口、单调栈LeetCode 中频题刷 2 遍高排序与贪心区间合并、任务调度熟练掌握 sort 扫描模式高数据结构基础哈希表、栈、队列、堆理解适用场景和复杂度中树二叉树遍历、BFS/DFS能手写非递归遍历中图论拓扑排序、最短路径Kahn算法、BFS/DFS中动态规划背包、子序列、编辑距离掌握经典状态定义低字符串高级算法KMP、Trie、AC 自动机了解原理能默写 KMP这个优先级不一定完全覆盖所有公司的出题风格但腾讯音乐确实完全踩在这个表上数组和字符串是绝对核心排序和贪心紧随其后树和图各出了一道场景题。动态规划这次虽然没有出现但准备阶段不能跳过。4.2 手写代码能力没有IDE自动补全也要顺畅笔试系统一般自带一个简易IDE有代码高亮但别指望有智能补全。我在考前专门练习了不依赖IDE的代码编写尤其是Python的collections.deque、defaultdict、sorted这些高频模块的用法保证手写时不会卡壳。另外一个很有效的练习是限时刷题。我在考前两天用LeetCode的模拟考试功能每天做一套90分钟的题目严格按考试节奏来。这种做法不会让你短时间内水平突飞猛进但会消除考场上的时间焦虑——当你习惯了倒计时时真正上考场反而会觉得从容。4.3 高频题型的肌肉记忆考前的最后阶段我不再追求做新题而是把高频题型重新做一遍区间合并、字符串去重、三数之和、链表反转、二叉树层序遍历、最长回文子串、爬楼梯。这些题在笔试中出现概率极高就像篮球运动员的投篮热身一样它们能让你快速进入状态。我还特意看了一批LeetCode题目的题解区讨论不是为了背答案而是看别人的解法和边界处理方式。同一个题有人用递归有人用迭代有人考虑了空输入有人没考虑——这种讨论能帮你在考场上想得更全面。5. 考后复盘如何用笔试经验校准后续春招节奏笔试结束不代表事情结束。我习惯在笔试后当天晚上花一小时做复盘因为这时候记忆还新鲜哪些题卡过壳、哪些知识点没掌握都一清二楚。这个复盘动作的价值比多刷五十道题还大。5.1 建立错题和卡壳记录我把这次笔试题按完全不会、思路对但代码有bug、稳定AC三档分类。第三档说明这个知识点的掌握已经比较扎实第二档是最有价值的部分说明思路没问题但实现细节存在盲区第一档则是后续复习的重点。具体来说我这次的选择题里有一道关于数据库复合索引范围的题属于思路对但选项犹豫说明对最左前缀原则的边界条件还不够敏感。我在复盘记录里专门写了一行重建复合索引时范围查询右边字段会失效。这种知识点不需要大块时间重新学只需要在后续复习中每周过一遍就能形成条件反射。5.2 笔试如何影响面试准备方向通过笔试的题型基本能看出这家公司对技术栈的重点关注。腾讯音乐这场笔试明显偏重基础数据结构和业务场景的结合数据库和操作系统的题目也占了相当比例。那我后续的面试准备就会相应调整数据结构方面重点复习哈希表和树的底层实现数据库方面重点准备索引优化和事务隔离级别操作系统方面重点看进程调度和内存管理。还有一个容易被忽略的点编程题的代码会被面试官看到所以复试面试中很可能针对某道题追问细节。比如第三题面试官可以问如果依赖关系中存在重复边怎么办、如果任务数量特别大能不能用DFS做、拓扑排序的结果是否唯一。因此笔试考完不等于这道题就结束了你应该在复盘时把每道题可能的追问方向都想一遍。5.3 春招节奏笔试之后做什么春招整体节奏比较紧笔试后一般2-5天会出结果通过后紧接着就会约面试。这段时间不用再海量刷题而是应该做三件事第一把笔试复盘中的薄弱点快速过一遍第二准备一段清晰的项目介绍重点突出技术难点和解决方案第三熟悉一些高频的面试追问套路比如为什么这样设计、有没有考虑过其他方案。我自己的经验是笔试后的等待期其实是心态最容易波动的阶段因为不确定能不能进面试。但与其干等不如把这段时间当成冲刺期——无论有没有过这段时间的复习都不会白费因为其他公司的面试也会用到这些知识。最终结果出来这场笔试我顺利通过进入了后续的面试环节。复盘完这套流程我最大的感受是大厂笔试并不是一道不可逾越的门槛它考的东西非常实在——基础扎实不扎实代码写得干不干净边界情况想得全不全限时压力下稳不稳。这些能力不是临时抱佛脚能补上来的需要平时写代码时就养成习惯。如果你正准备下一场笔试我建议你从今天起就有意识地在刷题时练习不看自动补全、先想边界条件、写清晰变量名这三件事。坚持两周你会明显感觉自己上考场的底气不一样了。