企业官网建设流程全解析

刚拿到这份《欢聚时代2018校招笔试题-C/C++ 音视频传输/推荐算法/测试开发 B卷》的时候，我第一反应是这公司真够狠的。一个校招笔试，四个方向全塞一张卷子里，C/C++底子要考，音视频传输要考，推荐算法要考，测试开发也要考。这已经不是单纯筛基础知识了，这是在筛“你脑子里有没有一套完整的工程认知地图”。

我当年帮人辅导过不少大厂校招，也和欢聚时代的工程师聊过他们的业务形态。欢聚是做直播和音视频起家的，旗下业务线从游戏直播到短视频到海外社交，每一块都离不开三样东西：高性能的C/C++服务端、低延迟的音视频传输链路、以及把内容和用户匹配起来的推荐系统。测试开发则贯穿所有业务，保障线上质量。所以这份B卷其实很典型——它代表了一批“重业务、重工程、重性能”的互联网公司筛选校招生的方式。

这篇文章我不打算只给答案，那没意思。我打算把这份卷子拆开揉碎，讲清楚每道题背后的考点逻辑、出题人想看到什么、以及你在准备这类笔试时应该建立的知识框架。文章会分四个方向逐个击破，最后给你一套可执行的备考路线。不管你是想投欢聚时代，还是想进类似体量的音视频/直播/推荐类公司，这套拆解都值得你看完。

1. 笔试整体复盘：这份B卷在考什么

先说结论：这份卷子绝对不是靠刷题刷出来的。它考的是**“你有没有真实做过东西”**。

整份卷子的结构大致是：C/C++基础题（指针、内存、STL、多线程）占大头，音视频传输和推荐算法各占一小块，测试开发则偏场景题。这个分布本身就有讲究——C/C++是所有后端和客户端岗位的硬底子，音视频和推荐是业务方向题，测试开发更多是考察你有没有“找问题”的敏感度。

1.1 四个方向的考点占比与出题逻辑

我根据过去几年接触到的类似题目，整理了一份考点分布参考（不同年份略有浮动，但大方向稳定）：

注意看推荐算法那一栏——它不考你手推Transformer，不考你背Attention公式，而是考召回策略和特征工程。这说明欢聚的算法岗更看重你懂不懂“真实推荐系统是怎么跑起来的”，而不是你会不会背模型结构。这一点和很多大厂的校招思路一致：模型可以入职再学，工程sense和业务理解力才是校招生最稀缺的。

1.2 为什么欢聚时代会这样出题

欢聚的业务形态决定了它对候选人的要求。直播业务天然依赖实时音视频传输，互动场景下延迟高一点用户体验就崩了；内容分发又依赖推荐系统，用户留不留得下来就看推得准不准。而这两块的核心底层语言都是C/C++——音视频编解码库、传输协议栈、推荐服务的在线推理模块，清一色C/C++。

所以这份卷子看起来是四个方向，本质上是一条完整的业务链路：C/C++打好地基，音视频传输保障体验，推荐算法促进增长，测试开发守住质量底线。你不需要四个方向全精通，但你必须能看懂这条链路，能说清楚每个环节存在的意义。这恰恰是很多校招生最缺的——只会背知识点，不会串业务。

1.3 这份卷子适合谁参考

如果你正在准备互联网公司的校招，方向是C/C++开发、音视频开发、推荐算法、测试开发中的任何一个，这份卷子都值得做一遍。即使你不投欢聚，这套“四个方向串一条业务链”的考察方式也是目前大厂的主流玩法。我建议你重点看自己目标方向的那几节，但C/C++部分建议所有人都看——它是很多公司的第一轮筛选器，基础不牢后面全是空中楼阁。

2. C/C++方向：笔试里的“硬通货”怎么拿分

C/C++部分在整份卷子里占的比例最高，也是刷人最狠的部分。不用怀疑，凡是考C/C++的卷子，指针、内存、多线程这三座大山基本跑不掉。但我想先说一个很多人误解的点：校招笔试里的C/C++题，重点从来不是语法细节，而是内存模型和工程意识。

