一名本科生的七段实习经历(5)

仲夏奔忙

你站在楼宇的缝隙，可你没有退缩。

2024 年春，收到腾讯 WXG（微信事业群）视频号（北京）团队暑期实习的 offer 后，我的一面面试官（既是同校学长，也是之后的 mentor），问我什么时候能入职。

我估摸着暑期实习最早也要 6 月份开始吧，最好先等我结束学校里的期末，能够全心投入实习，所以答复的是 5 月底或 6 月初。

快到 5 月时，学长来催我说，如果想转正的话，尽量早点入职，实习时间更长，机会也会更大一些。

的确，我是有争取转正的想法。在当时的我看来，微信视频号，目前属于整个腾讯的核心发展业务，倘若能在这里顺利转正，未来的前途可谓一片光明。

因此，我比原计划提前两周离开了正在实习的百度，随即入职仅一街之隔的腾讯。

腾讯并不像百度那样有统一的入职培训，经过了简单的入职流程，我和 mentor 联系，来到了工位。

非常不巧，此时分配给我的电脑是一台 Windows 台式机，大概是今年暑期招的实习生太多了，而我入职的并不算早，没有 Mac 笔记本能领了。

（所幸，C++ 后端开发一般都是连接远程开发机用于写代码和测试，影响不大。）

我的 mentor 从事算法岗，而我干的却是后台开发，因此会有组内另外一位开发同事来直接指导我。

事实上，在我的实习过程中，他也一直都扮演着 mentor （导师）的角色，耐心地提供了许多指导和帮助。

后来在会议室开会时，由于我没有电脑可用，只能对着手机、用纸质笔记本记录，也是他帮我申请换成了 Mac。

入职的第一周，依旧是先简单熟悉，配置环境，阅读文档，准备串讲。

我逐渐发现，大组内今年招了“海量”实习生，我已经算来的晚的了，之后还有些陆续入职的，实习生数量甚至占到了正式员工的 1/3 左右。

此前，我从未见过一个组中有如此多实习同学的情况。而且他们的背景履历也都相当优秀，来自北京的各大 top 高校，我则是其中唯一一位本科生。

这也意味着我面临的转正竞争可能异常激烈。

我们组虽然属于视频号，但并不负责主站的业务（微信“视频号”页直接呈现的推荐流，由微信广州总部的团队负责）。组里今年新承接了几个业务方向，包括图文、长视频、听一听、音频等功能的推荐系统，尝试基于微信打造出覆盖各类群体的社区（对标手机上常见的几款 APP），目前都还处于试水阶段。

串讲算是第一个考验：每名实习生会被分配到不同的业务方向，先花一段时间熟悉现状，然后进行一次业务串讲，组内会有许多同事关注和提问。

我来得晚，因此有幸先听了几位更早入职的同学做的串讲。

一般来说，在技术上潜心深入的同学，在表达上可能会有所欠缺。但整体听下来，他们都表达流利、逻辑清晰，即使面对提问刁难也往往表现得思维敏捷、应对自如。

看来能来到这里，都是经过了重重筛选的。

入职不久，我请了假应对期末考试，又回了家当高考招生志愿者；这边的进度也就不得不延误，入职近一月才完成串讲，还算顺利，毕竟在百度也有过一次经验了。

在应对同事提问的过程中我便能感受到，这边会比百度的同事更少关注技术细节，更看重整体思路，以及能否快速上手完成需求。

其中一个重要因素大概是，这边的组长、各方向负责人均为算法出身，不像百度那种策略算法与工程架构分离的组织架构，而是在同一个团队内，算法主导推进、开发辅助干活，敏捷高效地进行迭代。

之后的时间里就是慢慢干活，到暑期接近尾声时，会有一次统一的转正答辩。为了应对这个答辩，mentor 往往会分配一个相对完整的项目让实习生完成。

对于后台开发而言，主要工作就是应对算法提出的各类具体需求，链路搭建、策略编排、特征计算等，帮助实现更好的推荐效果，并且保障服务的性能和稳定性。

我刚开始干活时的感受并不算美好：

代码有些混乱，基建尚不完善，大仓容易卡住开发机，代码编译一次要等几十分钟。

