先聊一个挺实际的问题校招笔试为什么要去复盘一家公司好几年前的真题直接说我的看法笔试考的不是题目本身而是出题人背后那个团队的技术取舍。欢聚时代2018年这套C/C方向的A卷题目涵盖了音视频传输、推荐算法、测试开发三个完全不同的方向这恰好是直播类产品技术体系最核心的三块拼图。哪怕你不是奔着欢聚去把这三块内容吃透对其他音视频、直播、社交类公司的笔试面试也有很强的迁移价值。当年我刷这套题的时候花了整整一周把每个方向的知识点都梳理了一遍后来面其他公司遇到相似题目基本都能做到心里有数。这篇文章就把我当时复盘的内容完整整理出来不写虚的全是能落地的考点和思路。1. 这套题背后的公司技术画像1.1 从岗位设置看业务布局欢聚时代做的是YY直播、虎牙直播这类实时互动产品而直播产品最核心的技术链路就是主播端采集编码 - 网络传输 - 观众端解码渲染。这条链路决定了它必须同时具备硬核的音视频底层能力和大规模服务端架构能力所以C/C岗位在它的技术体系里承担的任务非常重从流媒体服务器到客户端SDK再到编解码器优化全都是C/C的战场。推荐算法和测试开发这两个方向看起来和C/C关系不大但在直播业务里同样绕不开。推荐算法解决的是给用户推什么直播间测试开发解决的是功能上线之后怎么保证质量。2018年这个时间节点短视频和直播正处于高速扩张期欢聚这个A卷把三个方向放在同一套题里其实就是在筛选不同梯队的人才C/C这题筛选的是底层核心研发推荐算法筛选的是增长率引擎测试开发筛选的是质量保障体系。三个方向对应三条完全不同的职业路径一条偏系统底层一条偏数据策略一条偏工程效能。1.2 为什么是这三个方向复盘这套题想明白一个点就值了音视频传输是直播的命脉推荐算法是直播的血液测试开发是直播的保险。一个做直播的公司如果音视频传输做不好再好的推荐和再彻底的测试都没有意义因为用户根本看不到流畅的画面但是如果只有流畅的传输用户找不到喜欢的主播留存一样上不去而前面两项都做好了没有完善的测试保障体系线上故障分分钟让日活崩塌。我当时画了一张图把这三者的关系理了一遍发现这套题看似分散实则是一条完整的业务闭环。更现实一点说这套题也反映了2018年校招的整体风向。那一年算法岗位开始大量涌入候选人推荐算法方向的竞争已经非常激烈音视频方向因为门槛高、会的人少反而成了性价比很高的选择测试开发则逐渐从点点点往自动化、平台化转型。如果你现在准备校招我建议按同样的逻辑去倒推目标公司先看它的业务是什么再推断它的核心技术方向最后针对性地准备笔试比盲目刷题高效得多。2. C/C考点复盘最扎实的一关2.1 内存管理与指针必考的硬骨头C/C的笔试题里内存管理永远是最高频的考察点这套卷子也不例外。我在整理真题回忆的时候发现几乎所有和C/C相关的题目都绕不开这几类指针和引用的区别、malloc和new的区别、堆和栈的区别、野指针和内存泄漏的成因。这些题目表面上是问概念实际上是在考察你有没有真正写过底层代码而不是只背了八股文。举一个典型的例子题目会给你一段代码判断它是否存在内存泄漏或者让你解释为什么这段代码会崩溃。看起来很简单但坑特别多。比如new和delete的配套使用很多人知道new要和delete配对但遇到new[]就要用delete[]这个细节经常被忽略再比如返回值是指针的函数如果返回的是局部变量的地址那必然出问题。我当时复习的时候把这类问题整理成了一个清单每次笔试前扫一遍基本能覆盖大部分考点。还有一个高频考点是内存对齐。不要去死记那个对齐公式要从CPU读取内存的原理去理解。CPU按照字长去读内存如果数据没有对齐就要读两次性能就差了。理解了这一点你自然就知道为什么结构体里成员顺序会影响sizeof。这类题目的意义在于筛选出真正理解程序执行细节的候选人因为写业务代码的时候不需要你知道但排查线上问题的时候你必须有这个敏感度。2.2 多线程与并发直播场景的刚需C/C方向的题里多线程几乎是必考项。我之前整理这套题的时候发现它考察得比较多的点包括线程同步的几种方式互斥锁、条件变量、读写锁、信号量、死锁的四个必要条件、生产者消费者模型的实现。这些考点和直播业务有很强的关联性比如音频采集线程、编码线程、网络发送线程之间就是典型的生产者消费者关系音画同步更是需要精细的线程管理。我记得有一道题是关于两个线程交替打印奇偶数的看起来很基础但它考察的不只是语法而是你对同步机制的理解深度。用互斥锁能实现加上条件变量也能实现但性能表现完全不同。我在实际笔试的时候就吃过亏只写了mutex版本认为能跑就行后来面评里反馈说可以考虑更优的同步方式。所以不光要写出答案还要主动思考有没有更好的实现。死锁的四个必要条件也是高频题做题的时候不要只是背出来要会分析代码为什么死锁。我建议用这种思路先画出线程A和线程B各自持有什么锁、等待什么锁然后判断是否存在循环等待。这个分析习惯在真实的工作场景里非常有用尤其是写多线程网络服务的时候死锁问题一旦出现在线上排查成本是很高的。2.3 语言特性与工程素养除了内存和多线程这套题的C/C部分还考察了不少语言层面的细节。比如const关键字在不同位置的修饰含义、static关键字在函数内外的作用差异、虚函数和纯虚函数的区别、虚函数表的工作原理。这些题看起来偏理论但其实是考察你写工程代码时的直觉。我印象很深的一个细节是虚析构函数。很多人知道基类析构函数要声明为virtual但不知道为什么。如果基类的析构函数不是虚函数用基类指针delete派生类对象时只会调用基类的析构函数派生类的资源就泄漏了。笔试遇到这个题不能只说会内存泄漏要能把这个过程讲清楚最好能画出内存布局来说明这样才算真的理解。STL的考察也很常见。vector和list的区别、map底层为什么是红黑树而不是哈希表、迭代器失效的场景这些经典题几乎每次笔试都会遇到。我复习STL的时候想明白一个道理STL考的不是容器接口而是你选型能力。一个合格的C/C工程师应该能根据数据量和访问模式说清楚为什么这个场景用vector、那个场景用list这才是笔试真正想看到的。3. 音视频传输整个笔试的灵魂3.1 编解码基础从PCM到AAC/H.264因为欢聚做直播音视频传输方向的知识点在整套题里占了相当大的比重。我当时复习的时候先梳理了最底层的概念音频采集出来是PCM裸流视频采集出来是YUV格式如果直接传码率根本扛不住所以要编码。这个逻辑链想明白后面所有知识点都能串起来。编码这块音频主流的编码格式是AAC和Opus视频主流的编码格式是H.264和H.265。笔试不太会考复杂的手写编码器但会考察你对编码原理的理解比如H.264的I帧、P帧、B帧分别是什么GOP是怎么构成的码率控制模式CBR、VBR、CRF有什么区别。帧类型和GOP这个知识点值得好好关注因为它直接影响后面要讲的秒开和卡顿优化。封装格式、编码格式、传输协议这三个概念非常容易混笔试也喜欢在这里挖坑。我做个类比编码格式是怎么压缩封装格式是打包成什么盒子传输协议是用什么交通工具送。H.264是编码格式MP4/FLV是封装格式RTMP是传输协议这三层不能混在一起。能把这三层关系讲清楚音视频的底子就比大部分人扎实了。3.2 传输协议RTMP、RTP、WebRTC的区别音视频传输的考题里协议对比是必考内容。2018年这个时间点直播行业最常用的协议是RTMP同时RTP/RTSP在传统流媒体里也有广泛应用而WebRTC因为低延迟的特性正在被越来越多地讨论。笔试常见的考法是让你对比这几个协议的优劣并说出使用场景。RTMP基于TCP优点是穿透性好、CDN支持成熟缺点是延迟偏高一般能做到3到5秒RTP通常配合RTSP使用更多用在监控、VoIP这类场景WebRTC基于UDP端到端延迟能做到500毫秒以内但复杂度高需要处理丢包重传和抖动缓冲。我当时为了整理这套题专门画了一张对比表格把传输层协议、延迟水平、应用场景、优缺点四列排开笔试前扫一眼就能理清思路。这里要注意一个很容易踩的坑千万不要把TCP和UDP的对错绝对化。TCP有重传机制所以可靠但延迟高UDP快但不可靠所以要在上层做FEC前向纠错或丢包重传。直播场景里网络抖动是常态所以设计传输方案的时候需要根据网络状况动态调整策略比如网络差的时候自动降低清晰度或者增大FEC冗余。笔试题目不会直接让你写传输模块但会在场景题里体现这些思路。3.3 卡顿与延迟优化一道送命题音视频方向的场景题几乎绕不开卡顿和延迟这道题这套卷子也一样。卡顿和延迟是直播体验的两个核心指标而且它们之间存在博弈延迟要求低数据要尽快推出去但网络一抖动就容易卡顿卡顿要求多缓冲延迟就上去了。笔试考这个点是想看你有没有在真实项目中处理过类似问题。我当时整理了一个优化思路框架分三层采集端、传输端、播放端。采集端尽量保证编码速度稳定避免瞬间高码率传输端做动态码率调整、关键帧请求、丢包重传播放端做抖动缓冲和追帧策略。面试的时候如果能把这个框架讲出来再结合首帧秒开优化的具体手法比如提前在播放器里探测I帧、预加载一段数据再播放会非常加分。我记得还见过这道题弱网环境下观众频繁卡顿你会怎么排查和处理这个不能只答降低码率要分步骤先看是网络问题还是服务端问题用打点数据定位丢包率、RTT、播放器缓冲长度然后再针对性优化。排查思路比具体优化手段更重要这个逻辑应用到任何技术岗位的面试都能通用。4. 推荐算法考察的不是模型是思维4.1 经典算法题协同过滤不会过时推荐算法方向放在这套A卷里考察的侧重点和单独招聘算法工程师的岗位不太一样。它不要求你写过Transformer或者深度兴趣网络但会考察最经典的推荐算法原理最常见的就是协同过滤。有一道题是给出用户对直播间的打分矩阵让手算用户相似度或者预测某个用户对某个直播间的评分。协同过滤分基于用户的User-Based和基于物品的Item-Based两种笔试常考察相似度计算方法比如余弦相似度和皮尔逊相关系数。我记得当时做这种题的时候容易把公式背错后来总结了一个记忆方法余弦相似度只看向量夹角不看长度皮尔逊相关系数会把用户的平均偏好减掉用来消除用户打分尺度的差异。理解了这个区别做题不仅快还能灵活扩展到面试里的追问。这题表面上是考计算实际上考的是推荐链路里的召回策略。直播间的数量级很大如果全量算相似度根本扛不住所以要先做召回再精排。笔试如果出这个题你可以主动补充一句实际工程里会做物品embedding然后建ANN索引做近邻检索这样就把一道普通计算题答出了工程深度。4.2 排序模型与特征工程推荐方向的题还会考察排序模型和特征工程的基本思路。2018年的时候FM因子分解机和FFM在工业界还很热门逻辑回归是各家系统的基础排序模型GBDT和LR的融合也是高频考点。我在求直播面试前专门把FMs模型的公式推了一遍理解了它怎么用隐向量交叉特征结果面试真的问到了相关概念。不过对C/C岗位的候选人来说推荐算法这部分能答上来经典思路就够了不用追求把深度学习模型都过一遍。我当时给自己定的目标是能解释清楚特征怎么来、模型怎么选、怎么评估形成一个完整的闭环。比如给定预测用户是否会看某个直播间这个任务要能说出特征可以分用户侧、主播侧、上下文侧三类模型可以用LR或FM评估指标用AUC这样逻辑就通顺了。一个刷题时容易忽略点是冷启动问题。新用户没有任何行为数据怎么做兜底推荐新直播间的标签信息不够怎么预估它的点击率。这类题目在笔试题里往往会以简答题形式出现关键在于展示解决思路而不是背答案比如提出用主播的画像模拟历史行为或者先做试探性曝光根据反馈快速迭代这些都是工程里真实在用的策略。4.3 评估指标离线与在线推荐算法相关的考题指标题是必考的尤其是AUC。AUC的含义是随机取一个正样本和负样本模型给正样本打分大于负样本的概率。看似只是一个概念但笔试经常会换个场景考你比如两个模型AUC一个0.72一个0.74能说明后者一定更好吗这就要你想到统计显著性检验。此外推荐系统的评估分离线评估和在线评估两个阶段。离线评估用历史数据回放看AUC、精确率、召回率在线评估要通过AB实验关注CTR、观看时长、留存率这些业务指标。笔试如果出场景题推荐算法的AB实验显示CTR提升了但留存没有提升怎么分析我的答题思路是先检查实验分流有没有问题再检查CTR提升是否因为标题党导致的点击质量下降最后看短期指标和长期指标的不一致。这套A卷里推荐算法占比不算高它是作为C/C岗位的综合素质考察项出现的所以复习的时候不用陷得太深。把协同过滤、LR/FM、AUC、特征工程基本思路理清楚已经足够应付大部分校招笔试了。5. 测试开发工程化思维的分水岭5.1 测试理论的考点测试开发方向的题首先会考察最基础的测试理论。测试用例设计方法、黑盒和白盒测试的区别、单元测试和集成测试的定位这些虽然看起来简单但笔试的时候很容易因为写得太虚而扣分。我总结下来的经验是答这类题要举具体例子比如设计测试用例时不要只写输入正确数据返回正确结果而要写出等价类划分的具体区间。测试用例设计里最经典的是边界值分析。比如一个输入框要求输入1到100之间的整数那测试用例至少需要包含0、1、2、99、100、101、单字、浮点数、负数、空值这些边界和异常情况。我当时做这套题的时候把这类边界值用例的写法整理成了一句话正常值选两端和中间异常值选边界外一位和极端异常再覆盖一下类型错误。这样答题条理会清晰很多。5.2 自动化测试与框架测试开发岗位笔试更看重的是自动化测试能力和工程化思维。常考的考点包括如何设计一个自动化测试框架、POPage Object模式怎么理解、接口自动化和UI自动化的区别。2018年在测试开发领域像Selenium、Appium、JMeter这类的工具是大家默认选项现在再看虽然工具在变但是背后分层的思想没有变。我当时在笔试中遇到的一道经典题给你一个登录接口让你设计自动化测试方案。我的答题思路分几步先用等价类和边界值设计功能用例其次准备测试数据包括正常账号、密码错误账号、被锁定账号然后通过接口调用方式实现自动化断言响应码和返回体最后加一层CI集成每次代码变更自动跑一遍回归。把这几步写清楚就会显得有真实的工程经验。针对直播业务测试开发还有一个独特场景音视频质量的自动化验证。这个在一般的测试题里很少见到但对欢聚这类公司来说很关键。比如测试直播过程中是否卡顿、花屏、音画不同步不能靠人眼盯着看需要设计自动化的音视频质量评估脚本通过采集端和播放端的打点数据对比。我当时没有准备到这个点面评里就被提醒了所以特别提醒后面准备的人一定要结合公司业务去预测考题方向。5.3 性能测试与问题定位测试开发笔试里性能测试是拉开差距的一个板块。经典题目包括如何设计一个直播间的压力测试方案、QPS和并发用户数的区别、性能瓶颈怎么定位。做这类题要先分清几个概念并发用户数指同时有多少用户在线QPS指每秒处理的请求数两者之间不是简单的相等关系因为一个用户可能同时有多个请求。搞混了这几个概念后续方案设计的逻辑就全乱了。举个例子如果在线用户有100万并不是就要压到100万QPS而要根据用户的行为模型估算请求量。看直播的场景里用户进入直播间会产生进房请求然后持续拉流不发请求所以真正的瞬时压力可能集中在开播和切换直播间的时刻。我的建议是设计压测方案时从业务模型出发而不是从数值出发这个思路在笔试和面试中都适用。问题定位方面常见考法就是给出一个线上Bug让你给出排查思路。典型的比如用户反馈直播间高峰期进不去要能想到从客户端、接入层、服务端、数据库四层依次排查通过日志和监控数据判断瓶颈在哪儿。这类题没有标准答案但测试开发岗位需要的就是这种条理清晰的排查能力笔试能答好基本就证明你具备这个潜质。6. 应试策略与复盘建议6.1 时间分配与审题技巧这套A卷覆盖了C/C、音视频传输、推荐算法、测试开发四个大方向题量一定不小。我先说一个真实的教训我做这类综合卷的时候经常因为顺序不对而没做完。后来总结出一个比较适合我的策略先快速浏览全卷把自己最有把握的题先做掉包括选择题和填空题这些题花费时间少、得分稳定然后是算法和代码题这类题分值高且需要思考时间把需要长篇论述的场景题放在最后确保即使时间不够前面的分数已经拿稳了。审题的技巧也要提一下。笔试题目经常会埋一些限制条件比如内存不超过1MB、要求时间复杂度O(n)这些约束其实是加分提示。我观察很多同学容易忽略这类限制直接按常规思路写代码结果一个简单的不额外分配大数组、原地处理的考点就被错过了。所以一定要把题读完再动笔题目越长考察点越细化。6.2 复习方向建议针对类似的校招笔试我建议复习的时候按两条线并行走。第一条线是掌握通用硬技能比如C/C的指针、内存、多线程这部分不管公司业务是什么都会考第二条线是研究目标公司的业务推导它可能在哪个方向加点难度比如直播公司大概率考音视频传输电商公司大概率考高并发和缓存内容型公司大概率考推荐和搜索。时间紧张的情况下优先抓频率最高的考点不要贪多求全。以C/C为例优先级排在最前面的是指针和内存、STL使用、多线程基础其次是语言细节和设计模式以音视频为例编解码基本概念、常用协议比较、弱网优化思路是核心细节的H.264码流结构分析就不用死磕。我复盘过很多套校招真题发现最高频的永远是最基础的知识点。6.3 面试延伸从笔试题到面试题的转化笔试做完了别急着丢一边把每道错题和蒙对的题都当成一个潜在的面试问题来准备。我个人的习惯是把笔试题目转换成三句话这道题我考的是什么知识点、我当时为什么没做对、下次遇到同类题我应该怎么思考。这个过程不需要花大量时间但对巩固知识的帮助却很明显。比如一个笔试题目让你写一个单例模式的线程安全版本笔试题做完了面试官可能会继续追问这个实现和double-checked locking有什么区别volatile在这里起什么作用。所以准备笔记时要把每个知识点向外延伸一层把配套的追问也一起准备。校招面试的淘汰率高于笔试靠的就是这种追问环节能把底层原理讲清楚的同学胜率明显更高。针对这套欢聚时代的A卷还有一个值得注意的延伸方向如果你对音视频传输方向感兴趣建议后续深入学习WebRTC的源码哪怕只看其中的JitterBuffer和拥塞控制模块也会在面试中有很大优势。这是一个门槛高但竞争者少的方向提前花时间投入实际回报率远超预期。最后分享一点个人体会现在回过头来看笔试考得好不好跟你大学里学过多少门课程关系不大真正决定差距的是你有没有主动去理解技术背后的业务逻辑和工程取舍。欢聚时代这套题三个方向看似分散其实都在验证同一件事——你能不能站在业务的视角思考技术问题。准备任何校招笔试的时候都可以带着这个问题去复习这个知识点在这个公司的业务场景里是怎么被用起来的想清楚这一点你看到的不再是一道道孤立的题而是一张完整的技术地图。