春招季刷题的人多了各种笔试卷子也跟着流传开来。前几天有读者给我发了一份“映客2020春招研发B卷”说想让我聊聊这套题背后到底在考什么。我仔细看了一遍发现这套卷子挺有代表性的——它不像某些大厂A卷那样追求偏题怪题而是把重心压在计算机基础、算法编码和直播业务场景的结合上。如果你正准备投直播类公司的研发岗或者在准备春招笔试阶段这篇文章应该能帮你少走不少弯路。我会把卷子里可能出现的题型分布、每类题的考察意图、答题时的思路链路以及做完后对面试的参考价值逐个拆开讲清楚。1. 拿到B卷后的五分钟先看懂这套题的出题逻辑1.1 试卷结构与考察目标定位研发岗的笔试卷子表面看是考知识点实际上考的是“你在真实开发环境里能不能上手干活”。映客作为直播平台它的研发团队每天面对的是高并发消息、音视频流处理、弹幕实时推送这类场景所以B卷的题目设计会有很明显的业务倾向性。从这类试卷的整体结构来看一般会分四块计算机基础客观题选择题为主、数据结构与算法编程题手写代码、专业方向题Android/iOS/服务端任选、以及一小部分与业务场景结合的开放题。B卷相比A卷通常难度略低一些但覆盖面更广它更看重基础扎实度和思维完整性而不是偏门技巧。我当时拿到卷子没有急着做题而是先花五分钟把整张卷子扫了一遍。这个动作很关键。它能让你快速判断哪些题是送分题哪些题需要花时间哪些题可能做不出来但可以拿步骤分。比如我看到选择题里有一道关于TCP握手过程的题这就是基础分看到一道LRU缓存设计的编程题这就是需要认真写的部分看到一道关于直播弹幕高并发推送的开放题这就是拿分差距的地方。1.2 B卷与A卷的定位区别很多人会纠结B卷是不是比A卷差其实不是。A卷通常用于技术岗的核心批次招聘题目偏深偏难倾向于考察算法功底和底层原理B卷则更贴近“工程能力”的检验题目覆盖范围更广难度更平均。对投递映客这类中大型互联网公司的研发岗来说B卷的区分度其实很高因为它把“知不知道原理”和“能不能解决实际问题”分得很开。比如同是考察线程A卷可能会让你手写一个无锁并发队列B卷则可能给你一个场景让你分析多线程同时读写一个共享变量会导致什么问题以及怎么解决。前者考功底后者考应用。B卷更看重后者因为实际开发中不会让你从零写无锁队列但你会经常遇到共享变量被多个线程同时操作的bug。2. 基础模块的送分题与陷阱题最容易拉开差距的选择题2.1 数据结构考点不是背定义而是会选型这类笔试卷的数据结构题通常会围绕着几个核心考点反复出数组与链表的区别、栈和队列的应用场景、二叉树的各种遍历方式、哈希表的冲突处理、堆的调整过程。表面上这些题是在问“链表的插入复杂度是多少”实际上考的是你在不同场景下能不能选对数据结构。比如直播间的在线用户列表用什么样的数据结构维护最合适如果做的是频繁的增删操作数组的扩容和搬移成本很高链表更合适但如果还需要频繁随机访问某个用户的信息单纯链表就显得力不从心这时候可能需要字典加双向链表的组合类似LinkedHashMap的思路。我记得这类卷子里有一道经典陷阱题给出一段代码让判断输出结果。代码里用HashMap存了自定义对象但没有重写hashCode和equals方法。很多基础不扎实的人会想当然地认为HashMap可以直接用对象当key结果取出来却是null。这个问题在实际开发中太常见了做直播项目的时候如果用用户ID对象的引用做map的key一旦对象被重新创建就会查不到数据必须重写hashCode和equals。2.2 操作系统考点从进程线程到死锁操作系统这块B卷的选择题喜欢从这几个角度切入进程和线程的区别、上下文切换、进程间通信方式、死锁的产生条件与解除办法、虚拟内存和分页机制。这里有一个特别容易搞混的概念——并发和并行。并发是多个任务在同一个CPU核上交替执行并行是多个任务在不同CPU核上同时执行。笔试时可能会给一个场景一个双核CPU的机器上跑两个线程问它们是并发还是并行。答案是既可能并发也可能并行取决于操作系统如何调度。这个点如果你只背了定义没理解调度机制很容易选错。死锁这块四个必要条件互斥、持有并等待、不可剥夺、循环等待是必背的但B卷很少直接让你默写更多是给你一段代码场景让你判断是否可能死锁。比如两个线程各自持有一把锁然后互相等待对方释放这就是典型的死锁场景。解决思路通常会考“按固定顺序加锁”或“使用tryLock设置超时”这类手段。2.3 计算机网络考点直播场景反复出现的TCP与HTTP网络题应该是整张试卷里和业务结合最紧的部分。直播平台的核心链路包括推流、拉流、信令交互这些都是基于TCP和HTTP协议的。所以B卷的网络题基本都会围绕TCP握手挥手、HTTP请求响应模型、HTTPS的加密过程来出。TCP三次握手的过程属于必考题但B卷会加一个“为什么”的追问为什么是三次而不是两次答案不是简单的“确认双方收发能力”而是要能说清楚三次握手可以把双方的初始序列号同步好防止历史连接的重复请求突然到达导致状态混乱。HTTP这块需要区分HTTP/1.1和HTTP/2的区别。直播场景里大量使用HTTP/1.1做接口请求但它的队头阻塞问题会导致慢请求阻塞其他请求HTTP/2通过多路复用缓解了这个问题但TCP层的队头阻塞依然存在。这个问题如果你能答出来会是个加分项因为它说明你不只是知道协议名还理解协议背后的瓶颈。2.4 细节陷阱容易被忽略的边界条件选择题里最烦人的是对细节的考察。比如数组下标越界、整数溢出、空指针、死循环——这些在刷LeetCode时不注意笔试时就会吃大亏。举一个典型的例子一段二分查找代码问你当目标值不存在时循环结束后left和right的位置关系。如果你没有手写过二分查找的边界条件很难记住left最后是第一个大于目标值的位置right是最后一个小于目标值的位置。笔试时把边界情况标注出来平时刷题时多关注这类题靠的是做题习惯的积累。3. 编程题实战拆解从读题到AC的完整思维链路3.1 常见算法题类型与解题切入点编程题是这类卷子的重头戏也是区分度最大的部分。从历年情况来看B卷的编程题基本不会逃出这几类字符串处理、数组与哈希表、链表操作、二叉树遍历、动态规划入门、以及一些模拟类型的题。遇到一道编程题正确的读题姿势应该是这样的先确定输入输出的数据范围再根据数据范围猜测期望的时间复杂度然后选择合适的数据结构和算法。比如输入规模是10^5那O(n^2)的算法大概率会超时需要往O(n log n)的方向想如果输入规模是10^3O(n^2)可能还能接受。举个例子假设有一道题是“给定一个整数数组找到两个数使得它们的和等于目标值”。基础做法是双重循环时间复杂度O(n^2)。但如果数据范围大就需要用哈希表遍历数组时把“目标值减当前值”存为key当前索引存为value这样一次遍历就能找到结果时间复杂度降到O(n)。这个思路很经典笔试时碰到“找两个数和为目标值”这类描述第一反应就应该是哈希表。3.2 手写代码的规范性看得见的步骤分笔试的代码题尤其是在线OJ模式往往只看运行结果但如果是人工阅卷代码的规范性就非常重要。变量命名要有意义、关键逻辑要有注释、边界条件要处理到位这些都是在拿步骤分。比如写链表相关的题目时很多人会忘记处理头节点为空的特殊情况。一旦链表为空调用head.next就会抛空指针异常整个程序直接崩掉。这种错误如果是在本地面试面试官可能还会提醒你但在笔试环境下系统只认结果跑不过就是跑不过。我记得一个很实用的建议写代码前先花30秒把思路列成三步。第一步做什么、第二步做什么、第三步做什么写到注释里。这样即使最终代码有小bug跑不过全部用例阅卷人也能看到你的思路是清晰的。3.3 动态规划题从暴力递归到DP表的推导过程动态规划是很多人的老大难但在B卷里DP题通常不会太难最多到“最长公共子序列”或“爬楼梯变种”这个难度。遇到DP题我的习惯是先写暴力递归再从递归中抽象出状态转移方程。比如爬楼梯问题第n阶只能从第n-1阶或第n-2阶上来所以dp[n] dp[n-1] dp[n-2]初始条件dp[1]1、dp[2]2。这个过程看似多此一举但对解复杂DP题特别有效因为它能帮你理清状态是怎么转移的。如果暴力递归会超时就加上记忆化搜索用一个数组保存已经计算过的结果。笔试时如果时间紧张记忆化搜索是性价比很高的方案它比完整DP表更容易写对。3.4 特殊情况处理输入校验与异常抛出编程题里有一类坑不是算法复杂度的坑而是输入校验的坑。题面可能说明输入是合法的但有时会隐含一些坑比如字符串可能包含空格、数组可能为空、数字可能为负数。处理这些情况的建议是在拿到输入后的第一时间就把边界情况处理掉。如果读入的数组为空直接返回0或空列表如果目标值不存在返回题目要求约定的值。这些代码虽然简单但能避免在运行时报错尤其是某些OJ系统对空指针异常特别敏感一个小异常就能让整道题判零分。4. 直播业务场景下的专业题Android/iOS/服务端怎么答才不跑题4.1 Android方向从四大组件到内存优化B卷选做部分的专业题是给不同方向的同学准备的。如果你投的是Android岗大概率会遇到四大组件运行机制、Handler消息机制、ListView/RecyclerView的复用原理、内存泄漏场景分析这些题目。Handler消息机制是Android面试的高频题笔试也喜欢考它。核心是Loop、MessageQueue和Handler三者之间的关系Looper负责从MessageQueue里取消息Handler负责发送消息和处理消息。这道题的关键不是背出流程而是能画出消息从发送到处理的完整链路并说清楚主线程和子线程之间的切换原理。内存泄漏这块比较容易出的场景是Activity被销毁后异步任务还持有Activity的引用导致Activity无法被回收。解决办法是把异步任务改成静态内部类加弱引用或者在onDestroy时取消任务。这道题如果只是回答“用弱引用”还不够最好能把WeakReference的使用场景说清楚以及为什么不推荐直接在全项目里滥用弱引用。4.2 服务端方向高并发与缓存穿透服务端方向的题目和映客的业务贴合得更紧。直播平台有大量用户同时在线对服务端的压力非常大所以试卷里的服务端题绕不开高并发处理、缓存设计、消息队列、数据库分库分表这些话题。缓存这块有一个必考的概念——缓存穿透。外部恶意请求不断请求一个缓存和数据库里都不存在的数据导致每次请求都打到数据库上数据库压力骤增。解决思路一般是布隆过滤器或者缓存空值。布隆过滤器的原理是用多个哈希函数把一个key映射到一个很长的二进制向量上判断key是否存在时只要有一个哈希位置上是0就说明key一定不存在。它能判断“一定不存在”但可能有误判说“可能存在”。消息队列的作用也很值得认真回答。直播平台的弹幕如果直接走数据库写入瞬间的高并发就会拖垮数据库。正确的做法是先写入Kafka这类消息队列再由消费者异步批量落库。这样既保证了消息不丢失又把高峰流量削平了。这道题答得好不好取决于你能不能讲清楚削峰填谷的真实含义。4.3 开放题如何设计一个直播弹幕系统B卷的开放题往往是最有意思的它没有一个标准答案但非常能体现一个候选人的综合能力。一道场景题往往是这样如何设计一个支持百万用户同时在线的弹幕系统。答这种题需要有自己的分析框架。我的建议是先拆分功能模块再考虑技术选型最后谈优化方案。功能模块上弹幕系统需要包含弹幕发送接口、弹幕分发系统、弹幕存储系统。发送端用户发一条弹幕通过API网关接入后端校验内容合规性然后把弹幕写入消息队列同时推送给当前直播间的在线用户。存储层面按照房间维度存储弹幕记录方便回放时拉取。技术选型上实时性要求决定了不能全走HTTP轮询而是要用WebSocket长连接来做服务端推送。每个直播间对应一个房间ID服务端维护一个房间ID到连接会话的映射关系。当用户加入直播间时注册连接退出时注销连接。优化方向上可以谈消息聚合和限流策略。弹幕量特别大时不需要每条消息都推送给所有客户端可以做一个聚合窗口比如把100毫秒内的弹幕打包成一条推送减少网络开销。发送端限流则可以用令牌桶算法或滑动窗口控制单个用户的发送频率避免有人刷屏。4.4 开放题的答题思路结构完整比追求完美更重要如果题库里有“给出你的思路”这类的开放式问题记住一个原则完整比完美重要。把方案的结构搭出来让阅卷人知道你有系统设计的能力比纠结某个细节对不对更重要。比如问“如何优化直播卡顿问题”你可以从三端拆解推流端、分发端、播放端。推流端要关注码率自适应和编码参数调优分发端要用CDN边缘节点就近分发播放端要做缓冲策略和丢包重传。这三个层次一展开整个回答的结构就很清晰即使细节不够精确至少说明你有全局观。5. 时间分配与做题策略120分钟怎么安排才不慌5.1 做题顺序选择题、编程题、专业题的优先级一张卷子通常120分钟题目量不小。做题顺序的建议是先做选择题再做编程题最后做专业题和开放题。因为选择题是拿分最稳的部分编程题需要的思考时间最长专业题和开放题主要看思维框架留个20到25分钟作答即可。选择题部分尽量控制在30到35分钟内完成。先把会做的迅速做完遇到卡壳的题先标注跳过不要在同一道题上纠结超过两分钟。等全部做完一轮如果有剩余时间再回来啃刚才跳过的题。编程题建议留足40到45分钟。如果有两道题先做自己最熟悉的那道保证有一道AC的把握再尝试第二道。千万不要在第一道编程题上死磕太久一旦超过20分钟还没有思路就果断换题。考试的目标是总分最大化不是单题完美。专业题和开放题留20到25分钟就够了关键在于输出框架而不是写论文。5.2 时间不够时的取舍拿步骤分的技巧笔试最怕的是一道题卡住心态崩掉后面全乱。如果编程题AC不了也要尽量写对思路。有些系统会按“通过的测试用例比例”给分暴力解法跑通一部分用例也能拿到部分分数。另一个技巧是把复杂题分解成小函数来写。比如做动态规划题时先写状态转移方程注释再写初始化代码最后写循环。即使最终结果有一点误差阅卷人也能看出来你是理解了这个模型的只是某个细节写错了这比毫无思路的白卷好太多。5.3 考前准备清单刷题之外还需要看什么考前一周除了刷题还需要做三件事第一把常见数据结构的复杂度表格再过一遍数组查找、链表的插入删除、二叉搜索树的平均和最坏情况复杂度这些选择题高频考第二把TCP挥手的状态变迁图自己动手画一遍确保能默写出来第三去了解目标公司的业务产品比如映客的直播App有哪些功能模块这些在回答业务场景题时会有帮助。如果你连目标公司的产品都没用过建议下载下来体验一下。尤其是互动功能、直播功能、送礼功能这些都能直接对应到笔试题里的业务场景。体验一遍之后再去聊弹幕系统的设计聊直播卡顿的优化你会明显感觉自己能站在产品的角度看问题而不是单纯背技术答案。6. 从笔试卷到面试题的延续这份卷子教会我的事6.1 笔试中暴露的问题往往是面试官追问的切入点笔试不只是流程的一环它本身就是一次预演。你笔试里做错的题、没答好的开放题很可能就是你面试时会被追问的问题。因为面试官能看到你的笔试成绩他们会针对你的薄弱点进行提问看你是否在笔试后做了复盘。所以做完笔试卷不要对完答案就抛到脑后。花20分钟把错题整理一下尤其是选择题里搞混的概念一定要回头查清楚。我见过不少候选人笔试表现一般但面试时能把自己犯错的原因分析得很透彻这种复盘能力反而让面试官刮目相看。6.2 从考试思维转换到工程思维准备笔试和真正做工程是两个维度的能力。笔试时知识点是点状的你能说出HashMap的原理但不一定能设计好一个直播间的在线用户管理模块。工程思维是指你能根据实际场景选择合适的方案并考虑扩展性、维护性和容错性。所以在复盘笔试卷时可以尝试把每道题做一个“场景迁移”这道题讲的HashMap在直播业务里哪里会用上这道题讨论的死锁在服务端开发中怎么避免这样的思考方式能让你从“应付考试”转化到“积累能力”对后续的职业发展也更有价值。6.3 长期备考的价值不是为了一场笔试说句实在话哪怕你现在只是为了映客的这场笔试准备但把那些知识体系和解题思路理顺了对你后续所有面试都是加分的。因为研发岗的技术栈是相通的数据结构和算法、网络、操作系统、数据库这些底层知识是所有互联网公司的硬通货。这套卷子的核心意义不在于你能得多少分而在于它检验了你作为研发人员的基本素养——你是否能理解底层机制、是否能选择合适的结构方案、是否能应对真实业务场景下的技术挑战。把这些能力修炼好了不管去哪家公司你都不会慌。