debug 工具是没有的，commit 是可以随便提的，代码合入是不需要 review 的，master 是不一定能编译的。

的确，WXG 推崇小而精的团队架构，支持快速试错和高效迭代，即使是实习生也能有较大的自主权，这也要求技术同学有着更高的工作效率、编码能力和风险控制能力。

整体来说，腾讯作为老牌互联网巨头，各个事业群相对独立，而 WXG 又属于其中比较超然的存在：

坐拥微信这一顶级社交产品，有着极深的护城河；

因此，深耕技术并非关键，如何最大化现有优势、持续吸引年轻用户留在平台才是部门层面最关心的事情。

比如视频号，尽管起步较晚，技术实力在大厂中并不算最领先，却能借助微信生态实现弯道超车。

我选择来这里，本就不是为了追求技术的精进，而是看好其产品和业务前景，渴望跟随着业务的高速发展获取超额回报。

（即使是顶级大厂，其技术底座也往往是由极少数技术大神完成从 0 到 1 的架构筑基，大部分的工程师则是在其之上堆砌砖石）

我的开发导师实力很强，一个人承接着多个方向的工作，同时处理许多算法同学提出的业务需求，常常忙得不可开交。

而我一开始只是跟着他接一些改配置、加特征的小需求，逐渐熟悉了工作流程，便上手了一个链路改造的工作。

对于一个视频推荐系统，在收到用户发来的请求之后，会先从海量的候选视频中召回用户可能感兴趣的视频，再进行多次排序与过滤，得到此时此刻最能吸引用户的一些视频，作为列表返回给用户。

其中，需要分别提取用户和视频的特征，形成用户画像和视频画像，并以此来预估用户对于各个视频感兴趣的程度。

而推荐算法的核心，就是如何更准确地实现这种预估。

随着预估模型愈发复杂，涉及到的特征也越来越多，原有的链路在开发和维护时都会有较大的负担，因此需要进行一定的改造，对特征进行统一的管理，减少重复计算带来的额外负载，同时也便于后续迭代。

这部分工作的难点主要在于链路的复杂性，高速的业务迭代也导致了技术债的积累，同时存在着设计缺失与局部过度设计的问题。

需要先通过对代码的考古，理清现有逻辑，再分阶段实施改造方案，进行验证。

本质上，针对这样一个大型项目进行改造，和对一道算法题的实现进行 debug，也没有太大的区别。

测试时还遇到过一个乌龙，由于一套代码耦合了不同的业务，误改了一行代码，导致其他业务的链路执行出了问题。

而我一开始只关注到我们业务的线上指标处于正常状况；所幸发现及时，迅速进行了回滚…

两个月的时间很短，在逐步完成了一些需求后，便开始为转正答辩做准备。

我向来不是一个擅长展示/汇报/演讲的人，时常会认为，把自己宝贵的时间用于求得别人的认可，是一件令我疲惫的事情。把明明不算复杂的事情，讲得花里胡哨，更是毫无意义。（其实不该这么绝对）

所以，我一开始的打算是通过文档进行汇报，朴素直白地展示工作。

但听了两位导师及同事的建议后，还是决定改为 PPT 的形式。在竞争激烈的情况下，除了实际的工作，表现形式上也不得不多下功夫。

既然已经身在局中，就要先遵循游戏规则。

对于内容的选取也颇有学问，由于答辩时间较短，不应呈现过于细节的实现原理，尤其在许多同事并不了解我所做的业务方向的情况下。

整体上，分成项目背景、原有痛点、工作思路、收益结果四个部分介绍工作，再加上个人介绍和对后续工作的展望。

通过有层次地组织，把工作内容讲明白的同时，也能证明自己思考和解决问题的能力。

我这时才意识到，对于展示，重要的绝非花哨的表述或炫酷的 PPT 画面，而是要学会从听众的角度思考，把他们愿意听的内容讲得清楚明白！

尽管道理并不复杂，但这又是难以从学校教育中学到的，毕竟很多课程听起来也常是云里雾里。

就这样，我顺利结束了自己人生的第一次转正答辩。

结果尚不可知，可既然已经无法改变了，不如抛之脑后，好好享受下剩余的时光。