背景

最近去面试，遇到了一个很糟心的问题： 我之前做过很多重要的项目，但却很难让面试官理解到里面的知识量和复杂度！

之前在的公司是一个中小型公司，所在项目也是一个新项目，所以大多数时候，做的事情对时间的要求都比较紧，不是那种一个具体的小领域可以做很久的状态（比如，我们基础架构组的生命周期才1年而已），这就有一个问题存在： 所做过的各项事情，都是在时间非常短的情况下完成的，因此肯定有很多的取舍，重点和核心往往不是面试中大家容易挖掘的点，而大多数面试官又很难同理到你当时的状态是什么样的。

描述地有点抽象，举个例子：
做性能测试的时候，周期是一个季度，人员是我自己，事情是 完善观测性建设、构建整套性能测试体系、性能测试及问题分析、性能优化。
抽象来看，似乎就这么个事，但即使是简单的一环 “构建性能测试体系” 就有无数多超大量的工作，比如 “调研市面上最常用的 http 测试框架” 就需要对 locust、k6、jmeter 等等做实践测试，每一个环境的搭建、每一个用例的编写、每一个实践运行 都是有大量工作要做的。 而这仅仅是整个性能体系当中很很很很不足为道的一环。

但是在(大厂)面试官看来却不是很能理解里面的复杂度，可能对他们而言，大多数东西都是有其他岗位的同学准备好，他们自己只需要参与其中的一部分就好了，这样也就能把这部分做得更深入。

一个实际的例子： 我和一个面试官描述了压测这套体系，其中提到一嘴 “kafka 的优化”，然后面试官就开始和我交流起 kafka 来了，问我在使用 kafka 遇到过什么问题…… 可是，我们都是比较轻量在使用 kafka，优化项无非也就是 ACK降级、batch调优、消息体积约束、commit策略优化 这些而已，后面又继续去深聊 kafka 的组件…… 虽然也能不深入地聊一点，但是啊！相比于整个压测体系的 100分工作，kafka 调优只不到 5% 而已！

面试官在考察的时候，经常容易把对一个 「具体技术组件认识的深度」 作为你 「技术的深度」 的评估要素！

可是我所做的东西的复杂度并不在此啊，核心是在 时间有限、无前人经验、全体系构建 上，任何中间的一环，如果是卡点，自然会进一步挖掘深入，但在正常使用的开源体系中，又怎会遇到卡点呢？

另外，我这几年每一年负责的领域都是不同的，第一年核心业务领域的开发，第二年基础架构和性能体系，第三年devops和私有部署。

但是面试官在考察时是不太能理解你在不同领域所做事情的复杂度的，跨领域、场景比较复杂、无前人经验、时间有限、全体系构建 所需要的知识密度是非常高的。 比如，私有部署。 如果是一个研发面试官，他可能很难理解 你需要对 k8s 的整套体系有比较熟练的掌握、对 k8s 集群搭建所需的各项功能有充分的调研、对每个服务组件有充足的理解、对 linux 的操作有大量的经验…… 然后你才能做出方案的决策 以及 方案的落地。 面试官在问的时候，基本不会问到你对 k8s 的网络模式理解 这些问题，即使你觉得这部分的复杂度还挺高……

我能理解这样做是大多数场景下比较高效的方式，能快速排除一些浮于表面的候选人，但我不能因此就被误伤了。

我觉得我需要做点什么，让我负责的所有这些东西被记录下来，一方面让自己在将来也能够记得曾经做过的事情究竟有些什么，另一方面也让知识呈现出本应具备的全貌。

解决方案就是： 写专栏！

我要写的专栏

我主体做过 前端 和 服务端 和 devops 的工作，因此专栏也会分成这几个领域，目前的重点仍然应当是 服务端。 这几年的直接工作中，主要涉及的方向有：

• 性能测试
• 序列化方案
• 协同及状态同步方案
• 基础架构
• 私有部署

以上就作为我第一期专栏的选题了，不要有太多负担，先写，其他等后面再说。

---

Vanity can easily overtake wisdom. It usually overtakes common sense.
— Julian Casablancas