第7章电话面试（1 / 2）

「您尾号8873的帐户于07月15日15：42入帐人民币2，700.00元，馀额8，483.71元。」

看来老吴真是被我吓坏了，不仅给了全额的工资，连之前画的饼都硬塞给了我。

林深看着手机上跳出的简讯，情不自禁的将视野右下角的系统界面调了出来。

这三个技能，没有一项是鸡肋啊！

只是……

【摸鱼币馀额：2.6】

【当前状态：无业】

【提示：未与有效工作单位建立正式雇佣关系，摸鱼币获取功能暂时锁定】

无业就无业吧。

林深望着远处渐次亮起的霓虹，心底那点隐约的不安，很快被一股更强烈的锐气取代。

人啊，总该有点自信。

更何况，他兜里揣着的，是整整十五年的未来。

-----------------

第二天上午九点五十五分，出租屋。

房间打扫得过分整洁，几乎不像一个二十二岁独居男生的屋子。地板光洁，书桌井然，连窗台上那盆半死不活的绿萝都被仔细擦过叶子。

林深觉得，植物也有权享受整洁的工作环境。

桌子上的笔记本电脑早已打开，屏幕上是林深花了一晚上时间整理的面试要点文档，按照「基础-项目-系统-认知」四个层次梳理的知识树。

旁边摊开的《编程珠玑》翻到「算法设计技术」一章，页边写满了细密的批注，间或夹杂着一些奇怪的涂鸦：一个歪歪扭扭的火箭，旁边写着「发射！」；一个瘫在椅子上的火柴人，标注「摸鱼态」；还有一行小字：「如果面试官问为什麽选腾讯，就说『因为食堂不错』——不，这个不行。」

手机电量100%，信号满格。一副半旧的入耳式耳机连接妥当，麦克风测试音清晰。林深已经对着镜子练习了三次「您好，我是林深」的语调——第一次太正经，像客服；第二次太随意，像约饭；第三次他故意压低声线，说完自己先笑场了：好像反派自我介绍。

此刻，他坐在椅子里，双手平放在膝盖上，闭眼调整呼吸。

紧张吗？

是这次的他过于放松了。

「好了，」他对自己说，「该疯的疯完了，现在该认真了。」

九点五十八分，手机屏幕准时亮起。

「您好，我是林深。」

「林深同学你好，我是腾讯的面试官，我叫周博涛。」

那个名字传入耳中的瞬间，林深的心脏猛地收缩了一下。

周博涛。

不是「有点意外」，而是头皮发麻的震撼。

前世在微信团队七年，他见过周博涛三次。一次是年度技术大会，周博涛在台上讲微信消息系统的架构演进，台下黑压压坐满了人，林深坐在最后一排，伸长脖子才能看清幻灯片上的小字。

一次是电梯里偶遇，他抱着一叠文档，周博涛和几个人走进来，讨论着什麽「用户触达率」和「漏斗模型」，他屏住呼吸，直到电梯到达才敢呼出来。最后一次，是周博涛升任事业群副总裁的全员邮件，他盯着那个名字看了很久，心想：这种级别的人物，离自己太远了。

而现在，这个「太远了」的人，正在电话那头，等着面试他。

重生的变数吗？还是……自己「巧合」地选择了「移动社交和通讯」这个方向引起了他的注意？

不重要了。

重要的是——周博涛这样的人，见过的天才和怪胎太多了。敷衍的丶模板化的丶缺乏思考深度的回答，在他面前只会瞬间暴露苍白。

但反过来想：这也意味着，只要你的回答有真东西，他一定能听懂。

赌一把。

赌自己十年积累的认知，赌那些对未来技术走向的模糊记忆，赌自己能把握住那个「优秀但合理」的微妙边界。

「可以的，周老师。」林深的声音平稳如常，但坐姿不自觉地挺直了三分——这不是谄媚，而是面对真正高手时，身体本能的认真。

「好，那我们开始。」周博涛的声音透过耳机传来，清晰丶稳定，带着技术人特有的那种直击要害，「首先请你简单自我介绍一下，重点说说你为什麽对移动开发感兴趣，以及你过去的项目经验。」

经典开场。

但林深知道，在周博涛这里，自我介绍从来不只是走形式。

他用两分钟时间，以比平时更凝练的节奏介绍了背景，但刻意在两个地方埋下钩子：一是在飞讯的「故障排查」，他强调了「从日志海量噪音中定位到配置项低级错误」的系统性排查思路；二是在个人天气应用中，他提到了「尝试根据网络状态动态调整数据刷新策略，平衡体验与耗电」。

不是展示「我做了什麽」，而是暗示「我会如何思考问题」。

周博涛安静听完，没有打断。然后第一个技术问题抛过来：「那我们聊聊基础。TCP和UDP的区别是什麽？在移动即时通讯的场景下，你会如何选择？」

基础题，但带着明确的场景导向，这很「周博涛」。他从来不喜欢抽象的理论，总要落到「为什麽要用」和「用了会怎样」上。

林深没有立刻回答。他停顿了恰到好处的两秒，仿佛在组织语言，实则在快速判断：该讲到什麽程度？

「TCP可靠，有序，有拥塞控制，但延迟相对高，需要三次握手建立连接；UDP不可靠，无序，但延迟低，无需连接。」基础部分他语速平稳，然后转向场景，「在移动IM场景下，我认为选择不能一概而论，而应该按消息的语义和容忍度分层处理。」

他故意用了「语义」这个词，这是后来IM系统设计中很关键的思路。

「文本消息丶已读回执丶关键状态同步，这些必须用TCP保证可靠投递和顺序。但像音视频通话的RTP包丶实时位置共享的坐标流，对延迟极度敏感，可以走UDP，在应用层做轻量级的丢包重传或前向纠错。」

他顿了顿，补充了一句看似随口，实则精心设计的话，「其实更理想的是能根据实时网络质量动态选择协议，比如在Wi-Fi下可以更激进地用UDP，在弱网下切回TCP保底——不过这需要客户端和伺服器有更强的状态协同。」

电话那头传来轻微的键盘敲击声，节奏似乎比刚才慢了一点。

「嗯。」周博涛的声音依旧平稳，「那如果要在客户端实现TCP长连接的心跳保活，你会怎麽设计心跳间隔？考虑哪些因素？」

问题深入了，林深知道，这是在考察工程权衡能力。

「首先要考虑运营商策略和系统限制，这是硬约束。不同运营商对NAT埠保留时间不同，从30秒到几分钟不等，我们需要以最短的那个为基线。」

他开始分层回答，「其次是电量，频繁心跳在移动端是不可持续的。我会设计一个自适应心跳算法：初始间隔保守一点，比如45秒；如果连续多个周期心跳成功且RTT稳定，逐步拉长间隔，最高可能到2-3分钟；一旦检测到网络切换丶心跳失败或延迟抖动，立刻重置为短间隔。」

他在这里稍微展开了一点：「其实心跳的目的不只是保活，还可以作为网络质量探针。我们可以在心跳包里携带极小的时间戳或序列号，通过往返延迟和丢包率，反过来推断当前网络状况，用于上层业务决策——比如决定是否预加载图片丶是否压缩文本。」

这个「心跳作为探针」的思路，在2010年还很少有人明确提出。