腾讯音乐秋招笔试复盘：技术研究岗的考察重点与准备思路

腾讯音乐的技术研究类笔试，算是我秋招季里印象比较深的一场。先说结论：它不像常规互联网大厂那样只盯着算法题海刷，而是把大量比重放在了“技术研究和业务落地结合”的维度上，尤其是音频技术、推荐算法这些和音乐场景强相关的方向。这篇就把我当时参加2023年秋招这场笔试的完整经历、题目类型复盘、踩坑记录，以及我后来整理出的准备思路，一次性说清楚。

1. 笔试概况与岗位方向拆解

腾讯音乐娱乐集团旗下有QQ音乐、酷狗音乐、酷我音乐、全民K歌这些产品线。技术研究类岗位在秋招里一般对应的是算法工程师、机器学习研究员、音频信号处理工程师这类方向。笔试考察的不是单纯“会不会写代码”，而是“能不能用技术解决音乐场景下的实际问题”。

1.1 岗位方向与考察侧重点

技术研究类笔试通常分以下几个方向：

• 推荐算法方向：核心是用户听歌行为建模、歌曲Embedding、召回排序策略，考察协同过滤、FM、DeepFM、双塔模型这些。
• 音频信号处理方向：歌曲识别、音质增强、歌声合成、伴奏分离，考察MFCC特征、傅里叶变换、频谱处理、深度学习音频模型。
• 自然语言处理方向：歌词文本分析、搜索Query理解、评论情感分析，考察BERT、文本匹配、序列标注。
• 多模态方向：音频加文本的跨模态检索、封面图与歌曲风格匹配，考察对比学习、多模态融合。

我报的是推荐算法方向，所以整场笔试里遇到的机器学习理论题占比最高，算法题量中等偏上，还有两道和音乐场景强相关的开放性设计题。

1.2 笔试形式与平台体验

2023年秋招的笔试统一在牛客网进行，双机位监控，手机放侧面，电脑开屏幕共享。全程大约120分钟，题量看方向略有差异。我这场是：

• 单选题 10道
• 多选题 5道
• 编程题 2道
• 场景设计题 1道

这里有一个很多人容易忽略的点：牛客网的在线IDE不支持本地调试，代码运行环境是固定的。我当时用的Python 3.9，但有些第三方库如numpy在部分题目环境里不可用（准确说可用，但某些版本支持不完整）。建议笔试前先去牛客网熟悉一下他们的在线编程界面，特别是输入输出处理方式，避免在正式考试时因为输入输出格式问题丢分。

2. 在线笔试的完整复盘

这一部分是我最想详细写的。整场笔试的题目设计其实是有梯度的：选择题考基础理论，编程题考代码功底，场景设计题考业务直觉和技术视野。

2.1 选择题部分：机器学习基础理论全覆盖

选择题基本覆盖了机器学习最核心的知识点，我回忆了一下，大概有这么几类：

概率论与统计基础：有一道题给了两个高斯分布的均值和方差，要求计算两个分布重叠区域的概率近似值。这类题本身不难，但需要记住正态分布的一些关键分位点，比如1.96对应95%置信区间。我当时因为临时想不起来分位点，最后靠估算选的。

损失函数与优化：问的是在分类任务中，当正负样本极不均衡时（比如正样本只有1%），直接使用交叉熵损失会出现什么问题，应该怎么做。答案是模型会倾向把所有样本都预测为负类，可以用Focal Loss或者对损失做类别加权。这类题考的是对损失函数原理的真正理解，而不只是会调API。

正则化与防止过拟合：给出一个高维稀疏特征场景，问L1正则和L2正则分别会带来什么效果。L1会让部分特征权重变为0，起到特征选择作用；L2会整体压缩权重值，但不会直接置零。

评价指标：给了混淆矩阵，计算精确率、召回率、F1值。这道题不难，但要注意多分类情况下micro-F1和macro-F1的计算区别。题目考的是macro-F1，即每个类别的F1单独计算再取平均。

