收到腾讯音乐2023春招后台业务开发岗的笔试通知是在投递简历后的一个周三下午。邮件里明确写着“第一批笔试”我知道准备时间已经不多了。作为一个后台开发方向的求职者我当时最关心的几个问题其实是笔试用什么平台、考什么题型、算法题大概什么难度、选择题覆盖哪些科目、有没有场景设计题以及最重要的——怎么分配时间才不至于做不完。现在回过头来看这场笔试的考察思路相当典型很能代表大厂后台业务岗的选拔逻辑。这篇文章就把整个笔试复盘一遍包括题型分布、复习重点、解题思路和一些实用经验目标是让准备后续批次或者其他厂笔试的人心里有底。1. 笔试整体概况平台、时长与题量结构先说最基础的笔试通过牛客网在线考试系统进行全程需要在浏览器里完成会有摄像头监控和切屏记录。整套题的时间是120分钟题量不算夸张但节奏如果没控制好很容易出现“选择题纠结太久、最后一道算法题只能交白卷”的情况。从题型结构上看大致可以分成三个板块计算机基础选择题单选加不定项选择、三道编程题、一道或两道简答/场景设计题。选择题大概在10道左右覆盖操作系统、计算机网络、数据库、Java或C语言特性、数据结构等编程题按难度递增排列场景设计题则是给出一个偏业务的后台问题要求写出设计方案或关键代码思路。这里有个容易被忽略的细节牛客的笔试环境里编程题支持的语言以C、Java、Python为主但如果你用的是比较小众的语言或者编程环境依赖特殊库很可能在编译环节就被卡住。我当时的策略是“Java为主、Python做辅助验证”因为Java在牛客的判题环境里生态最稳定而Python适合用来快速验证思路和写部分分。如果你对C更熟用C也没问题但要注意别在笔试时尝试一门自己不熟练的语言——网上很多代码模板看着优雅真正手写的时候反而容易出低级语法错误。笔试的通过线没有一个公开标准但从周围人的反馈来看选择题的正确率、编程题的通过用例数、场景设计题是否有完整逻辑这三项都会被综合评估。也就是说哪怕有一两道题没完全ACAccepted只要整体表现不差还是有进入面试的机会。但反过来如果三道编程题全挂选择题正确率再高也很难救回来。2. 三道算法题难度梯度与常见解法拆解后台开发岗的算法题不会像算法岗那么偏门重点还是那些“工作中真正可能用到”的思维比如模拟、双指针、二分、动态规划、贪心和数据结构操作。三道题基本呈梯度分布第一题是入门的模拟或字符串处理第二题是常见套路题第三题则会综合两个以上知识点AC起来会比较费劲。2.1 第一题偏模拟与字符串处理送分题不能丢第一题通常是类似“解析一段输入计算某种统计值”的题目核心考察的是编码基本功和边界条件处理。这种题没有高深的算法但如果你平时习惯在LeetCode里刷题反而容易在这种题目上吃亏——因为LeetCode不需要你处理输入输出的细节而笔试平台需要你自己写完整的main函数和输入解析逻辑。举个例子有一类典型题是“给定一个字符串按某种规则提取数字并求和”。看起来很简单但坑往往藏在输入里可能有多余的空格、可能包含负数、可能数字之间没有明确分隔符。正确做法是先写一个稳健的解析函数把字符串拆成token序列再针对每个token做判断。这种题的暴力写法都能过大部分用例关键是别为了追求一行流而把代码写得难以调试。2.2 第二题滑动窗口或二分答案的中等题第二题难度中等常见的考察点包括滑动窗口、前缀和、二分查找、拓扑排序等。当时我印象比较深的一道题思路是典型的滑动窗口给一个整数数组和一个目标值求满足“子数组和至少为target”的最短子数组长度。第一次看到这种题很多人会下意识用双重循环枚举所有子数组复杂度是O(n²)数据量一大就直接超时。而滑动窗口可以把时间复杂度降到O(n)。滑动窗口的核心思路可以这样理解用两个指针left和right表示当前窗口的左右边界右指针不断向右扩展窗口、累加窗口内的元素和一旦窗口和满足条件就尝试左指针向右收缩在收缩过程中更新最小长度。每个元素最多被加入窗口一次、移出窗口一次所以整体是线性复杂度。def min_subarray_len(target, nums): left 0 current_sum 0 ans float(inf) for right in range(len(nums)): current_sum nums[right] while current_sum target: ans min(ans, right - left 1) current_sum - nums[left] left 1 return ans if ans ! float(inf) else 0这类题想拿满分除了写出正确代码还要注意几件事一是边界条件比如数组为空、没有满足条件的子数组时应该返回0二是输入数据规模如果n可以达到10^5甚至10^6任何O(n²)的写法都会超时。另一类高频第二题是二分答案典型特征就是“求最大值的最小值”或“求最小值的最大值”。这类题一旦你意识到可以用二分去枚举答案再用贪心或模拟去验证答案是否可行思路就打开了。比如经典的“将数组分成连续k段使每段和的最大值最小”判断某个候选值mid是否可行时只需要贪心地把元素尽量往当前段里塞超过mid就开新段最后看段数是否不超过k。写验证函数的时候记得用 long 类型避免整型溢出这也是笔试里的常见扣分点。2.3 第三题多个知识点的综合题拿部分分要果断第三题普遍会难一个档次经常需要组合数据结构与算法。比如“树上路径查询”可能涉及DFS序加树状数组或线段树又比如“带限制的最短路径”可能涉及Dijkstra变种。面对这种题我先定的策略是先写暴力版本确保小规模数据能过再尝试优化到正解。笔试和算法竞赛一样是按通过用例的比例给分的暴力版本通常能拿到30%-60%的部分分直接空着等于放弃这些分非常可惜。以一道常见的综合题为例给定一棵树每个节点有一个权值支持两种操作——修改某个节点的权值、查询某个节点到根节点的路径上的权值和。如果没有修改操作直接用DFS预处理出每个节点到根的路径和一次查询就是O(1)。但加上修改操作后每次修改都会影响该节点整棵子树到根的路径和你就要想到用树状数组维护DFS序把子树映射成连续区间再结合差分思想做区间更新、单点查询。DFS序加树状数组这个组合几乎可以说是树相关笔试题的标配建议复习阶段就把它练熟。第三题还有一个明显的测试点题目给出的数据规模范围往往很大比如节点数10^5操作数10^5如果审题时没注意到这个量级就容易写出O(n²)复杂度且自以为正确的解法。拿到题目第一步一定先看数据范围这直接决定了你能接受的上界复杂度。经验上n ≤ 10^5基本要求O(n log n)甚至O(n)n ≤ 5000才允许O(n²)的写法。3. 计算机基础选择题高频考点与易错陷阱编程题决定你能不能过笔试选择题则决定你能不能高分过笔试。我个人的感受是选择题的考点其实非常固定基本就是操作系统、计算机网络、数据库、编程语言和数据结构这几大块。以下表格基本覆盖了当时的高频考点科目高频考点容易踩的坑操作系统进程与线程区别、死锁条件、虚拟内存、页面置换算法把进程状态转换的顺序记混同步与互斥概念混淆计算机网络TCP三次握手四次挥手、TIME_WAIT、拥塞控制、HTTP状态码握手过程中各个状态名记错搞混滑动窗口与拥塞窗口数据库索引结构、事务隔离级别、B树、SQL执行计划把隔离级别对应的问题连错以为索引一定加速所有查询Java/C内存区域、对象生命周期、容器类底层结构、并发机制基础类型与引用类型赋值行为的差异HashMap在并发场景下的行为数据结构链表操作、栈与队列性质、二叉树遍历、哈希冲突忽略平均与最坏情况复杂度差异3.1 网络题里最喜欢挖的TCP的TIME_WAITTCP题目里出现频率最高的坑之一是TIME_WAIT。简单说主动关闭连接的一方在发送完最后一个ACK之后会进入TIME_WAIT状态并等待2MSL最大报文段生存时间后才完全关闭。为什么要等这么久主要是为了防止最后一个ACK丢失如果被动关闭方没有收到ACK它会超时重传FIN主动方必须留有足够时间来处理这个重传另外也能让旧连接中迟到的重复报文在网络中自然消亡避免干扰使用相同四元组的新连接。选择题里常见的错误选项是“进入TIME_WAIT的是收到FIN的一方”或“TIME_WAIT只持续1MSL”。如果你不了解主动关闭和被动关闭的角色很容易被绕进去。另一个关联考点是大量短连接同时关闭时服务端如果作为主动关闭方可能出现大量TIME_WAIT连接导致端口被占满这也是后台开发实际工作中会遇到的性能问题笔试考到也不算超纲。3.2 数据库题里喜欢挖的隔离级别与幻读数据库的隔离级别同样是必考题。四种隔离级别——读未提交、读已提交、可重复读、串行化——分别对应的并发问题脏读、不可重复读、幻读需要背得滚瓜烂熟。笔试中一个高频陷阱是关于MySQL的默认隔离级别InnoDB引擎默认是可重复读很多人默认“可重复读只能防不可重复读不能防幻读”但实际上InnoDB通过间隙锁和next-key lock在可重复读隔离级别下也能阻止幻读的发生。这道题如果出成多选题选项里说“MySQL默认隔离级别下不存在幻读问题”很多人会因为概念模糊而不敢选。建议在复习时把“脏读、不可重复读、幻读”三个词和对应的解决机制做成一张对照表反复记忆。同时理解锁机制的基本原理记录锁锁住一行间隙锁锁住一个范围next-key lock是前两者的结合锁住“行加上前面的间隙”。这样不管题目的措辞怎么变你都能判断出最终效果。3.3 基础题里的“选择题技巧”选择题并不是只能靠硬知识还有一些实战技巧可循。拿到一道不会的题先排除明显错误的选项再通过“极端情况代入法”验证剩余选项。比如考复杂度可以把n10^5代入选项看哪个数量级最合理考数据结构可以拿一个最简单的用例空链表、单节点树、全相同元素数组去验证选项描述是否成立。这个方法尤其适合不定项选择——宁可少选不要错选因为多选和错选通常都不得分。还有一点笔试选择题中偶尔会出现“每题多选”的情况审题时必须先看清是单选还是多选别用默认的“单选思维”去应付多选题。我在模拟练习中做过不少粗心题几乎都是在这里丢的分。4. 后台场景设计题从需求到落地的答题框架场景设计题是后台业务开发岗笔试里很有意思的一环它不像算法题那样有固定答案而是在考察你面对一个真实业务问题时的思考方式。腾讯音乐的业务属性很强题目很可能会从音乐播放、歌单、排行榜、用户画像等场景出发。我整理了一套从需求到落地的答题框架这里详细拆一下。4.1 需求边界分析先把问题定义清楚拿到场景题第一件事不是画架构图而是把需求边界问清楚。比如“设计一个播放量排行榜”你需要先明确几个问题排行榜是实时还是离线榜单范围是全国还是分地域榜单周期是小时、天还是周排行的指标是播放次数还是独立用户数允许的延迟是多少在笔试里你要在有限时间内把这些假设写在答案最前面这会向面试官传递一个信号你具备需求分析能力而不是拿到需求就埋头写代码。我当时给自己定了一个套路先是用两三句话描述“这个系统要解决什么问题、服务对象是谁、核心指标是什么”再列出“非目标”例如暂时不做的东西最后才进入数据估算和存储设计。4.2 数据估算所有设计的起点数据估算是场景设计题中区分度很高的一环。拿“最近7天播放量Top100歌曲榜单”举例假设日活跃用户DAU是1亿每个用户平均每天听20首歌那么一天产生的播放记录就是20亿条一周就是140亿条。存储上如果每条播放记录需要100字节左右的原始日志那一天的日志量就有接近200GB。这个估算本身不需要太精确关键是展示你具备从业务指标推导数据规模的意识。基于这个量级全量排序显然不现实所以核心思路应该是“分而治之”每天对歌曲的播放次数做聚合统计生成一个当日统计结果查询7天榜单时只需要合并这7个统计结果再进行排序。这样需要处理的数据量就从百亿级别降到了百万甚至十万级别。我用一个简单的计算举例如果全站歌曲数量有5000万首活跃歌曲每首歌每天用8字节存储播放次数一天的核心统计结果才400MB。再进一步如果你只需要Top100甚至可以只保留每首歌7天的统计结果最终排序时只需要比较这5000万首歌的7日播放量如果数据再大还可以用“大根堆只保留前100”的方式把内存占用控制在极小范围。这就是典型的时间换空间、空间换时间的权衡。4.3 存储选型MySQL、Redis还是消息队列存储选型是场景题里必须回答的问题。我的通用做法是核心业务数据放MySQL热点数据和高并发读取用Redis异步解耦用消息队列。以排行榜为例播放行为先写入消息队列由消费端异步聚合并写入Redis的有序集合ZSet以歌曲ID为member、播放次数为score这样查询Top100只需要一条ZREVRANGE命令耗时在毫秒级。统计数据再定期以异步任务的方式落库到MySQL用于历史查询和数仓分析。这里有一个容易被忽略的点Redis的ZSet在元素数量特别多时虽然读写仍是O(log n)但内存占用会显著增加。如果歌曲量极大可以考虑对歌曲进行分桶比如按首字母分桶或按热度分层热门歌曲单独一个桶、长尾歌曲进另一个桶查询时合并各桶的Top100。这种“分桶合并”思想在后台开发里很常见笔试能写出来会是加分项。4.4 缓存与降级体现你的工程经验场景题要拿高分除了结构完整还要有一些工程上的细节思考。缓存策略可以说是最加分的一项。排行榜场景里如果每次都实时查Redis、再合并排序QPS每秒查询数高的时候仍然会打满资源。更稳妥的做法是排行榜结果做成二级缓存——本地缓存一份例如5秒过期Redis里保存聚合后的全量榜单再从Redis同步一份到本地缓存。读请求优先打本地缓存只有缓存过期了才回源Redis这样可以大幅降低对Redis的压力。降级策略也需要提一笔。比如下游统计服务发生抖动排行榜直接返回旧版本数据并打上“更新时间”标记而不是把错误展示给用户。这种对“可用性优于一致性”的取舍正是后台业务开发区别于纯算法题的重要能力点。5. 做题节奏与写给后来者的几个提醒整场笔试下来我对做题节奏的感悟最深。120分钟的时间看似宽裕但如果你选择题琢磨太久、第一道编程题写完调了半天后面的压力会滚雪球一样增大。以下是我复盘后认为最合理的时间分配方案供参考时间段任务策略前10分钟快速浏览全部题目标记每道题的难度等级不在一道题上停留第10-40分钟完成选择题不会的先蒙一个标记下来不恋战第40-75分钟编程题第1题和第2题先写暴力再优化保证前两题尽量接近满分第75-100分钟编程题第3题先写暴力版本拿部分分剩余时间再想正解最后20分钟场景设计题按“需求→估算→选型→扩展”框架写答案不要求过于精细剩余时间检查所有题目代码重点检查输入输出格式、边界用例有几个非常细节但极其影响结果的提醒我想单独列出来。5.1 输入输出处理看起来简单最容易翻车笔试时编程题的输入输出格式不会像LeetCode那样给你封装好你需要自己写完整的IO。以Java为例优先使用BufferedReader和StringTokenizer处理大量输入而不是Scanner因为在数据量达到十万、百万级别时Scanner的性能差距非常明显。C就记住三行ios::sync_with_stdio(false); cin.tie(nullptr);Python里则用sys.stdin.buffer.readline()而不是input()。这三行代码几乎可以当成笔试必备模板提前准备好。另外一个很容易翻车的点是有些题目要求输出浮点数并指定保留几位小数或者要求答案对某个模数取余。审题时如果看到这类描述必须严格按照要求格式输出否则即使逻辑全对判题也会报错。我在模拟练习里就遇到过因为少了一个换行符而全盘判错的情况这种低级错误在真正的笔试里是致命的。5.2 离线环境的适应别依赖自动补全牛客笔试的在线编辑器功能比较基础没有本地IDE那么强大的自动补全、多文件组织和重构功能。如果你习惯了在IntelliJ IDEA或VS Code里写代码第一次切换到在线编辑器会有一种“裸写”的别扭感。我建议在笔试前至少花3-5个小时直接在牛客或者同类平台做模拟题完全不用本地IDE。这个过程能帮你熟悉在线编译器的快捷键、错误提示方式以及最关键的——“在不太舒服的环境下依然能快速写出正确代码”。另外笔试过程中千万不要频繁切换浏览器窗口。考试系统会记录切屏次数超过阈值可能被判定为作弊。如果实在需要看在线文档尽量在笔试开始前就准备好别在考试中去查基础API。5.3 笔试只是第一关精力管理别忽视腾讯音乐春招的流程里笔试之后还有面试整个招聘流程可能持续两周甚至更久。笔试本身虽然重要但你不需要在这120分钟里把自己所有的精力榨干。我的经验是笔试前一天保证睡眠考试过程中保持清醒的头脑比临时抱佛脚多刷几道题更有价值。很多人在第三道编程题上死磕半小时结果不仅没想出来还影响到后面场景设计题的输出质量这就是典型的精力分配失误。我个人的做法是如果一道算法题15分钟内没有任何思路直接把暴力版本写好提交然后跳到下一题。暴力分拿到就是赚到死磕失分才是真的亏。等到所有题目都有一版答案之后如果还有剩余时间再回头慢慢优化难一点的题。5.4 笔试后的复盘与后续准备笔试结束不代表任务完成当天最该做的是把题目回忆一遍整理出自己哪些地方薄弱。如果选择题里网络相关的题错得比较多那面试准备阶段就应该重点补TCP和HTTP如果编程题第三题卡在树结构上那后续就可以专门刷一刷DFS序、树状数组和线段树的题目。这种“以考促学”的复盘方式效果通常比盲目刷题好得多。另外笔试中你写的代码如果有自己都觉得笨拙的实现建议考后重新用更优雅的方式实现一遍。这个过程不仅提升编码能力也是为面试中的“手撕代码”环节做积累。很多面试官会问你项目里用过哪些数据结构和算法你说得越熟练越能体现出笔试成绩不是靠运气得来的。