2.1 高频考点一：智能指针与内存管理

智能指针是笔试题的“亲儿子”。shared_ptr、unique_ptr、weak_ptr三兄弟的区别和使用场景几乎是必考，而且通常会结合一个场景：让你找出下面代码的内存问题。

#include <memory> #include <iostream> class Node { public: std::shared_ptr<Node> next; std::weak_ptr<Node> prev; // 注意这里用 weak_ptr 而非 shared_ptr ~Node() { std::cout << "Node destroyed" << std::endl; } }; int main() { std::shared_ptr<Node> n1 = std::make_shared<Node>(); std::shared_ptr<Node> n2 = std::make_shared<Node>(); n1->next = n2; n2->prev = n1; // 如果prev是shared_ptr，两个节点互相引用，析构函数永远不会调用 return 0; }

出题人考你智能指针，真正的考点是循环引用。如果n1和n2用shared_ptr互相指向对方，引用计数永远到不了0，内存就泄漏了。解决方式就是用weak_ptr打破循环。这个考点为什么高频？因为真实项目里链表、树、图这些结构到处都是，循环引用是线上内存泄漏最常见的元凶之一。

再补充一个实操心得：笔试里如果让你“设计一个内存池”或者“实现一个智能指针”，别慌，这类题考的是底层原理。实现一个简易unique_ptr的核心就两点——RAII思想（资源获取即初始化）和移动语义（禁止拷贝，允许移动）。能把这两点讲清楚，面试官心里就会给你加分。

2.2 高频考点二：STL容器底层原理与选型

STL这部分的题特别容易暴露“背八股”和“真懂”的区别。比如问你vector和list的区别，背八股的人会答“vector是连续内存，list是链表”，但真懂的人会接着往下说：vector扩容的拷贝开销、list节点分散导致缓存命中率低、unordered_map的哈希冲突处理、map的红黑树为什么不用AVL。

举一个笔试常考的选择题逻辑：

有一个频繁在头部插入、尾部删除，并且需要随机访问的场景，应该选哪个容器？

标准答案往往说deque，但它为什么合适？因为deque是双端队列，头尾操作都是O(1)，而且支持随机访问。但真实项目里如果元素量大且插入频繁，deque的块状存储结构也会因为维护中控器指针产生额外开销。我在实际开发里遇到这种场景，通常会直接评估数据量级：几千级别vector随便用，几十万级别才需要考虑deque或list。

这里给一个实用的避坑提示：笔试中凡是涉及“选容器”的题，不要只答容器名，把时间复杂度和内存布局一起说。比如“我选deque，因为头部插入O(1)且支持随机访问，虽然缓存局部性不如vector，但能满足头尾操作的性能要求。”这种回答模式，在面试环节同样吃香。

2.3 高频考点三：编译链接与内存布局

这个考点比较冷门，但欢聚这份卷子出现了相关的影子。它考察的是你知不知道一个C/C++程序从源码到可执行文件经历了什么——预处理、编译、汇编、链接，以及最终产出的二进制在内存里怎么排布：代码段、数据段、BSS段、堆、栈。

笔试里常见问法是：全局变量和局部静态变量都存储在哪个段？堆和栈的区别？为什么栈比堆快？

快速梳理一下关键结论：

• 栈：由编译器自动分配释放，连续内存，速度快，容量小，默认一般在1MB到8MB之间
• 堆：由程序员手动分配释放，低地址向高地址增长，速度慢，容量大
• 全局变量和static变量：不在栈也不在堆，而是存在静态存储区（数据段或BSS段）
• 字面量常量：通常存在只读数据段

这个考点本身不难，但很多刷题型选手会漏，因为它不在LeetCode覆盖范围内。我的建议是，用一周时间把《程序员的自我修养——链接、装载与库》前四章啃下来，这本书虽然老，但讲编译链接的部分至今没有更好的替代品。

2.4 C/C++部分实操建议

如果你正在为这类笔试做准备，我给你一套具体的复习优先级：

