说实话看到“欢聚时代2018校招笔试题-C/C 音视频传输/推荐算法/测试开发 B卷”这个标题的时候我第一反应是有点怀念。那会儿直播行业正打得火热欢聚时代也就是YY母公司的校招题基本就是当年行业技术风向标的缩影。C/C、音视频传输、推荐算法、测试开发这四个关键词放在一张卷子里乍看有点杂但如果你真的在音视频或直播行业待过就会明白这其实是一条完整的业务技术链条底层用C/C做高性能传输中间用算法做内容分发最后靠测试开发来保障质量。这篇文章我想站在一个参加过类似校招、后来也做过几年音视频开发的从业者角度把这份B卷背后真正想考察的东西拆开揉碎讲清楚。不论你是正在备战校招的应届生还是打算转行进入直播、音视频、推荐系统领域的技术人这份拆解都能帮你理解大厂笔试题不是用来“考倒你”的而是用来筛选“能不能接住真实业务问题”的人。1. 试卷整体观察三个方向背后的业务逻辑1.1 为什么C/C、音视频、推荐、测试开发会出现在同一张卷子里很多人拿到这类多方向混合卷第一反应是“公司是不是随便拼的题”。实际上欢聚时代当时的核心业务是直播和短视频这几个方向恰恰是直播平台最核心的技术骨架。直播业务最底层是音视频链路采集、编码、推流、传输、拉流、解码、渲染这一整条链路对性能和延迟的要求极高C/C几乎是唯一主流选择。Java和Python在这条链路上当然也能写但涉及到内存直接操作、硬编硬解API调用、底层网络库调优时C/C的地位仍然不可替代。所以C/C和音视频传输放在一起考本质是在筛选“能做底层基础设施”的人。推荐算法则是另一条线。直播平台内容那么多用户凭什么点进某个直播间靠的是推荐系统。这个岗位不需要你动音视频数据但需要你有扎实的机器学习基础、数据处理能力和工程落地能力。而测试开发岗位在直播业务快速迭代的背景下要解决的是“怎么保证频繁发版不出事故”的问题这需要懂代码、懂自动化、懂流程。一张卷子覆盖三个方向说明这家公司那个阶段的招聘逻辑是“按业务需求招人而不是按语言招人”。你不需要三个方向都精通但你必须能看懂这张卷子背后企业到底在为什么业务问题招人。1.2 B卷的设计潜台词笔试不是知识竞赛是业务代入感测试如果你仔细研究过欢聚时代、包括其他几家直播大厂当年的笔试题会发现一个特点大多数题目不会直接问你“RTP协议默认端口是多少”这种背诵型问题而是会给你一个场景比如“直播间出现卡顿你会从哪些层面排查”。这种题目考察的不是记忆而是你有没有在真实业务场景中思考过问题。B卷的“B”通常和A卷做区分常见情况是所有非技术岗或部分技术岗共用一套题也可能是不同岗位方向的题混合在一起。但不管它怎么分的核心逻辑是一致的笔试想在短时间内判断你对“真实业务链路”的理解深度。所以你在答题时不要只写知识点要写你如何用这个知识点去解决一个具体业务问题。1.3 透过岗位分工看技术选型C/C方向的人未来大概率会去写推流服务、媒体网关、播放器内核这类底层模块。推荐算法方向的人会去搭建召回、排序、特征平台这类数据链路。测试开发方向的人会去搭建自动化测试框架、性能压测平台、CI/CD基础设施。这三个岗位表面上是完全不同的职业路径但它们有一个共同底层要求工程能力。C/C方向的工程能力体现在内存管理和并发控制推荐算法方向的工程能力体现在数据管道和模型服务化测试开发方向的工程能力体现在对研发全流程的理解。所以整张卷子无论哪个方向的题最后都在考察一件事你能不能在公司现有的技术体系里独立干活。2. C/C方向核心考点与答题策略2.1 别忽略环境配置这门“隐形考题”很多应届生准备C/C笔试时只刷算法题忽略了开发环境本身。等到真正上机写代码时才发现连编译命令都不熟或者代码在Windows上能跑、一上Linux就崩。2018年那会儿还没有现在这么多一键配置的IDE很多人在本地用Visual Studio写得好好的笔试现场用的是Linux环境一套gcc编译直接暴露基本功。我给你的建议是准备C/C方向先把自己的日常练习环境切成Linux VSCode gcc/clang。Windows下如果非要用也可以配置MinGW-w64并手动添加环境变量但最终笔试和面试的代码考核大概率是在Linux环境里。提前熟悉gcc的常用参数比如-Wall开启警告、-g生成调试信息、-O2优化等级熟悉gdb的基本断点、查看变量、查看堆栈操作这比多刷十道题都重要。还有一个很多人会忽略的点C和C的编译器路径问题。有些人在VSCode里配置C/C插件时会遇到“C和C编译器路径不一致”的报错直观表现是C文件编译正常、C文件编译失败。原因通常是c_cpp_properties.json里的compilerPath配置只指向了gcc没有切换到g。这类问题在笔试现场一出现就非常浪费时间。所以平时把环境问题彻底搞定考场上才能心无旁骛。2.2 指针、内存、并发C/C岗的三大“生死题”C/C方向的笔试题如果让我划重点我会把90%的精力放在三类问题上指针与内存管理、并发与线程同步、网络编程。这不是巧合而是音视频后端开发每天都要面对的核心问题。指针与内存管理方面常考的包括堆和栈的区别生命周期、分配效率、大小限制、野指针和悬空指针怎么产生、内存泄漏怎么定位、unique_ptr/shared_ptr/weak_ptr的原理和选型、深拷贝与浅拷贝、struct内存对齐。这些题看起来基础但非常能区分“背过八股”和“真的写过”。比如问“shared_ptr循环引用怎么解决”如果你只回答“用weak_ptr”我通常还会追问“底层引用计数是怎么维护的”这一问就能看出来你有没有自己实现过智能指针。并发方面常见考点包括mutex和spinlock的适用场景、条件变量为什么必须配合mutex使用、原子变量的底层实现CAS还是总线锁、死锁的四个必要条件、读写锁和互斥锁的性能对比。你在答题时最好能结合场景举例比如“在音视频采集线程和编码线程之间传递数据用无锁队列还是互斥锁”这种结合实际业务场景的回答比单纯罗列定义有说服力得多。2.3 STL选型与算法题你的选择会暴露你的水平STL是C/C笔试里的“送分题”也是“送命题”。vector的扩容机制一般是1.5倍或2倍不同编译器策略不同默认的std::vector每次扩容会搬移所有元素、map和unordered_map的底层数据结构红黑树 vs 哈希表、list为什么不适合频繁随机访问这些如果你只看过结论没看过源码遇到变体题时很容易翻车。算法题方面2018年直播行业正处于风口笔试题里经常会出现一些“直播场景题”。比如海量日志里统计某个用户的上麦时长、设计一个直播间弹幕的TopK热词统计、实现一个LRU缓存管理用户最近观看记录。这些题本质上还是数据结构题但包装了业务场景答的时候你可以多一步点明你选择的数据结构为什么适合这个业务场景。举一个例子LRU缓存你用“哈希表双向链表”实现为什么不用数组因为直播场景中“最近观看”是一个频繁更新的列表数组的插入删除是O(n)而双向链表加哈希表能稳定做到O(1)。这种回答能体现你不只是会背模板而是理解了数据结构对业务的适配。2.4 网络编程基本功socket、epoll、定时器音视频传输方向如果考C/C几乎一定会涉及网络编程。常见题目是让你实现一个简单的TCP回声服务器或者问select、poll、epoll三者的区别。你需要答清楚select有FD_SETSIZE限制默认1024每次调用都要把fd_set从用户态拷贝到内核态epoll通过红黑树维护监听集合通过就绪链表返回活跃fd避免了遍历全部fd的开销而且支持边缘触发模式。更进阶一点的题目会考定时器实现。比如一个直播服务需要做超时管理客户端心跳超时踢掉、推流中断检测你会用最小堆、时间轮还是红黑树如果让我答我会分析三种方案最小堆实现简单插入和删除O(logn)时间轮插入删除O(1)但精度受槽位大小限制红黑树稳定但实现复杂。实际线上服务经常用“最小堆时间轮”的组合笔试时你能答出这个方案演进的基本取舍就已经领先很多人了。3. 音视频传输方向从码率计算到弱网对抗3.1 “送分”的计算题码率、帧率、分辨率之间的关系音视频方向的笔试题里计算题往往是整个人最放松的环节因为公式固定、逻辑清晰。比如给你一个分辨率为1920x1080、帧率为30fps的视频流采用YUV420颜色采样每个像素平均12bit让你计算原始视频的码率。这时候你的计算过程大概是1920乘以1080算出每帧约207万个像素乘以12bit得到每帧约24.8Mbit再乘以30fps得到原始码率约745Mbps。算完这个数你再对比H.264编码后通常只有2到8Mbps就能直观理解“压缩编码为什么是音视频技术的核心”。这类计算题不复杂但它考察的是你对数据量的“体感”。一个合格的音视频开发看到分辨率、帧率、像素格式脑子里应该能秒估出带宽需求。笔试现场做这种题我建议你不仅写结果还要把推导过程简要列出来因为阅卷人想看到你对原始数据量的直观感知而不只是套公式。3.2 直播协议选型RTMP、HTTP-FLV、HLS怎么选音视频传输的另一个高频考点是“推流和拉流协议选型”。RTMP基于TCP交互简单延迟可以做到2到5秒是早期直播推流的事实标准HTTP-FLV利用HTTP的兼容性避免RTMP的复杂握手更适合网页端拉流但延迟同样受TCP和缓冲策略影响HLS基于HTTP把视频切成多个小文件延迟通常在10秒以上优点是通过CDN分发非常成熟兼容性极好。笔试如果问“直播低延迟方案怎么设计”你可以从推流端和播放端两边展开推流端用RTMP或SRT基于UDP的可靠传输播放端用HTTP-FLV或WebRTC中间经过边缘节点做转封装和分发。如果能再补一句“WebRTC的UDP传输配合FEC和NACK延迟能压到1秒以内但弱网下的带宽自适应策略需要仔细调”这个答案就已经有工业级水平了。3.3 音视频同步PTS/DTS、音视频时钟对齐音视频同步是笔试中容易被忽略、但实际上特别重要的考点。直播场景里最常见的问题是画面和声音对不上。解决这个问题的核心思路是视频帧和音频帧各自有PTS显示时间戳播放器需要根据一个统一的时钟来调度显示。比较经典的做法是“以音频时钟为主时钟”因为人对声音的延迟更敏感。具体来说播放器维护一个audio clock每播放一个音频帧就更新当前播放时间视频帧根据PTS和audio clock的差值决定是立即渲染还是等待、丢帧。如果你答到这里可以补充一点对于直播场景音视频同步还需要考虑网络抖动所以播放器要有一个抖动缓冲jitter buffer同时要根据缓冲深度动态调整播放速度这又和弱网对抗策略挂钩了。能把这几个点串起来讲说明你是真的理解了一条完整链路而不是只背了“PTS/DTS”两个概念。3.4 弱网对抗丢包重传、FEC和自适应码率音视频方向面试官特别爱问“弱网场景怎么保证传输质量”。这个问题没有标准答案但你必须能梳理出几条清晰的思路丢包重传ARQ、前向纠错FEC、码率自适应ABR。ARQ的思路是发现丢包后请求重传适合低丢包率、低延迟场景代价是额外增加一个RTT的等待FEC的思路是发送冗余包接收方能直接恢复部分丢包代价是占用额外带宽ABR的思路是根据实时网络带宽调整编码码率比如实测带宽下降时把1080p降到720p以避免卡顿。笔试如果让你设计一个弱网下的推流策略我建议你给出组合方案先通过ABR控制码率再叠加FEC兜底轻量丢包重传只用来处理关键帧或重要数据。这种“分层应对”的思路远比单点方案更接近工业实践。在答这题时最好结合C/C的底层操作比如推流端要实时统计发送码率、RTT、丢包率这些数据用C/C做采集才能做到毫秒级缓存队列长度不能无限增长否则延迟越来越大需要在“缓冲足够对抗抖动”和“延迟不能太大”之间做权衡。这种讨论会让你的答案有工程深度而不是泛泛而谈。4. 推荐算法方向从公式推导到工程落地4.1 推荐系统架构题先画地图再答题推荐算法方向的笔试题最容易拿分但也最容易丢分的是一道架构题“请设计一个直播推荐系统”。很多应届生一上来就说“用协同过滤”“用DeepFM”但忽略了系统整体结构。一个完整的推荐系统应该包含数据层用户行为日志、物品信息、画像特征、召回层从海量物品中粗筛出几百个候选、排序层对候选做精排输出CTR/CVR预估分、重排层去重、打散、多样性控制、商业规则最后是AB实验平台验证新策略线上效果。你答的时候最好一层一层拆每一层说清楚输入和输出。我当时在笔试里遇到这道题时是先画了一个框架图然后针对每一层展开说明用什么模型、处理什么特征、解决什么问题。这样做的好处是阅卷人能一眼看到你有“系统思维”而不是零散地堆模型名字。4.2 召回与排序从协同过滤到CTR预估模型类题目里协同过滤和CTR预估模型是常客。问“协同过滤的原理和优缺点”时你要能说清楚User-Based和Item-Based两种思路的区别User-Based是找出和你口味相似的用户把他们喜欢的东西推荐给你Item-Based是根据你喜欢的物品找出相似物品推荐给你。还要能说出它们的局限冷启动问题、稀疏性问题、无法利用上下文特征。CTR预估模型推荐问“为什么现在工业界用GBDTLR或者DeepFM而不是单独用LR”。一个能加分的回答是LR简单、可解释性强、训练快但表达能力有限需要人工做大量特征交叉GBDT能自动发现高阶特征组合但无法处理高维稀疏特征DeepFM把FM的一阶特征和隐向量交叉能力与深度网络的非线性拟合能力结合起来是工程上比较实用的方案。你在回答时要考虑样本规模、训练时效、可解释性这些工程约束而不是单纯比较模型指标。另外建议你复习一下典型的概率统计题比如“用户平均在线时长服从指数分布求期望”“贝叶斯公式求后验概率”。这些题虽然看起来和推荐算法无关但其实是评估指标计算、AB实验显著性检验的基础。没有概率统计功底你很难真正理解AUC和置信区间。4.3 特征工程与评估指标容易暴露实战经验的部分推荐系统里特征工程决定了模型的上限因此笔试也爱考。常见的包括用户特征性别、年龄、地域、历史行为序列、物品特征直播分类、主播标签、当前在线人数、上下文特征当前时间、设备、网络环境。直播场景比较特殊的点在于直播是实时的和短视频不同特征强调“当前状态”比如主播正在播什么、当前热度怎么样所以特征延迟极其重要。评估指标方面AUC是最常用的离线评估指标它衡量的是模型排序能力随机抽取一个正样本和一个负样本模型给正样本打分高于负样本的概率。GAUC则是按用户分组后的AUC加权平均能避免“整体AUC虚高但每个用户内部排序很差”的问题。如果你答到AB实验可以提一下最小样本量计算、实验周期、置信度和p-value这些细节因为这些恰恰是工业界和学术界差异较大的地方。4.4 业务场景题给直播场景设计个性化策略最后一种高频题型是“开放设计题”比如“直播间推荐需要考虑什么特殊因素”。这时你可以从以下几个维度展开实时性用户正在看的直播可能是几分钟前开播的不能用离线特征处理、冷启动新主播没人气、新用户没历史、多样性不能连续推同一类直播、供需平衡推荐出去之后主播能承接收人自己也要考虑承接能力、商业因素广告位、付费礼物转化。这种题目考察的是你把算法放进真实业务里的能力而不是纯学术建模能力。你平时可以多思考一下如果给你一个直播平台的推荐位你会怎么设计规则和模型这种思维训练比背论文公式对笔试更有帮助。5. 测试开发方向笔试考的是有没有工程思维5.1 测试开发到底是干嘛的和测试工程师有什么不一样测试开发测开这个岗位很多人误解为“点点点”的手工测试。实际上测开的核心是“开发工具/平台来解决测试问题”。比如自动化测试框架、压测平台、CI/CD流程、日志分析工具、质量监控大盘都是测开写的。所以笔试时你的代码能力虽然不要求像纯开发那么深但工程基础必须扎实。测试开发学习路线大概可以这样走先掌握一门语言C/Python/Java均可然后是数据结构、操作系统、网络的基本功接着是测试理论测试用例设计、等价类划分、边界值分析再到自动化测试接口自动化、UI自动化、性能测试、持续集成。你对这条路线越清晰笔试答“你平时怎么测一个接口”这类题就越有底气。5.2 测试用例设计题分层思考比穷举更重要常见的测试设计题是“给一个登录功能设计测试用例”。新手往往会写很多“正确账号密码能登录”“错误密码不能登录”这类最表层的用例但资深测开会这么组织第一功能维度正常登录、异常密码、空值、超长字符串、密码错误次数锁定第二兼容维度不同浏览器、不同操作系统、不同分辨率第三性能维度并发登录、高频点击、弱网环境第四安全维度SQL注入、密码传输加密、验证码绕过第五异常恢复数据库宕机、网络断开后重新连接、服务端返回超时。这五种维度涵盖了功能、兼容性、性能、安全、容错答题时如果能量能按层组织说明你有系统思考能力而不是想到哪写到哪。笔试现场时间有限不用追求绝对完整但至少要体现“分层思维”。5.3 工程能力题SQL、shell、日志分析测开方向经常会有一些“给一段日志让你统计异常率”或者“写SQL统计充值金额TopN用户”的题目。这类题考察的不是深度而是你平时有没有真正处理过数据。比如给你一个Nginx访问日志每行包含IP、时间、请求URL、状态码、响应时间写一个命令统计状态码为500的请求占比。用awk加sort、uniq、wc组合很容易得出结果。你如果不会写就会白白丢分。我建议你系统学一下awk、sed、grep这三个文本处理工具再学一下SQL的group by、join、子查询、窗口函数基本就能应付大多数测开笔试了。另外测试开发会问“怎么保证一次发版上线不出问题”。这个问题能展开的点很多代码审查、单元测试覆盖率、接口自动化回归、监控告警、灰度发布、快速回滚。你如果能说出“灰度发布 监控大盘 自动回滚”的组合说明你真的懂线上风险控制。回答这类开放题时宁可讲得具体、有实操痕迹也不要泛泛说“要做好测试”。5.4 从传统测试开发到AI测试开发近几年热词里出现了“AI测试开发”这个方向已经开始进入笔面试视野。核心是用AI生成测试用例、用AI做缺陷预测、用AI做UI自动修复。比如给一个需求文档让大模型自动生成接口测试用例或者根据历史缺陷数据预测当前代码变更会不会引入回归。这类问题在2018年的笔试里几乎不会出现但现在聊测试开发已经绕不开了。我在实际工作中发现AI更多是辅助定位问题和生成脚本真正的测试设计思路还是要靠人来把关。如果你在笔试或面试遇到这个问题能从“AI辅助 vs 人工判断”的角度区分比盲目吹捧AI更有说服力。6. 从一份笔试题反推备战方法6.1 拿到试卷先别急着动笔时间分配是一种能力经历过笔试的人都会有这个感觉时间根本不够用。别人拿到卷子从头做到尾我拿到卷子会先花两分钟把题目扫一遍判断哪些题是送分题、哪些题是拔高题、哪些占分最大然后按性价比排序先把熟练的、分多的题做掉再做需要思考的题最后是开放性题目。选择题如果卡住超过两分钟直接跳过不要在个别题上消耗太多时间把后面的大题丢了。如果你发现自己擅长算法题就先做算法题保证拿到基础分如果你擅长开放性系统设计题就留足时间给大题。大多数校招笔试没有“必须按顺序做”的强制规定策略性跳过是聪明人做的事。6.2 刷题不是只看题解动手写才是真正的掌握刷题最常见的问题就是“看题解觉得自己懂了合上书自己写就卡壳”。我自己的经验是刷题要分三步第一步自己独立写卡住可以想十分钟第二步看题解理解为什么这么做第三步关掉代码从头再写一遍直到能一气呵成通过编译和测试用例。用这个流程刷下来的题远比一天看几十道题更有用。C/C方向尤其要重视“编译和运行”这最后一步因为很多内存类错误比如访问越界、指针悬空、内存泄漏不是看一眼代码就能发现的必须实际跑起来用调试工具去观察异常。笔试前至少熟练使用gdb或VSCode的调试功能能加断点、单步执行、查看变量地址和值这个技能在线上排查问题时也极其重要。6.3 项目经验从“会做”到“能讲清楚”很多应届生简历里写了项目但笔试和面试时讲不出来。实际上一个能讲清楚的项目比十个“简历上写了但说不明白”的项目更有说服力。不管你是做过音视频推流Demo、推荐系统小项目还是测试平台开发都要准备好回答以下问题项目的核心模块是哪些你负责的部分有什么难点你当时是怎么排查和解决的如果再给你一次机会你会怎么优化其中“难点 排查过程 最终方案”是最能体现技术深度的组合。面试官最怕听到“我这个项目用的是某某框架”但一问到原理和细节就开始含糊其辞。如果你没有项目经验我建议你从现在开始做一个“小而完整”的项目比如用C写一个简单的RTMP推流器或者用Python写一个基于协同过滤的电影推荐脚本或者用Selenium加pytest搭一个简单的UI自动化测试框架。不需要多复杂但要把技术链路走通把过程中踩的坑记录下来这些都会变成你的素材。6.4 从2018年到今天这类岗位的技术栈发生了哪些变化回头看2018年的校招题和今天的校招做对比能明显感受到技术趋势变化。音视频方向WebRTC的普及让低延迟互动直播成为标配SFU选择性转发单元架构逐渐替代传统的MCU架构音视频岗位对WebRTC、SRS、ZLMediaKit这类开源项目的熟悉程度要求更高了。推荐算法方向传统机器学习还在应用但深度学习模型已经成为默认选项特征平台和向量检索的权重越来越高。测试开发方向云原生和容器化让持续集成、持续交付变成标配测试平台不再是内部工具而是逐渐产品化。这份2018年的B卷放在今天当然不是“最新题库”但它背后的考察逻辑完全没有过时基础是否扎实、是否理解真实业务场景、是否有工程化思考。你如果能把这些基本功打牢不管技术栈怎么变你都能在笔面试中游刃有余。最后再分享一点我的个人体会笔试准备这件事本质上不是“刷题”而是在和出题人对话。你把一份卷子做透了你会慢慢感受到这家公司正在为什么业务头疼音视频传输考弱网说明他们在优化直播体验推荐算法考冷启动和实时性说明他们在做增长和留存测开考全链路质量说明他们在加速迭代。当你从“做题”切换到“和一家公司做技术对话”的视角后你对知识点的理解会完全不一样。如果你正在准备这类岗位我建议你把自己当成“这个方向半年后的工程师”而不是“刚毕业的学生”。按照这个标准去要求自己笔试、面试、甚至入职后的成长速度都会比同龄人快一截。