谈谈面试

因为有同事离开上海，需要补缺，所以最近在密集的进行面试。遇上有个候选人强烈要求我们在五一假期里做面试（因为疫情的关系，实际上是电面），所以和他约了五一晚上聊聊。

然后我对面试结果不太满意，感觉他想问题思路有点不直接，后面让写一个简单的小函数（难度比leetcode easy还要低）也写得非常的离谱，所以就直接告诉他不能让他过。自觉当时自己的语气非常诚恳了，不给过的原因也算解释清楚了。第二天发现他在挂了电话不久发了一条短信给我，大意是自己已经拿到了字节跳动的offer，阿里的面试也快过了，我们这样的小破公司居然有脸挂他，居然不关心他擅长的工程能力，反而和他纠结循环的O(n)和O(n^2)，语气极尽嘲讽。

可以听到外界的批评是一件好事，但是这个批评该不该接受还是需要自己判断。我觉得面试这件事本来就是一件非常主观的事情，这不是高考那种全面考察个人能力的测试，顶多几个小时（多轮面试），只够考察用人公司最关心的那几个点，有点儿像我重点考语文现代文阅读。如果这项成绩很差，就算面试者表示自己别的地方水平可高了，我也只会说，亲，那很好，但不是我们最关心的。

每个团队都有自己招人最关注的点，这个可能是团队长期形成的习惯，所以，面试更多的是去感觉这个人是不是会适合自己所在的这个团队。我们这边一直以来的风格就是代码轻微洁癖，努力维持在team中流转的代码质量尽量的高，但是这份努力的前提是大家的代码水平都还过得去。我不喜欢看到那些如同鼻涕虫一般黏黏糊糊的代码，充满了不知所谓的逻辑，这件事比我没有跟上业界最好最酷的工程实践步伐要让我难受多了。

这件事另外让我想讨论的是，对于一线非infra的程序员来讲，是否有脱离代码能力的工程能力。我的答案是否，因为不管怎么样，最终的业务逻辑依然需要靠程序员手写代码去填满。在所谓"big data"的情景里，一个函数可能要被反复调用百亿次，O(n)和O(n^2)差异巨大，对于我们这种比较贫穷的公司，不能随便给集群加机器，代码的效率就特别重要。

最后，无论什么时候，我依然相信，程序员用正确的方式解决问题，写正确的代码来实现业务是最重要和核心的能力。诚然条条大路通罗马，但是只有一条最快最省力，我们的追求就是无限的去逼近这条线路。这是编程中最核心，最永恒的那一部分。反之，程序员放弃自己这一部分能力，将只是把玩过各种工具称为工程能力，并视之为核心竞争力，那么现在的遍地996和35岁现象，就完全不值得同情。