特征工程：问在CTR预估场景中，对于用户年龄这种连续特征，为什么经常要做分桶处理而不是直接输入原始值。原因是连续值在浅层模型里难以拟合非线性关系，分桶后配合embedding能学到更好的非线性表达。

2.2 编程题：两道题决定了你是否进入下一轮

编程题一共两道，难度我认为介于LeetCode中等和困难之间。

第一道题：简化版热门歌曲排行榜

题目大意是：有n首歌，每首歌有歌曲ID和播放次数，需要实现一个数据结构支持以下操作：

• 增加某首歌的播放次数
• 查询当前播放次数排名前k的歌曲ID

这个题本质是设计一个支持增量更新和TopK查询的数据结构。常规解法是哈希表映射歌曲ID到播放次数，配合小顶堆维护TopK。关键在增量更新时，小顶堆需要支持删除旧值插入新值，用懒删除标记处理，而不是真的从堆中删除。

我当时用Python的heapq实现，维护一个大小为k的小顶堆，每次更新播放次数时，如果新次数大于堆顶，则弹出堆顶并插入新值。同时用字典记录每首歌当前是否在堆中以及对应的次数，避免重复插入。

这道题的时间复杂度是O(logn)每次操作，完全能过。

第二道题：歌手相似度计算

题目给了一个歌手的特征向量矩阵，要求计算两两歌手之间的余弦相似度，并找出与目标歌手最相似的top3歌手。

这个题表面上是计算余弦相似度，实际考察点在于数据规模。如果歌手数量是10万级别，特征维度是128维，暴力两两计算相似度是10万乘以10万再乘以128，约1.28万亿次乘法运算，显然会超时。

正确做法是：

1. 对特征矩阵做L2归一化
2. 矩阵乘法直接计算相似度矩阵，利用numpy的并行加速

如果是用Python写，直接np.dot(features, features.T)就能完成计算。我当时提交的代码用的是numpy，大概几十行，所有测试用例都通过了。

2.3 场景设计题：音乐场景下的技术方案设计

这道题我印象最深刻：QQ音乐每天有上亿用户听歌，如何设计一个实时歌曲推荐系统？要求给出从数据采集到线上服务的完整架构，并说明冷启动用户如何推荐。

这道题考察的是全栈式的系统设计能力。我的思路分四层：

第一层是数据采集层，实时收集用户听歌行为、暂停、切歌、收藏、分享等事件，通过消息队列传输到下游。

第二层是特征计算层，实时计算用户当前 session 的听歌序列、高频风格分布、最近播放时间等特征，同时离线计算用户长期兴趣画像。

第三层是召回层，多路召回：基于协同过滤的相似用户召回、基于歌曲Embedding的相似歌曲召回、基于热门歌单的热门召回、基于用户的实时行为序列召回。

第四层是排序层，用精排模型（比如DeepFM或DIN）融合多路召回结果，再经过业务规则过滤（比如版权限制、重复歌曲过滤、内容安全审核），最后输出推荐结果。

冷启动用户的推荐策略我写的是：优先用热门歌曲和热门歌单，结合用户的地理位置和年龄段做粗粒度匹配，同时利用用户前几次点击行为快速更新短期兴趣模型。

这类题没有标准答案，但一定要把思路写完整，逻辑要通顺。阅卷人看重的是系统思维和业务理解，而不是具体某个模型的精度。

3. 技术研究类笔试的底层能力要求

如果你想在技术研究类笔试中取得好成绩，光靠刷LeetCode是不够的。这场笔试的题目设计反映出腾讯音乐对候选人的底层能力要求，我总结为四个维度。

3.1 数学基础：概率论、线性代数、最优化方法

技术研究类岗位的笔试中，数学基础是必考项。概率论部分常考高斯分布、贝叶斯公式、期望与方差、最大似然估计。线性代数部分常考矩阵乘法、特征值分解、奇异值分解、余弦相似度。最优化方法部分常考梯度下降、随机梯度下降、动量优化、学习率衰减策略。

我建议把“花书”《Deep Learning》的前四章和“西瓜书”《机器学习》的第一章到第三章过一遍。重点不在于能推导所有公式，而是要理解每个公式的物理含义和适用场景。