1. 先过一遍智能指针和移动语义，确保能徒手写出RAII思想
2. 再把STL常用容器的时间复杂度表打印出来贴在桌上，背熟
3. 去把编译链接四阶段走一遍，用gcc的-E、-S、-c、-o各跑一次，看中间产物
4. 最后刷多线程题，尤其是生产者消费者、读者写者这类经典模型

多线程题欢聚这份卷子里也有涉及，建议掌握std::thread、std::mutex、std::condition_variable的基本用法，再理解原子变量和锁的区别。笔试里如果让你写一个线程安全的单例，建议直接写C++11的Magic Static版本，代码最简洁：

class Singleton { public: static Singleton& getInstance() { static Singleton instance; // C++11起，局部静态变量初始化是线程安全的 return instance; } Singleton(const Singleton&) = delete; Singleton& operator=(const Singleton&) = delete; private: Singleton() {} };

这段代码的考点是：C++11标准保证了局部静态变量的初始化是线程安全的，编译器会生成保护代码。背下来，笔试能用，面试能讲，性价比极高。

3. 音视频传输方向：从协议到底层链路的完整拆解

音视频传输是欢聚的老本行，笔试题通常不会让你写大段代码，而是考察你对协议和链路的理解。这部分的题有个特点：看起来是问技术，实际上是问业务。

3.1 必知必会：RTMP、HLS、WebRTC三者的定位差异

直播场景下最常见的三个协议，几乎每次笔试都会涉及。我建议你用“业务场景”来记忆，而不是死背协议格式。

• RTMP：基于TCP，延迟约2-5秒，是传统直播推流的绝对主力。Adobe搞的，但开源生态好，到现在国内直播推流还在大规模用
• HLS：基于HTTP，苹果推出，延迟通常在5-10秒以上，好处是穿防火墙能力强、CDN分发成本低，适合点播和弱互动场景的直播
• WebRTC：基于UDP，延迟能压到500毫秒以内，适合连麦、视频会议、在线课堂这类强互动场景

笔试常考的一道题是：实时连麦场景下，选RTMP还是WebRTC？为什么？

正确答案是WebRTC。因为连麦是双向实时通信，延迟必须控制在几百毫秒级别，RTMP的2-5秒延迟根本做不到。但如果你只说“因为WebRTC延迟低”，还不够。完整回答应该带上工作原理：WebRTC用UDP承载SRTP加密的媒体流，配合前向纠错（FEC）和丢包重传（NACK）在弱网下保质量，还支持带宽自适应。

3.2 推拉流全链路：一次直播是怎么跑通的

音视频方向的笔试题很喜欢让你画链路图（手写流程不是画图工具）。这里我给你一个可以直接套用的标准链路，笔试面试都能用：

采集 → 预处理（美颜/滤镜/降噪） → 编码（H.264/H.265/AAC） → 封装（FLV/MP4） → 推流（RTMP/WebRTC） → 边缘节点接入 → CDN分发 → 播放端拉流（HTTP-FLV/HLS） → 解码 → 渲染

这个链路里，笔试最常抠的细节是编码环节。比如会问：H.264编码中I帧、P帧、B帧的区别？GOP（Group of Pictures）设置多大合适？

快速回答思路：

• I帧是关键帧，完整编码一帧画面，解码时不需要参考其他帧
• P帧是前向预测帧，参考前面的I帧或P帧
• B帧是双向预测帧，参考前后帧，压缩率高但编码延迟大
• GOP越大，压缩率越高，但出错后恢复越慢，直播场景GOP一般建议2秒内

再补一个实操细节：直播推流如果网络抖动，RTMP会怎么做？答案是TCP层的重传机制会兜底，但重传会导致延迟累积。所以生产环境的推流端通常会增加一个自适应码率逻辑——检测到网络变差就自动降低编码码率，防止延迟无限拉大。这个思路笔试可能考，面试更可能考。

3.3 延迟优化：为什么你的直播会有3秒延迟

延迟优化是音视频岗的高频考点，也是欢聚这类直播公司最在乎的能力之一。笔试如果出场景题，大概率是这样的：

主播端到观众端延迟到了5秒，分析可能的原因并提出优化方案。

你可以按链路分段排查：

1. 采集端：摄像头采集buffer过大，加上采集分辨率高，产生延迟
2. 编码端：使用了B帧或过大GOP，导致编码缓冲延迟
3. 推流端：TCP拥塞控制导致带宽探测变慢
4. 服务端：转码集群排队，或边缘节点没有就近接入
5. 播放端：播放buffer设置过大（为保证流畅宁可多缓冲），Jitter Buffer吸收抖动造成延迟

优化方案的核心逻辑是在流畅和低延迟之间取平衡。生产环境常用的手段包括：关闭B帧、缩短GOP到1秒、启用UDP私有协议传输、播放端动态调整缓冲、服务端做智能B帧转码丢弃等。

这里给你一个独家经验：实际工作中，50%以上的高延迟问题出在播放端的缓冲策略上。播放器为了减少卡顿会把缓冲设到3-5秒，这在点播场景没问题，但直播场景就直接毁掉体验了。所以做音视频优化一定要有全局视角，不是只看某一段。

3.4 音视频方向的学习路线建议

如果在准备音视频方向的面试，我建议按这条路线来：

1. 先把H.264码流结构搞明白：SPS/PPS、I/P/B帧、GOP、码率控制
2. 然后掌握FLV/MP4封装格式，至少能手工解析出关键字段
3. 再学RTMP协议交互流程：握手、连接、创建流、推流/播放
4. 最后在电脑上搭一套实战环境：用OBS推流 + SRS或Nginx-RTMP服务端接收 + VLC拉流，把整个链路跑通

工具链这几件套就够了：FFmpeg（编解码与转封装）、OBS（推流端）、SRS（流媒体服务器）、Wireshark（抓包分析RTMP交互）、VLC（播放验证）。不要贪多，把这套环境跑熟，比看十篇博客都管用。

另外说一句很现实的：音视频岗校招对算法题的要求通常低于纯后端岗，但对工程的熟悉度要求更高。你有没有自己搭过流媒体服务、有没有用FFmpeg处理过视频，聊两句就暴露了。所以简历上如果有相关项目，投音视频岗的命中率会高很多。

4. 推荐算法方向：从业务理解到工程落地的考察逻辑

推荐算法方向在欢聚这份卷子里占比不算高，但题目很有代表性。它不考深度学习模型推导，而是考你对“推荐系统整体架构”和“业务目标”的理解。我把这类题的底层逻辑拆给你看。

4.1 推荐系统笔试的经典框架：召回→粗排→精排→重排

这道题几乎是推荐方向必考：请简述推荐系统的整体架构，说明各模块的功能。

我的标准答题框架是四层：

召回层：从全量内容池（几百万到上亿）里快速捞出几千到几万候选。常用策略包括：基于用户的协同过滤（UserCF）、基于物品的协同过滤（ItemCF）、向量召回（双塔模型）、热度召回、地域召回（直播场景很关键）。核心要求是快和广，召回率优先，精度可以牺牲。

粗排层：用轻量模型把几千条候选快速压缩到几百条。常用双塔模型、FM这类轻量模型，特征可以做交叉但不做太深的网络。目的是把明显不相关的候选过滤掉，减轻精排压力。

精排层：对几百条候选做精细打分，使用DeepFM、DIN、BST这类深度模型，特征工程极其丰富。产出准确的CTR/CVR预估分数，是推荐效果的核心。

重排层：结合业务规则对精排结果做最后调整，比如打散同类型内容、去除已看过的内容、插入广告位、加入运营强推内容等。重排直接面对用户体验，很多细节技巧都在这一层。

一个答题加分点：说完架构之后，主动补充一句“直播场景下推荐和短视频不同，直播是实时性的，内容过期极快，所以召回层必须把‘热度衰减’和‘同城/同语言’这类强实时特征纳入”。这一句话就能让面试官觉得你有业务sense，而不是只会背框架。

4.2 协同过滤：理解原理，更要能写出代码

协同过滤是推荐系统最经典的算法，笔试里可能出现基础代码题。我建议你至少能手撕一个基于物品的协同过滤（ItemCF）核心流程：

import numpy as np from collections import defaultdict # 用户-物品交互矩阵：行是用户，列是物品，1表示有点击/观看 interaction = np.array([ [1, 1, 0, 1, 0], [0, 1, 1, 0, 0], [1, 0, 1, 1, 1], [0, 0, 1, 0, 1], ]) def item_cf_similarity(interaction): n_items = interaction.shape[1] # 计算物品共现矩阵 co_occur = interaction.T @ interaction # 共现矩阵，co_occur[i][j]表示同时被点击的次数 # 计算每个物品的流行度（被点击次数），用于归一化 item_pop = interaction.sum(axis=0) sim_matrix = np.zeros((n_items, n_items)) for i in range(n_items): for j in range(n_items): if i == j or item_pop[i] == 0 or item_pop[j] == 0: continue # 余弦相似度：共现次数 / sqrt(物品i次数 * 物品j次数) sim_matrix[i][j] = co_occur[i][j] / np.sqrt(item_pop[i] * item_pop[j]) return sim_matrix sim = item_cf_similarity(interaction) print(sim)

这个实现里有一个重要的工程细节：为什么用余弦相似度而不是直接用共现次数？因为直接用共现次数会让热门物品占便宜——一个爆款视频和谁都共现，用它做推荐会失去个性化。除以流行度的平方根是经典做法，笔试和面试都能讲出道理。

4.3 特征工程：推荐系统的“隐藏分水岭”

很多人准备推荐算法岗，死磕模型结构，但欢聚这类公司更看重特征工程能力。原因很简单：线上模型的胜负，60%以上在特征，模型结构反而是相对标准化的。

笔试可能问：直播推荐中，你能想到哪些特征？

我建议你按特征类别组织答案：

• 用户特征：观看历史、停留时长、关注的主播、用户画像（年龄段、地域、性别）
• 内容特征：直播标题、主播分类、画面封面、历史互动数据（点赞、评论、送礼）
• 上下文特征：当前时间（早中晚）、星期几、设备类型、网络环境
• 交叉特征：用户偏好类别和当前直播类别的匹配度、用户和主播的互动历史

回答完再补一句：特征离线和在线一致性是工程里的坑。离线训练时用的特征和线上推理时不一致，模型效果会崩。这个点很多校招生不知道，你能说出来就是加分项。

4.4 AB实验：推荐算法岗必懂的业务语言

推荐算法方向笔试的最后一部分往往是AB实验相关题。典型问法：我们上线了一个新推荐模型，怎么评估它比旧模型好？

标准答题结构：

1. 确定实验指标：核心指标用人均观看时长、次日留存、人均互动次数；辅助指标观察人均送礼、分享率等
2. 设计分流：按照用户ID哈希分流，保证实验组和对照组用户特征分布均匀，流量比例建议先小后大（比如先10%）
3. 设定实验周期：至少跑7天，覆盖工作日和周末。因为直播匹配有明显的星期周期性
4. 显著性检验：用t检验或卡方检验判断指标差异是否显著，不能只看平均值的数值高低
5. 关注长期效果：短期指标涨不代表长期留存涨，必要时做更长周期的追踪实验

这里有个我踩过的坑：小流量实验时，实验组和对照组如果只看一天数据，数值波动会非常大，经常出现“新模型效果提升20%”的假象。正确的做法是看累积曲线是否持续稳定超过对照组，而不是某一天的绝对值。

5. 测试开发方向：从“找bug”到“建体系”

测试开发方向在很多人眼里是“点点点”，但大厂的测试开发完全不是这个定位。欢聚这类公司招测试开发，要的是能搭测试平台、写自动化框架、做性能压测、定位线上问题的人。这块的笔试题也很有特点——它考的是你的质量思维链路。

5.1 测试开发vs功能测试：本质区别在哪里

我见过太多人简历写“熟悉测试流程”，一问细节全崩。你想投测试开发岗，首先要搞清楚这个岗位和传统功能测试的差别。

笔试和面试中，你要让面试官觉得你理解这个差别。比如可以主动说：“我认为测试开发的核心不是写测试用例，而是思考如何用代码和工具让测试这件事变得更快、更稳、更省人力。我主要关注三层：单测和接口自动化保障功能正确性、性能压测保障系统容量、监控告警保障线上稳定性。”

这个回答一出口，你就和“只会点点点”的候选人拉开了差距。

5.2 用例设计方法：笔试的高频送分题

测试方向的笔试题里，用例设计几乎是必考的。常见考法有两种：一种是给你一个功能，让你写测试用例；一种是给你一段代码，让你设计测试策略。

给你一个万能思考框架，按这个顺序来，基本不会漏：

1. 功能测试：正常流程、异常流程、边界值
2. 兼容性测试：不同操作系统、浏览器、设备型号、网络环境
3. 性能测试：并发量、响应时间、吞吐量、资源占用
4. 安全测试：权限校验、SQL注入、敏感信息加密
5. 可靠性测试：断网重连、弱网模拟、杀进程恢复

举个例子，笔试如果考“给登录功能写测试用例”，大多数人只会写“输入正确账号密码能登录、错误密码提示错误”。但你按上面的框架来，可以写出来一堆高质量用例：密码长度边界（6位和7位）、密码包含特殊字符、账号不存在、连续输错5次锁定、切换网络后登录状态保持、token过期处理、多端同时登录、暴力破解防护。

我建议你把“登录功能”这个用例设计题当模板反复练。它足够简单，但能覆盖测试设计的方方面面，练熟之后你面试其他功能都能套用这个思维模式。

5.3 自动化测试框架选型与建设思路

测试开发笔试可能会问：你会选择什么自动化测试框架？为什么？

这个问题没有标准答案，但你要展示出“根据业务场景选型”的思考能力。我的建议是分场景回答：

• Web端UI自动化：Selenium或Playwright。Playwright是后起之秀，自带多浏览器兼容，等待策略更智能，我在新项目里优先用它
• 接口自动化：Python+Requests+pytest，轻量易维护，适合业务快速迭代
• 移动端App自动化：Appium，配合云真机平台做兼容性测试
• 性能测试：JMeter做接口压测，Locust做并发模拟，底层要能看懂CPU、内存、I/O监控
• 单元测试：C++项目用Google Test，Java项目用JUnit，Python项目用pytest

选型之外，面试官更想听到的是“如何搭建一套可持续运行的自动化体系”。核心考虑点是：用例稳定性、失败自动重试机制、CI流水线集成、测试报告可视化、回归任务的定时触发。我踩过最大的坑是UI自动化用例的稳定性——元素定位方式一变，几十条用例集体失败。后来我用Page Object模式封装页面元素，把元素定位收敛到独立的层，用例稳定性从60%提到了95%以上。

5.4 性能测试与线上问题排查

测试开发岗的性能测试题，通常不会让你背JMeter操作步骤，而是考你怎么设计压测方案和分析瓶颈。典型问法：

直播观看接口QPS突然下降，怎么排查？

我会按这个顺序回答：

1. 先确认是局部问题还是全局问题，看监控大盘：QPS、RT、错误率、CPU、内存、网络带宽
2. 再看最近是否有发布变更，查发布记录和日志
3. 如果怀疑依赖服务，看下游接口RT和超时时间设置
4. 现场抓包或dump线程，看是否有死锁或线程池耗尽
5. 结合压测复现，用JMeter或Locust回放流量，观察系统拐点

这个回答里体现出的是系统性排查思维——从现象到原因，从单点到全局。笔试如果考这种开放题，答题逻辑比最终答案重要得多。另外多说一嘴，性能压测一定要在测试环境做完整链路压测，而不只是单独压某个接口。我在实际项目中遇到过接口压测全绿，上线后整个集群被打挂的情况，原因就是测试环境没有模拟下游依赖的耗时和限流。压测压的是全链路容量，不是单个接口的极限。

5.5 测试开发方向的知识体系搭建

如果你想系统准备测试开发岗，我给你一条不走弯路的学习路径：

第一阶段（2-3周）：掌握Python基础、pytest测试框架、requests库做接口测试、Selenium或Playwright做UI自动化。目标是能写出一套最小可用的自动化用例。

第二阶段（2周）：做一个小项目，比如给一个开源项目写接口自动化测试框架，或用Appium跑通一套App端核心流程的自动化。项目要有代码、有文档、能演示。

第三阶段（1周）：学习性能测试工具和监控分析方法，重点是理解指标含义和解剖链路，不在工具本身钻研太深。

第四阶段（持续）：多看线上故障案例，学习根因分析方法。质量意识是在一次次复盘里练出来的，不是在文档里看出来的。

6. 备考路线图：基于这份B卷的实战准备建议

前面四个方向拆完了，最后给你一套落地的备考方案。别追求面面俱到，把有限的时间砸在性价比最高的地方。

6.1 按目标岗位分配复习权重

不同方向的同学，复习重点完全不同。我给你一个参考权重分配：

别把所有方向平均用力。卷子虽然四个方向都有，但你在笔试里不需要全做对——保证自己方向的高正确率，其他方向能答出基础概念就足够了。我见过太多人花大量时间想把四个方向全学完，结果每个方向都是半吊子，这恰恰是最亏的策略。

6.2 时间线：从零到笔试的8周规划

假设你还有8周时间，我给你一个可行的实战时间线：

• 第1-2周：专攻C/C++基础。智能指针、STL容器、内存管理、多线程。每天做10道基础题，周末写一个小型C++工程（比如一个线程安全的对象池），把语言底子打牢
• 第3-4周：根据目标方向做深度突破。音视频方向搭FFmpeg+SRS环境跑通推拉流；推荐方向手写协同过滤和DeepFM的简化实现；测试方向搭建pytest自动化框架加CI集成
• 第5-6周：刷目标方向的高频题。重点看往年真题的解题思路，不追求题海，而是每道题都能讲清楚“为什么这么解”
• 第7周：全真模拟笔试。找一份完整套题，按考试时间做一遍，重点练习时间分配
• 第8周：查漏补缺。把错题对应的知识点重新梳理，形成一张自己的知识图谱

这个时间线里最容易被忽略的是第7周的全真模拟。很多人直接上考场才发现时间不够用——前面基础题抠太久，后面业务题没时间写。模拟笔试不只要练题，还要练“取舍”：遇到卡住的选择题先标记跳过，把能拿的分先拿稳。

6.3 准备过程中的几个关键心态

最后分享几个心态层面的经验。这些不是鸡汤，是我见过太多候选人栽跟头后总结出来的实际教训。

第一个：别被“我不会”吓退。笔试遇到不会的题很正常，尤其是音视频和推荐这种垂直领域，和你目标方向不同的题不会做完全不影响录取。关键是别让一道不会的题打乱整场节奏。

第二个：展示思考过程比给出正确答案更值钱。笔试面试中，开放性问题没有唯一答案，面试官想看到的是你的分析框架和思维路径。哪怕你的方案不完美，只要逻辑自洽、能自圆其说，就能拿到高分。

第三个：项目经历比八股文更重要。校招简历上，一个你亲手做出来并跑通的C++项目，比刷300道LeetCode更有说服力。建议花时间把一个小项目做到极致，包括代码规范、文档注释、性能优化，这些细节会在面试中被放大。

第四个：保持对业务的好奇心。欢聚的笔试题之所以这么出，就是因为它们的业务就是这样跑的。你在准备时试着多问一句“为什么这个技术要点在这个业务场景里特别重要”，而不是单纯记忆知识点，这会让你在面试中显得与众不同。

我把这份卷子的四个方向拆完，又把备考路线理了一遍，核心想表达的就一句话：校招笔试筛的不是谁背得多，而是谁理解得深、能落地。不管你是想投C/C++开发、音视频传输、推荐算法还是测试开发，把地基打牢，把业务链路想清楚，把亲手做过的项目讲透，这份卷子就没那么可怕了。