参加欢聚时代2018校招笔试那天拿到的就是这份A卷。当时翻完卷子的第一反应是这哪是一份普通校招笔试题这分明是一家实时音视频公司的技术自画像。整场考试C/C占了最大比重音视频传输、推荐算法、测试开发三个方向混合出题题型覆盖选择、填空、简答和手写编程题量不算小但真正难的不是题本身而是你要在有限时间内读懂出题人想考察的工程能力。我是在笔试结束后对照同届同学和牛客上的讨论把整张卷子重新复盘了一遍又带着这些题目做了几年直播相关的后端开发再回头看才真正明白各道题的用意。这篇就按我的记忆把A卷的考点和解题思路拆开讲给准备校招尤其是想投C/C、音视频方向的同学做个参考。1. 先看懂欢聚时代笔试背后的公司基因1.1 为什么这家公司的笔试题值得逐题研究2018年直播行业正是最热的时候YY直播是欢聚时代的核心业务整个公司的技术体系都围绕“实时音视频”展开。实时直播和普通Web后端有一个本质区别它对延迟、卡顿、弱网对抗的要求极高而当时的直播客户端、服务端、音视频引擎几乎全部依赖C/C作为底层语言。理解了这层业务背景再看A卷C/C占比最高这件事就完全不奇怪了。很多人觉得2018年的题放到现在已经过时我不这么看。这几年直播、短视频、RTC实时通信业务越来越普及WebRTC、自研音视频引擎大量出现底层需要的仍然是扎实的C/C功底和对传输链路的理解。这份卷子考的不是某个框架的API用法而是内存、指针、并发、协议、网络、算法这些十年都不会变的东西。反而现在很多笔试开始考八股式的问题这种直接抓底层功底的卷子更显得珍贵。1.2 从岗位设置猜题目权重C/C是底盘音视频是特色A卷的岗位方向写得很清楚C/C、音视频传输、推荐算法、测试开发。看起来是四个方向其实它们都围着直播业务转——音视频传输是直播的生命线推荐算法负责让用户在直播广场看到感兴趣的房间测试开发保证直播链路稳定可交付而C/C是所有这些模块的底层实现语言。我印象里卷面结构大致是这样的题型大致占比覆盖方向选择题30%左右C/C语法、操作系统、网络基础填空题15%左右指针、内存、输出结果类题目简答题25%左右音视频传输、推荐算法、测试设计编程/设计题30%左右手写算法、系统设计、场景题这四块是按分值大致估的具体题目顺序记不太清了但考察逻辑很清楚C/C基础决定你能不能进下一轮音视频、推荐、测试开发相关题目则用来区分你适合哪个方向。想投C/C岗位的人如果音视频题目完全不会容易被调剂到非核心岗位想投测试开发的人如果C/C基础太差后面的用例设计题再答得好也会很悬。2. 回看A卷整体答题节奏题型、分值与时间分配2.1 A卷的大致构成与考察重点先说选择题。A卷的选择题里C/C语法占了一半以上剩下的分布在上层网络和操作系统。比如sizeof相关计算、指针自增自减的优先级、static修饰局部变量和全局变量的区别、进程和线程的对比、TCP三次握手和四次挥手的过程、虚拟内存和物理内存的映射关系等。这些题单独拿出来都不算难但组合在一起就会让基础不扎实的人大量失分。填空题基本是给一段C/C代码让写输出结果。这类题在牛客上被讨论得最多因为代码里有太多细节陷阱整型溢出、类型转换、运算符优先级、指针偏移、字符串拼接、宏定义展开等。我印象很深有一道宏定义的题定义了#define SQUARE(x) x*x然后写int a SQUARE(31);很多人直接填16实际结果是7因为宏是文本替换展开后变成31*31。这种题考的就是你对“宏不是函数”这个底层机制的理解。简答题和编程题是拉开差距的地方。简答题有一道“推流上行不稳定时你会从哪些层面做优化”还有一道“设计一个测试直播房间进入功能的测试用例”。编程题则是经典的数据结构与算法我记得有链表中环检测、手写快速排序、字符串转整数这类题目。整体难度在2018年校招笔试中属于中上但胜在方向明确不偏门。2.2 我的答题顺序与时间预算当初我犯过一个错误就是在一道选择题上纠结了将近十分钟。现在回头看A卷的题量和限时决定了你不可能每题都精雕细琢必须有清晰的取舍。按我的经验比较合理的时间预算是选择题控制在20到25分钟内完成遇到拿不准的题先标记不恋战填空和简答留40分钟左右简答题按“要点解释例子”的结构作答不要写成长篇大论最后至少留60分钟给编程题和设计题。编程题哪怕写不完完整的代码也要把思路、数据结构、时间复杂度和边界情况写清楚阅卷人看的是你分析问题的过程而不只是最终结果。另外说一个很多人忽略的点简答题的排版和书写很重要。笔试不是面试你的答案就是你的“代码”写得乱、没有层次阅卷人很难给你高分。我当时的原则是每道简答题先写结论再分点展开最后补一句关键名词解释这样即使部分内容不确定逻辑框架也是完整的。3. C/C方向真题复盘指针、内存、并发决定你能否进下一轮3.1 指针与内存校招必考范围内的“送命题”指针在A卷里反复出现贯穿选择、填空和简答。最常见的一类是把各种声明混在一起考比如char *p[10]、char (*p)[10]、int *f()、int (*f)()、const char *p、char *const p。很容易混淆我按照工程中真实使用的优先级给它们排了个序char *p[10]是“指针数组”p是一个数组里面存了10个char指针char (*p)[10]是“数组指针”p是一个指针指向一个含10个char的数组int *f()是“函数返回指针”f是一个返回int*的函数int (*f)()是“函数指针”f是一个指针指向返回int的函数const char *p表示p指向的字符是const不能通过p修改字符char *const p表示p本身是const不能修改p的指向。我当年在复习时把这几组放到一起对比记忆后来在笔试中遇到类似的题几乎是一眼出答案。这里的核心逻辑不是死记硬背而是理解“优先级”和“结合性”[]、()的优先级高于*所以默认先按数组或函数理解再用括号改变结合顺序时再按指针理解。填空题还考过内存对齐。题目大致是定义一个struct里面有char a; int b; char c;让你求sizeof。很多人凭感觉填6实际答案是12在默认4字节对齐下成员按声明的顺序依次对齐char占1int按4字节对齐会从偏移4开始c再补到12。这道题在工程里的意义是如果系统里大量使用结构体内存对齐会影响内存占用和CPU访问效率很多通信协议封包解包时也会因为字节对齐问题出现难以排查的bug。后来我做音视频服务端时经常要处理二进制协议里的结构体对齐问题每次都会想起这道填空题。内存泄漏相关的内容在简答题中出现。考察的切入点不外乎new/delete和malloc/free的区别、野指针是怎么产生的、如何避免内存泄漏。A卷第3部分通常会出现类似“C中如何管理动态内存RAII思想是什么”这样的题目。我之前在项目里用裸指针踩过坑所以对RAII的理解比较深资源获取即初始化把内存、文件句柄、锁等资源绑定到对象的生命周期上对象析构时自动释放这样就算代码中间抛出异常资源也能被正确回收。笔试时我把RAII和智能指针结合起来答从unique_ptr的独占语义讲到shared_ptr的引用计数再提到weak_ptr解决循环引用阅卷人看出你有实际工程经验印象分会高不少。3.2 构造、析构、虚函数class里的“暗坑”有多强C面向对象部分的题在A卷中占的分值也不小。选择题里有一道经典题创建一个派生类对象时构造函数的执行顺序是什么。答案是先基类构造函数再成员对象构造函数最后派生类构造函数析构顺序则完全相反。这道题本身不难但它背后埋着一个很多人意识不到的坑如果基类析构函数不是虚函数通过基类指针删除派生类对象时只会调用基类析构函数派生类资源不会被释放造成内存泄漏。另外一道代码题是关于拷贝构造函数的。说的是一个类里有一个char*成员在拷贝构造时直接做了浅拷贝导致两个对象指向同一块堆内存析构时同一块内存被释放两次程序崩溃。这道题在那个环境下不算难但涉及到深拷贝 vs 浅拷贝、拷贝赋值运算符、移动语义能展开的点非常多。答题时如果只写“浅拷贝导致double free”是不够的更完整的答法是先指出问题本质是指针成员导致了共享所有权再给出深拷贝的实现思路最后引申到现代C应该用std::string、std::vector这类值语义容器来避免裸指针带来的所有权混乱。笔试时间有限但至少要把前两层写清楚。虚函数的机制也是必考点。选择题会出现“虚函数表是类级别的还是对象级别的”这种题目答案是每个类一张虚函数表每个对象里有一个指向该表的虚表指针vptr。简答或填空题可能会考为什么构造函数不能是虚函数析构函数却建议是虚函数。前者是因为构造对象时vptr还没初始化虚函数机制还不成立后者是为了保证通过基类指针删除派生类对象时能正确调用到派生类析构函数。这类问题在客户端和服务端开发里非常常见我后来排查线上C崩溃问题时十次里有三次跟对象生命周期没管好有关。3.3 多线程与同步从生产者消费者到死锁直播平台的大量服务端模块都是多线程模型所以多线程相关题目在A卷里几乎是必考。选择题有进程和线程的对比简答题有生产者消费者模型。生产者消费者模型在2018年作为必背题存在现在依然是经典一个缓冲区多个生产者线程往里面放数据多个消费者线程从里面取数据要求缓冲区满时生产者等待空时消费者等待。答案通常要写两把锁和两个条件变量或者用互斥锁加一个条件变量配合处理。核心要点是判空、判满和操作缓冲区的动作必须在同一把锁的保护下进行否则会出现竞态条件。这里有个小细节就是我面试过不少同学他们能把代码背下来但问“为什么wait要放在while循环里而不是if里”就答不上来。原因是条件变量存在“虚假唤醒”的可能如果只用if判断线程被唤醒后不会重新检查条件缓冲区的状态可能已经不满足要求直接操作会出错。笔试时如果能主动写出这个细节说明你是真正理解并发原语而不是背模板。死锁相关的题也会出现最常见的是列出一个场景判断是否死锁然后问如何避免。死锁的四个必要条件互斥、持有并等待、不可剥夺、循环等待是标准答案代码层面的考察则偏爱“线程A持有锁1申请锁2线程B持有锁2申请锁1”这个经典场景。答这类题除了理论最好能提到实际工程中的规避手段尽量使用std::lock一次性锁多个互斥量、保证多把锁的加锁顺序一致、用try_lock替代阻塞等待等。3.4 手写代码从链表环检测到快速排序编程题部分和我同期笔试的同学反馈基本一致没有偏题怪题考的是基本功。链表中环检测我用的是快慢指针慢指针每次走一步快指针每次走两步如果相遇说明有环。这道题的关键是解释“为什么快慢指针一定会相遇而不是快指针把慢指针跳过去”——在环里快指针每次比慢指针多走一步相当于慢指针不动、快指针以每次一步的速度靠近它所以不会跳过。这个解释面试官很看重。快速排序也是高频题。笔试要求手写完整实现包括递归终止条件和分区函数。我当时的写法是经典的Hoare分区或Lomuto分区时间复杂度平均O(n log n)最坏O(n^2)稳定性是不稳定的。要拿高分除了能把代码写对还要会回答优化点三数取中、小区间改用插入排序。字符串转整数这道题看似简单实际上边界条件极其多正负号、溢出、前导空格、非法字符、空字符串。出题人真正想考察的是你有没有边界意识。我当时列了一个检查清单跳过开头的空白字符判断正负号逐字符转换遇非数字停止用long long保存中间结果防止int溢出溢出时返回INT_MAX或INT_MIN空字符串和纯符号串返回0这些边界条件放到后来做音视频信令服务时同样重要——客户端传来的字符串参数永远不能假设是合法的健壮性就是这么一点点磨出来的。4. 音视频传输方向一份协议、两条链路考出你的工程直觉4.1 TCP和UDP的选择题从来不在表面音视频传输相关的选择题里TCP和UDP的对比几乎是必有的。很多人只看表面TCP可靠但慢UDP快但不可靠。这种答案在笔试里拿不到分因为出题人想要的是你在具体业务场景下做取舍的能力。维度TCPUDP可靠性有确认、重传、排序无确认、无重传连接管理三次握手、四次挥手无连接延迟相对高队头阻塞明显相对低无队头阻塞适用场景文件传输、信令、HLS实时音视频、RTC当时的选择题问的是“直播场景下为什么推流常用RTMP基于TCP而WebRTC通话走UDP”。这两者并不矛盾RTMP用于一对多的直播分发对延迟要求没那么极致TCP的可靠性可以减少内容分发过程中的花屏和音画不同步WebRTC用于实时通信延迟必须压到几百毫秒以内TCP的拥塞控制和丢包重传带来的不确定性是无法接受的所以选择了UDP之上做SRTP、FEC和ARQ。答这类题时如果能把这个层次讲清楚说明你不是只会背协议名而是真的理解协议为什么这么设计。4.2 推流链路的简答题从“秒开”到弱网优化简答题里有一道题我印象很深大致是“直播推流上行不稳定时你会从哪些层面优化”。这类题没有标准答案但答得好的人一定能画出下面的链路采集 - 前处理美颜、降噪- 编码H.264/H.265- 封装FLV/MP4- 推流RTMP/QUIC- 服务端转码 - 分发CDN- 播放器解码渲染明白了整条链路优化点就很好找了上行带宽不足时可以降低编码码率或分辨率也可以动态调节帧率编码参数方面可以调整GOP关键帧间隔长度减少I帧大小或改用H.265获得更高的压缩率传输层面可以做码率自适应根据反馈的带宽估计动态调节编码参数也可以加入前向纠错FEC来恢复随机丢包关键帧请求机制则保证出现严重丢包时播放端能快速恢复。这里我特别提醒以后要投音视频方向的同学GOP大小直接决定延迟和首帧时间GOP越长编码压缩率越高但接收到关键帧要等待的时间越长这在直播秒开优化里是一个经典权衡。A卷如果在简答题中出现“如何降低直播首帧延迟”方向就是GOP缓存优化、边缘节点就近接入、播放器预加载和协议升级这几个方面。4.3 音视频专题填空题里的编码基础填空题还有几道关于H.264的比如I帧、P帧、B帧的含义以及它们对传输的影响。I帧是关键帧可以独立解码且体积最大P帧是预测帧依赖前面的帧才能解码B帧是双向预测帧依赖前后帧压缩率高但是会引入额外延迟在直播低延迟场景下通常会限制或关闭B帧。另外考了帧率、码率、分辨率三者的关系计算。给你分辨率1920x1080、帧率30fps、色深8bit问原始视频一秒钟的数据量大概是多少然后问经过H.264压缩后大约降到多少。原始数据量就是把宽、高、帧率、每像素位数乘起来大概是1920x1080x30x24bps约150MB/s压缩后取决于码率设置常见直播码率在2~8Mbps。这个计算过程不复杂但它体现了你是否了解“未压缩数据量”和“编码后码率”是两个差别极大的概念理解这个对比才能真正明白编码在直播链路里起什么作用。5. 推荐算法方向题目在问模型实际在问工程化5.1 召回与排序的选择题和简答题用户推荐的题目在A卷里分布得比较散选择题大概率会出现协同过滤的变体。试题可能会给一个用户-物品评分矩阵问使用基于用户的协同过滤UserCF时需要找相似度的对象是什么。答案是“和目标用户历史行为最相似的其他用户”而基于物品的协同过滤ItemCF则是“和目标物品被同一批用户喜欢的其他物品”。这两者的选择在直播场景里很讲究。ItemCF更稳定适合用户兴趣相对固定的场景UserCF更容易发现新兴趣但计算量大且实时性要求高。直播广场的房间推荐用户兴趣变化快因此业界常用ItemCF和实时行为特征结合的方案。我当时答题时补充了一句“UserCF在用户量非常大时在线计算用户相似度矩阵代价很高因此常离线计算或采用近似算法”这个点现在看来仍然是考察候选人对推荐系统复杂度认知的分水岭。排序模型的题目则更偏基础。可能出现一道选择题问逻辑回归LR的适用场景或者问FM为什么比LR效果好。LR是线性模型简单、可解释性强、易于上线但无法自动学习特征之间的交叉组合需要人工做特征工程FM通过隐向量引入特征两两交叉能在稀疏特征场景下表现出更好的效果。2018年正是FM、GBDTLR、DeepFM这些方法快速迭代的时期笔试题不会考到太深的模型细节能答清楚“特征交叉”和“稀疏性问题”就够了。5.2 数据倾斜与实时性直播推荐的真实考题直播推荐和电商推荐有一个巨大差异直播内容有时效性一场直播的热度窗口可能只有几个小时用户进入房间、离开房间、送礼物、发弹幕都是实时信号。因此推荐系统的数据链路必须支持实时特征计算。试卷里对应出现一道简答题如何做实时推荐。基本思路是用户实时行为点击、观看时长、关注通过消息队列收集经过流式计算框架做滑动窗口聚合产出结果更新到特征库和候选集再在排序阶段结合实时特征和离线模型打分。提到消息队列、流式计算、特征存储、模型打分这套链路阅卷人就知道你有工程概念。数据倾斜的题出得很典型某直播间热度极高大部分用户都喜欢导致这个直播间的特征在训练样本中占比过大、模型偏差严重。解决办法可以从两个角度回答在样本层面做热门物品降采样限制单个物品在训练集中的出现次数在特征层面增加“热门程度”分桶特征在评估层面用加权指标降低高热房间对整体指标的影响。这些点如果没做过实际推荐项目很难答全。冷启动问题也是必考。新主播没有观看历史协同过滤完全失效。我当时给出的方案是内容特征匹配根据直播标题、标签、封面图做相似度匹配、利用主播所在分类和地域信息做冷启动探索、用多臂老虎机bandit算法平衡探索与利用。这些思路在没有大厂实习经历的情况下可能比较难写全但哪怕只写出“新内容没有历史行为时用内容特征做初始泛化”这一个点也比空泛地写“给新主播流量扶持”要专业得多。5.3 特征工程与A/B测试的边界还有一道选择或简答题围绕A/B测试展开问“一个新推荐模型上线前如何验证效果”。标准答案是做分层实验划分实验组和对照组确认流量隔离、样本无偏设置足够的实验周期和样本量用置信区间判断指标差异是否显著。这里容易被忽略的是“实验组的流量不能分层交叉污染用户一旦被分到某组就固定不变”以及“某些指标提升以另一些指标下降为代价时需要建立综合评估体系”。笔试时把这个层次写出来很加分。特征工程方面有一道简答题我记得是“推荐系统里哪些特征最重要”。我的答法是先分特征类型用户静态特征性别、地域、注册时间、设备、用户行为特征点击率、观看时长、活跃时段、兴趣标签、内容侧特征房间分类、主播等级、在线人数、标签、上下文特征当前时间、网络环境、正在直播的房间热度。再补充一句“直播场景下实时行为特征往往比静态画像更重要”。这样答案有结构也让阅卷人看到你不是只会列几个特征而是对特征体系有完整的认知。6. 测试开发方向用例设计题怎么答出“开发思维”6.1 用例设计的套路从等价类到场景法测试开发方向的题目在A卷里最贴近实际工作。简答题出现“设计一个直播房间进入功能的测试用例”算是非常温和的题。很多人看到这种题就开始堆用例写得零散且没有层次这是比较吃亏的。我当时的策略是分维度回答功能层面要覆盖用户进入房间成功、房间不存在、房间已满、房间密码错误、被踢出后无法进入、私密房间权限校验失败等基础场景。网络层面要考虑弱网、断网重连、WiFi切4G、上行丢包时的进入行为。性能层面要考虑并发进入房间时服务器的承受能力、首帧画面出现时间是否达标。兼容性层面要覆盖Android/iOS不同版本、不同机型、低端机内存不足时的表现。最后补充安全层面越权进入付费房间、伪造房间ID请求等异常场景。这个过程实际上贯穿了测试用例设计的核心方法等价类划分、边界值分析、场景法、错误推测法。考试时不需要把术语写全但用例必须从这几个维度自然展开让阅卷人看出来你不是只会“点一下看能不能进”的点点点测试。6.2 音视频质量测试外人不知道的考察点测试开发方向和音视频传输方向在A卷中出现了交叠有一道题是“直播卡顿你会从哪些维度检测和分析”。这道题对测试开发岗位来说考察的是“质量指标的建立”首帧时间、播放成功率、卡顿率、卡顿时长占比、音画同步差、端到端延迟、上行丢包率、下行丢包率、网络切换频率。这些指标不是靠肉眼感知而是要在播放器SDK和服务端日志中埋点采集再上报到数据平台做聚合分析。答题时我提到了“卡顿率和用户主观体验不是简单的线性关系”短卡顿可能被用户接受长时间卡顿则会导致用户流失所以指标制定时往往要给卡顿率和卡顿时长加权。这种细节说出来阅卷人就知道你不是只看过测试皮毛而是理解质量分析怎么做。6.3 自动化与性能测试测试开发的核心是“开发”A卷里测试开发方向还有一个倾向就是考察候选人的“开发能力”。比如有一道题是“如何对一个C后端服务做接口自动化测试”。标准思路是确认被测接口的协议和入参出参使用测试框架如gtest编写单元测试和接口测试将测试用例纳入CI流程每次提交代码自动触发构建和测试测试报告自动归档。性能测试也可能出现比如“直播弹幕服务每秒能处理多少条消息如何设计压测”。回答要涵盖压测工具选型、压测脚本编写、服务器指标监控CPU、内存、QPS、响应时间、结果分析和调优闭环。在调优环节可以提线程池大小调整、连接复用、消息批量处理、缓存热点数据等。这些点都体现出“测试开发”和“纯测试”的区别纯测试关注找bug测试开发关注怎么用工具和代码提升测试效率和质量保障能力。我特别想强调一点当年一起笔试的同学里有人觉得测试开发方向是“备胎”答得比较随意结果自然不理想。事实上欢聚时代这类公司的测试开发岗位待遇和核心度都不低因为直播业务对稳定性要求极高质量保障本身就是核心工程能力。笔试中测试方向的题答得专业同样能拿到很好的评级。7. 考后复盘这份A卷真正筛选的是什么能力7.1 笔试背后的三层筛选逻辑准备过很多校招笔试之后回头看欢聚时代这份A卷的筛选逻辑其实是三层递进的。第一层是C/C基本功。指针、内存、面向对象、多线程这些题几乎不给人侥幸过关的机会语法细节、代码输出题、内存管理题、手写编程题把“背过八股”和“真正写过”区分得很清楚。第二层是业务理解能力。音视频、推荐算法、测试开发的题目不是孤立的知识点而是围绕直播业务场景展开考察你有没有从链路角度看问题的意识——推流上行不稳定时你会改哪个环节直播卡顿了你从哪些指标定位推荐系统要兼顾实时性和兴趣探索。第三层是表达能力。简答题的答案结构、层次、关键术语编程题的时间复杂度和边界条件都在映射你以后写代码、写文档、做方案汇报时能不能把事情说清楚。7.2 给准备校招的同学三条实操建议如果你正准备投C/C方向或者音视频方向的校招我的建议很直接。第一把C/C基础按“指针与内存—面向对象—STL与智能指针—多线程—编译链接”这条线系统过一遍重点做代码输出结果类的题和手写代码题不要只看不写眼高手低是笔试最大的坑。推荐把经典面试题里关于const、static、虚函数、智能指针的部分刷到形成条件反射。第二理解音视频的核心链路不需要你掌握编码的每一个细节但采集、编码、传输、解码、渲染这条链路每个环节的作用必须讲清楚TCP/UDP的取舍、GOP和延迟的关系、码率自适应的基本原理都要能展开讲两三分钟。第三算法题保持手感数据结构与算法仍然是笔试的基本盘链表、二叉树、排序、字符串处理、动态规划这几类高频题型在笔试前保持每天两三道的量就可以。我自己走过这些路也见过太多同学在笔试时因为一道指针题卡住丢掉后面编程题的时间。这份A卷的技术含量放到今天依然在线它最值得学习的地方不是具体题目本身而是那股“业务驱动技术、技术回归链路”的出题思路。希望这篇复盘能让你在拿到下一份笔试卷子时不只是会做题更能看懂出题人想要什么。