比如面试官问“为什么在深度学习训练中通常使用Adam优化器而不是SGD”，答案是Adam通过一阶动量和二阶动量自适应调整每个参数的学习率，在稀疏梯度和噪声较大的场景下表现更稳定。这种理解性的认知，选择题里很爱考。

3.2 机器学习算法理论：从线性模型到深度模型全覆盖

笔试选择题覆盖了线性回归、逻辑回归、决策树、随机森林、GBDT、XGBoost、SVM、K-means、DBSCAN、PCA、协同过滤、矩阵分解等经典算法。

考察方式通常是：给你一个具体场景，问哪种算法最合适；或者给一段代码，问这段代码实现了什么算法；或者直接问某个算法的优缺点、时间复杂度、空间复杂度。

我当时遇到的一道题是：用户听歌数据是一个稀疏矩阵，行为用户，列为歌曲，值为播放次数，如何做歌曲推荐？选项包括SVD矩阵分解、KNN、决策树、朴素贝叶斯。这题正确答案是SVD矩阵分解，因为矩阵分解天然适合处理稀疏矩阵的推荐问题。

3.3 深度学习模型：从DNN到Transformer

深度学习部分的考点集中在常见的网络结构上，包括DNN、CNN、RNN/LSTM、Attention、Transformer、BERT。需要掌握每种模型的原理、优缺点、适用场景。

有一道选择题问：在序列推荐场景下，使用Transformer相比LSTM的优势是什么？选项包括并行计算能力强、能够捕捉长距离依赖、不需要循环结构、对位置信息不敏感。正确答案是前三项，第四项是错误的，因为Transformer需要额外加入位置编码。

我当时选对了，但事后想想，这类题考的不只是你会不会用Transformer，而是你理不理解Transformer为什么比LSTM更适合序列建模。核心是自注意力机制的计算是并行的，而且任意两个位置之间的依赖距离都是1，所以长距离依赖捕捉能力更强。

3.4 工程能力：数据结构、算法复杂度、代码实现

工程能力的考察主要是编程题，难度不算离谱，但需要在限定时间内写出可运行的代码。我总结了几类高频题型：

• 哈希表与排序组合：TopK问题、频率统计、去重
• 动态规划：字符串编辑距离、最长公共子序列、背包问题
• 二叉树遍历：前序中序后序、层序遍历、最近公共祖先
• 图算法：最短路、拓扑排序、并查集
• 双指针/滑动窗口：连续子数组问题、字符串匹配
• 二分查找及其变体：旋转数组、查找区间

推荐大家在准备阶段把LeetCode热题100过两遍，特别是medium难度的题目。笔试现场的编程题一般不会直接出自LeetCode原题，但解题思路都是相通的。

4. 音乐场景下的技术特色与实战经验

腾讯音乐的笔试和纯互联网大厂笔试最大的不同，在于它大量结合了音乐业务场景。这是它的特色，也是很多候选人容易忽略的盲区。

4.1 音频技术考察点：不只是算法题纯数学

如果你是投递音频信号处理方向，笔试中会出现音频相关的专业基础题。我虽然没有投递这个方向，但在准备阶段看过往年题目，整理了一些高频考点：

• 采样与量化：Nyquist采样定理，电话语音8kHz采样、CD音质44.1kHz采样，每个采样点用16bit量化
• 时频域变换：傅里叶变换、短时傅里叶变换、梅尔频谱、MFCC特征提取流程
• 音频编解码：AAC、MP3、Opus的码率、延迟、音质对比
• 音频增强：谱减法降噪、维纳滤波、DNN-based语音增强
• 音高与节奏：自相关函数提取基频、节拍跟踪算法
• 歌声合成：WaveNet、Tacotron、DiffSinger的基本原理

这些知识点如果平时没有接触过，临时抱佛脚是来不及的。建议相关方向的同学在秋招前系统性地过一遍数字信号处理的基础课程，至少要知道每个概念是解决什么问题的。

4.2 推荐算法在音乐场景下的特殊挑战

