做了这么多年技术面试，回头看，最贵的成本不是招错一个人，而是你根本不知道自己错在哪里。

早期我面试有个执念：能把算法题写出来的人，工程能力不会差。这个信念让我错过了一些人，也让我招错了一些人。直到有次被现实教育——一个面试表现非常出色的候选人，入职三个月就让我开始怀疑自己的判断力。

第一次看走眼

那个候选人来的时候，我们聊了两个小时。从系统设计到编码细节，他都能接住。我问他一个并发场景怎么处理，他几乎是脱口而出地给了三种方案，还主动比较了优劣。

面试结束我就跟团队说，这个人我要了。

入职后呢？代码确实写得不错，Review也能过。但慢慢地问题浮出来了：跟产品对需求理解有偏差时，他不会主动澄清，而是按自己的理解做完再说。跟后端联调遇到接口不一致，他倾向于等别人改而不是沟通解决。分配任务时，他永远选技术最有趣的那个，而不是业务最紧急的那个。

三个月后我开始反思：我在面试里到底看到了什么？

答案是：我看到了一个"面试能力强"的人，但没看到一个"工程能力强"的人。这两个东西，重叠度远没有我想象的高。

"流畅"的陷阱

上个月，一个朋友在群里吐槽：他们的在线文档产品要加多人协作功能，技术负责人评估了一下，给了个方案——用 WebSocket 广播所有编辑操作，冲突了就提示用户"文档已被他人修改，请刷新后重试"。

我问他，你们打算让用户刷新多少次才能写完一段话？

这不是段子。在我见过的技术选型里，"广播 + 冲突提示"仍然是很多团队处理实时协作的第一反应。理由很简单——实现成本低，逻辑好理解。但这条路的尽头，是一个永远填不完的坑。

冲突不是边缘情况

想象一个场景：两个人同时编辑同一份文档的同一行。A 把"用户协议"改成了"服务条款"，B 在同一位置加了个逗号。两个操作几乎同时发生，网络延迟让它们到达服务器的顺序不确定。

传统做法要么让 A 的修改覆盖 B 的（后到的覆盖先到的），要么把文档锁住让 B 等 A 改完。前者丢数据，后者体验差。

CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型）提供了第三条路：从数学上保证，只要操作满足交换律和结合律，无论网络传输顺序如何、延迟多长，所有客户端最终都会收敛到同一份数据。不需要中心服务器仲裁，不需要锁，不需要用户手动解决冲突。每个操作本身就是一个独立的、可传播的、可合并的单元。

从论文到产品的距离

最近帮一个 Node.js 中间层排查 OOM。一个聚合接口，把三四个下游接口的数据拼一下吐给前端，单次请求的数据量也就两三 MB,看着毫无压力。但 Grafana 上常驻内存随 QPS 线性爬升，GC 触发得越来越频繁,终于在晚高峰把进程撑爆了。

翻代码，逻辑大致是这样：

```js
const responses = await Promise.all(
endpoints.map(url => fetch(url).then(r => r.json()))
)
return res.json(merge(responses))
```

看起来人畜无害。`fetch` 拿到的是流，`.json()` 一次性消费它，`merge` 拼好再 `res.json()` 序列化出去。整个链路里数据至少出现了三份：原始响应体、解析后的对象、合并后的对象。再加上序列化时的字符串缓冲，单请求峰值轻松到原始数据的四五倍。这还没算 V8 把这些短命对象塞进新生代、触发 Scavenge 的开销。

在技术领域深耕近二十年，我先后跨越了通信、软件、互联网等多个行业，并在金融科技领域潜心笃行近十年。一路上，我经历了从后端到前端的技能迁移，也完成了从普通工程师到研发管理者的角色跃迁。我曾作为初创成员，从零开始搭建起一支高效的团队；也曾与伙伴们并肩作战，见证了核心业务突破万亿规模的高光时刻。

然而，当技术管理走到深水区，我逐渐感受到了那面无形的玻璃天花板——单纯的技术视角在面对复杂的商业战略、跨部门协同以及宏观市场变化时，常常显得力不从心。

为了突破认知瓶颈，重塑个人品牌，并构建更宽广的资源网络，我选择在职业生涯的黄金期主动求变。2026年，我顺利拿到了上海交通大学安泰MBA综合管理方向的拟录取通知。

这段备考之路，既是一次严苛的自我测试，也是一场关于"取舍"的修行。以下是我的一些实战经验，希望能为正在筹备考研的学弟学妹们提供一些落地、有价值的参考。

一、择校：谋定后动，选择最契合的土壤

对于在职备考的人来说，精力的分配是极其奢侈的，因此择校的精准度决定了备考的性价比。我选择交大安泰MBA，主要基于三个维度的考量：