音乐推荐和电商推荐、信息流推荐有很大不同，这些差异在笔试中会以选择题或场景题的形式出现。

音乐推荐的用户行为信号比较稀疏。用户听一首歌可能只是背景音乐，并没有强烈偏好表达。电商的购买行为是强信号，而音乐播放行为是弱信号。因此，在建模时需要对行为进行加权，比如完整播放权重高于只听了10秒，收藏权重高于完整播放，主动搜索权重高于被动推荐。

音乐消费存在明显的session内连续性。用户可能因为心情好连续听快歌，也可能因为失恋连续听慢歌。这种session级别的兴趣漂移需要在模型中建模，DIN模型中的注意力机制在这里很适用。

长尾歌曲的冷启动问题比电商更严重。头部歌曲播放量极高，长尾歌曲几乎没有反馈数据。因此，基于内容特征的歌曲Embedding和基于图神经网络的传播方法，在音乐推荐中特别重要。

4.3 腾讯音乐笔试中的业务理解考察

场景设计题其实是业务理解考察的延伸。我当时写的是基于用户实时行为序列和DeepFM排序模型的方案，但后来复盘发现，可以答得更贴合音乐场景。

我的方案里还应该包括：

• 听歌识曲与推荐打通：用户用听歌识曲识别了一首歌，这个行为代表他主动想了解这首歌，是强正反馈信号，可以用于后续推荐
• 新歌首发场景：新歌上线时没有播放数据，可以通过相似老歌的Embedding迁移来解决冷启动
• 视频场景的BGM推荐：短视频平台带火的老歌回春现象，说明跨场景的热度传播很重要
• 多人同时听歌场景：通过实时位置和耳机状态判断用户是否在聚会场景，推荐适合多人场景的热门欢快歌曲

如果你能把这些业务思考写进场景设计题里，会明显比只堆通用技术名词拿到的分高。

5. 从笔试到面试：复盘与进阶建议

笔试只是秋招的第一步，但它的成绩直接决定了你是否有面试资格。从我个人的经验来看，笔试后的复盘比笔试本身更重要。

5.1 笔试结束后的快速复盘方法

笔试结束后，趁记忆新鲜，把题目分门别类地记录在表格里，比如：

然后针对薄弱项做专项提升。我当时多选题错误比较多，原因是多选题要求对知识点有精确的边界认知，而不是模糊的印象。所以后续我专门做了深度学习面试题的专项梳理，把每个模型的“原理-结构-损失函数-优化器-适用场景-局限性”整理成卡片，反复记忆。

5.2 技术研究类面试的高频追问方向

通过了笔试之后，面试环节的考察点会和笔试高度关联。腾讯音乐的技术面试通常有两轮到三轮，其中必然有一轮是算法题，一轮是项目深挖，一轮是业务场景设计。

业务场景设计面试中，面试官可能会追问：

• “你刚才提到用DIN建模用户历史行为序列，如果用户历史行为有5000条，如何处理？”答案：截断最近N条，或者用注意力机制对历史行为做软筛选。
• “冷启动的用户没有任何行为数据，怎么办？”答案：利用用户注册时的标签（年龄、性别、地域）、设备型号，以及跨产品线的数据（比如用户是否在用全民K歌唱歌）。
• “如何评估推荐系统的效果？”答案：离线指标用AUC、GAUC、Recall@K，在线指标用CTR、播放时长、次日留存率，还要关注主动搜索率的变化。

面试官更喜欢听到你自己踩过坑之后的经验总结，而不是教科书式的标准答案。有一说一，多做真实项目或者实习经历，在面试中会非常有优势。

5.3 准备秋招的时间线与资源推荐

我自己是7月份开始系统性准备秋招的，8月中旬投递，9月初笔试，9月中旬面试。这个节奏不算早，但完全来得及。

具体时间线建议：

• 6月~7月：巩固机器学习理论基础，看西瓜书和李航的统计学习方法，整理自己的知识体系
• 7月~8月：刷LeetCode热题100，每天3~5道，分类刷，不盲目追求题数
• 8月：投递简历，复习深度学习和推荐系统项目经验，准备一段3分钟自我介绍
• 9月：笔试密集期，每周保持两场笔试的手感，笔试后及时复盘

资源方面，我推荐几个比较实用的：李航《统计学习方法》适合机器学习基础，DeepLearning.ai的深度学习专项课程适合快速回顾神经网络，LeetCode热题100适合短期刷题，知乎和牛客的笔经面经适合了解目标公司的考察风格。

5.4 踩过的坑：给后来者的几条提醒

最后分享几个我实际踩过的坑，希望后来者能提前避开。

第一个坑是过于重视编程题，忽视了理论题。实际上腾讯音乐这场笔试的选择题和场景设计题占的比重非常大，编程题只要AC两道就能过，选择题错太多反而容易被刷。我的建议是编程题保证每天练手保持手感，但理论知识的复习时间至少要占全天准备的50%。

第二个坑是没有提前熟悉牛客网的笔试环境。我第一次在牛客网做笔试时，不知道代码要手动处理输入输出，导致第一道题花了10分钟才把输入解析写对。强烈建议正式笔试前，至少去牛客网做两场模拟笔试，把输入输出处理的模板提前准备好。

第三个坑是场景设计题写得过于技术化，缺少业务思维。考官的反馈（虽然是后来通过面试了解到的）是，大多数候选人的方案都长得很像，只是把推荐系统的通用架构默写了一遍。真正能脱颖而出的，是那些能结合音乐App特有业务逻辑的方案。

第四个坑是时间分配不合理。笔试120分钟，我花了太长时间在第一道编程题上，导致场景设计题只有15分钟来写。场景设计题虽然只有一道，但分值比重可能超过编程题的单题。建议开考后先把全部题目扫一遍，预估每部分的耗时，把场景设计题至少预留20分钟。

6. 聊聊腾讯音乐技术岗位的价值与成长空间

如果你拿到了腾讯音乐的offer，或者正在考虑面试技术研究类岗位，我觉得有必要聊一聊这个方向的长期价值。

6.1 音乐场景对算法研究的意义

音乐是数字内容产业中技术复杂度最高的领域之一。音频信号处理、推荐系统、内容理解、多模态检索，每一个方向都有大量真实的业务问题可以研究。相比于在通用电商平台做推荐，音乐平台推荐有一个显著的不同：用户的兴趣是高度多样化和个性化的，而且同一个用户在不同场景下的偏好可能截然不同。

这意味着你在这个领域积累的经验，很多是可以复用到视频推荐、短视频推荐、播客推荐等相邻领域的。技术迁移性比较强，这对职业发展是有利的。

6.2 业务壁垒与技术护城河

腾讯音乐拥有庞大的版权曲库和多年的用户行为数据，这些数据本身就构成业务壁垒。对于算法工程师来说，数据意味着可以做更精细的模型训练和效果验证。另一方面，音频技术（如听歌识曲、歌声合成、伴奏分离）有比较高的技术门槛，掌握这些能力后，你在整个行业中的稀缺性会明显提升。

如果你未来想在音频AI方向深耕，无论是去音乐平台还是去智能硬件公司，腾讯音乐的技术研究岗位都是一个不错的跳板。

6.3 我个人的一点体会

准备秋招的过程确实是高强度、高压力的，笔试只是第一道关卡。但回头看，我觉得最有价值的不是最终拿到了哪个offer，而是在准备过程中逼着自己把机器学习、深度学习的知识体系重新梳理了一遍，把推荐系统的经典论文读了一遍，把LeetCode高频题刷了两遍，把每一段项目经历反复提炼成可以在面试中讲清楚的故事。

这套准备方法论，不管最后去了哪家公司，都是拿得出手的核心竞争力。

最后再分享一个小技巧：笔试前的晚上不要刷难题了，把机器学习、深度学习关键知识点快速过一遍，然后早睡。状态比临时抱佛脚重要得多。如果时间实在来不及，优先保证把编程题AC，再带着业务理解去写场景设计题，比硬憋一个大型推荐架构要拿分得多。