写给所有想在新年换工作的技术从业者

致所有想在新年动一动的朋友们：

1. 面试官视角

我正式开始给别人面试的时间应该是在2015年左右，这么算来我的“面试官生涯”应该也有五年多了，基本上占了自己职业生涯一半还多的时间。来来回回面过的人两三百个总是有的。

总体来讲，面试是个苦差事，我其实特别不喜欢给别人面试。因为要在短短的几十分钟之内，彻底认识一个人的难度是非常大的，尤其是做技术这一行。

评价一个人的标准无外乎个人的工作履历和参与过的项目。个人的工作履历有时候受限于平台和环境，并不一定每一个能力出众的候选人都有一份漂亮的履历。项目经验上，但凡参与过，提前做过充分准备的候选人，基本都能顺利回答面试官有关项目上的问题。

从我的面试经验来看，只凭简单的你问我答的形式，只能筛选出不要的。比如说：候选人过来面试却完全不做准备的，这类容易被归为态度问题，让面试官很担心入职之后在工作上候选人是不是也会采取相似的态度；工作履历和实际表述差距大到可以直接听出来的，这类候选人往往存在主观夸大个人履历的成分，其实骨子里还是对自己的不自信。这种不自信的产生有很多因素，有可能是候选人本身技术能力确实未达到岗位要求，也有可能是近几年工作过于懈怠被拉开了明显差距。

但如果想单纯通过简单问答形式找出自己想要的候选人其实是非常难的。难点在于，即使候选人回答的再出彩，这并不能代表候选人入职后一定会有高绩效。毕竟在技术领域的岗位里面，除了少数几个高级岗位，比如总监级别（其实我觉得即使是总监，也最好是技术专家，但往往人的精力有限，现代技术栈的宽度也越来越宽，确实很多高级别岗位的任职人员的工作重心会从纯技术上转移出去）以上的岗位更多的要求是有战略思维之外，大部分还是需要有非常强的实际编码能力。但编码能力是很难通过对话就能确认的。

那么实际上手写一段代码，其实是一种非常好的确认候选人工程能力的手段。工作履历可以美化，项目经历也可以夸大，但是自己亲手写出来的代码则是骗不了人的。

总体来说，作为面试官，能让候选人在面试的时候亲手写一段代码，确实是一件非常令人惬意且能快速辨别候选人能力的手段。

另外，有几个观点我想和大家一起分享下：

观点一：英雄不问出处

总体来讲，英雄不问出处这个观点和360行行行出状元的观点，都是政治正确的。但苦在最近行业内卷确实太严重了，所以对于很多口碑较好的企业，只能提高候选人的应聘门槛。对于HR来说，学历和毕业院校其实是非常好的一个选择。

但技术行业开始挑候选人毕业院校的问题，全部都归咎于HR吗？我觉得这个对HR也有些不公平。

除了HR的因素之外，还有一部分的逻辑大致是这样的：

我认为很多面试官挑选毕业院校的逻辑，不在于看中985/211高校的背景，更多的看中的是就读知名高校背后所代表的含义。能考上985/211高校的候选人，大部分说明自小学习能力不错，也就是底子不错，更文艺点的说法叫软性技能过硬。那么从985/211高校的候选人中，找到合适的人员的概率相对就会高。

当然，凡事都没有绝对。在985/211高校毕业的人中也有很多人后面就碌碌无为、泯然众人矣；非985/211高校毕业的也有人经过社会历练变得异常出众。但从大数定律上来说，这种筛选逻辑大致是不错的。

这里面的不公平在于，我们过早地为还未谋面的人打上了标签。从面试官的角度来看是概率性的问题，但对于候选人来讲则变成了是或否的残酷的二值逻辑。

观点二：关于稳定性

同样是行业内卷的问题，很多口碑好的企业已经形成了一条不成文的规定：三年两跳的候选人不要。

从HR的角度来讲，他们自然不愿意辛辛苦苦招聘来的候选人，还没有熟悉工作内容，没有作出什么实质性贡献的时候就从企业离职。因为招聘每个人企业都是需要负担成本的，如果招聘过来的人员普遍工作一段时间就离职了，HR的工作能力难免遭到质疑。

但跳槽频繁就一定意味着不稳定吗？我觉得不尽然，这得看情况。

本人就是这条不成文规定的受害者，也正是因为这个原因，达成了在某知名大厂四部门九面最终被刷下的壮举。我觉得我应该已经进入这家大厂的黑名单了，当然这家大厂也进入我的黑名单了（我胡汉三就算是饿死，死外面，从这里跳下去，也绝不可能再去！玩笑话~）。

怎么说呢，这个同观点一，一样不显得有多公平。对用人单位来说是个概率问题，对个人则变成了是或否的二值逻辑。

唯一能劝各位的，就是最近这两年，除非机会特别好，且自己已经准备好了接受新的更高级别的挑战，能不动就不动吧，活着就好。

观点三：问的高大上，实际不还是CRUDER

这是我接触到的很多人的普遍观点。这种观点和觉得上大学无用，大学教的知识在工作中绝大部分都用不到的观点，惊人的相似。

那这个观点错了吗？我不能说是完全错误的，但我个人确实不是这么理解的。那该如何解这个问题？我们可能需要换个角度去思考学习的本质是什么。

无论是我们在大学学习到的理论知识，还是我们在毕业之后学习到的工程知识，其本质都是在于增强我们自身的能量。如果我们只去理解书本中写的东西，不去深入思考的话，那学习始终停留在表面。我认为书本是打开心灵世界的钥匙，更多的是 引导我们自身去思考。只有将书本中看到的、学到的内容，经过自己的理解和加工，转换并加载入自我的知识体系内，才能真正算是学会了。

这其实是做技术的一个非常通用的要求，单纯学会某种技术，可能你一辈子都用不到，或者在某个狭窄的领域里日复一日地重复着使用，变成了自己的谋生手段。但如果我们将接触过的、了解到的知识都作为武器弹药储备在武器库中，也许在某一天遇到某个特定问题时，你会突然产生一种似曾相识的感受，你武器库中长期储备的弹药会自动上膛，完成致命一击！这就是完全不一样的境界了。差距在哪儿呢？差距就在于我们如何看待学习这件事。

低质量的运用就是拷贝别人的代码，直接用在自己的项目中，这叫抄袭；高质量的运用则是借鉴别人解决问题的思路，应用在自己的实际工作中，这叫创新。这一点也是我评价一个候选人技术发展潜力的核心标准。

2. 应聘者视角

我参加的面试不太多，但最近一段时间，尤其是去年参加的次数相对算多的了。由于在去年之前，绝大部分的时间都是我面试别人，突然在去年变成别人面试我，还真的挺不适应的。

总体来讲，当候选人年龄超过30岁以上，级别在技术专家/技术总监及以上的时候，通过公开招聘的方式就已经不太适合了。这里说的公开招聘，包括：

• 自己通过官方渠道投递简历；

• 由猎头推荐去相关公司应聘；

这时候，最好的方式还是需要通过熟人推荐，相互了解之后确认意向再决定去留。

为什么这样说的原因主要有：

1. 工作满10年和才毕业的毛头小子之间最大的区别，在于企业招聘你的心态会有很大的变化。对于有丰富经验的候选人来讲，企业更注重的是个人能快速融入团队，产出正向绩效。才毕业的年轻人，企业会有更多的耐心给与培养；

2. 资深岗位的必然要求是需要候选人具有独当一面的能力，而独当一面是一个相对的概念，并不完全等同于技术能力过硬，还有很多软性要求。这里面最大的不同在于，你的直属上司对你的信任感。对你信任或者不信任，将会对你的个人日常工作产生极大的影响。这时候，是否有人曾为你做过信用背书，就起到了至关重要的作用；

3. 较长的工作年限，意味着候选人对薪资和岗位也有更高要求。企业在高级岗位上招聘的成本确实会比初级岗位高出不少。那企业付出了更多的成本，理所当然就希望有更高的回报。凭面试的几次初步接洽是很难断定候选人是否胜任或者不胜任的。但若是有人为你做过信用背书，对方认可了你的过往经历和工作能力，则无论是薪资和岗位上都会更好协商；

4. 熟人推荐的情况下，面试过程相对会比较温和。尤其在最近如此内卷的大环境下，很多公司的HR说话基本都不留余地，专挑难听的话说，他们美其名曰压力面试。这些所谓的压力面试的问题，对于才踏入社会的新人来讲，忍忍也就罢了。但对于工作年限较长，且自身能力完全没问题的候选人，听起来就非常刺耳了。但这种情况下，如果是熟人推荐的话，HR基本不会进行所谓的压力面试（大家都懂的...）。

那如果我不要资深岗位的话，是不是就可以不考虑年龄，投入公开的招聘市场，最终找到自己满意的工作呢？

其实也比较难，因为HR会很难以理解你为何要降低要求来他们公司。从他们的角度来讲，一个人的要求若低于他所在层级的平均线，那是必然有问题的。这种情况下，他们会进行严格的背调，直到找到他们能接受的理由，才有可能最终放过你。即使最后，他们没有找到什么不利于你的证据，证明你不胜任，为了保险起见，大概率也是会拒绝掉你的。

在中国的现有国情下（也有可能全世界都一样），年龄越大，个人的流动性越差，每次选择所付出的机会成本也会越高。所以，我还是以自己的切身经历奉劝大家，最近这两年尽量稳住，没事不要乱换工作。如果真有机会了，一定要睁大眼睛确认是机会，不是陷阱！

3. 如何应对面试中的编程题目

首先，从面试官的角度来解释一下。现场面试中出的题目，其实不是为了考候选人的算法能力的。如果真有公司出的题目非常难，花在构思解题思路上的时间远远超过编写代码的时间的话，我觉得候选人可以直接离开。这种价值观已经偏离主旨的面试，其实是在浪费大家时间。

但这种现象其实并不少见，经常有面试官面着面着就把面试变成了辩论赛，非要争个对错，这不是候选人的问题，这是由于面试官本身不具备面试官应具备的能力导致的。好的面试官，应该是以引导为主，去发掘候选人的能力象限，然后在心中默默评估候选人能力与岗位要求的匹配度，最终给出面试结论。面试不是为了争个技术高低，也不是比谁更厉害。

面试中的编程题，主要考察的内容应该是：

• 候选人是否具有良好的抽象思维能力；

• 候选人是否具有良好的工程建模能力；

• 候选人是否具有良好的编码习惯；

• 候选人是否具备使用常用的简单算法（查找、排序）；

另外，还需要注意的是，候选人编写的代码其实不是为了解决问题，是为了向面试官展示自己具有解决实际问题的能力。因此代码可读性的优先级高于所有编程规范和原则！这点候选人一定要切记，写的代码是给人看的，一定要尽可能保证阅读舒适，其它的所有原则和规范，都是在阅读舒适之后才需要考虑的。

因此，如下的反设计原则的规则在处理现场编程题的时候是可以考虑的：

• 对象和结构不需要封装，可以直接将属性定义成public，省去get/set方法

• 花括号能省则省，较短的代码段在面试时，面试官更容易快速理解

• 能用简单结构的尽可能不要定义复杂结构，比如能用数组的不要用列表

还有，在编写代码的时候，要理解面试官的意图，面试官的核心目标是需要通过实际编写代码评估候选人的编码能力。比如面试官让你实现排序算法，你直接写了一句Collections.sort(a).这种情况，是该说你机灵呢，还是说你抖机灵呢……

最后，有时间的话，大家可以在LintCode和LeetCode上刷刷题，培养自身现场编程的感觉，有助于实际面试时的临场发挥。

下面是一个我最近一直在用的例子，我个人觉得其实蛮简单的，但到目前为止，都没有遇到写出来的代码能让我觉得耳目一新的候选人。

给定两个无重复元素的已经排好序的数组，写一段代码将这两个数组归并成一个无重复元素的数组

很简单吧，有兴趣的朋友可以自己本地写一写，然后和下面这段代码比较下：

    // 1. 用static省去new对象的麻烦；
    // 2. 用数组不要用列表;
    // 3. 用int不要用Integer，更不要纠结元素是不是需要支持更复杂的元素
    public static int[] merge(int[] a, int[] b) {
        // 不要用花括号，两行就可以写完，加上花括号，就变成了6行，这个地方就和常见的编程规范不一样了
        if (a == null) return b;
        if (b == null) return a;

        int[] c = new int[a.length + b.length];

        // 标准的双游标算法
        int i=0, j=0, k=0;
        while(i < a.length && j < b.length) {
            // 这个写法看你个人的喜好，我有时候甚至会缩写成下面这种格式
            if (a[i] < b[j]) {c[k++] = a[i++]; continue;}
            if (a[i] == b[j]) {c[k++] = a[i++]; j++; continue;}
            // 可以再写个if，也可以不写，逻辑上是等价的
            c[k++] = b[j++];
        }

        // 补全某一个没有处理的数组的剩余数据，用了下面的简写，减少行数
        for (; i<a.length; c[k++] = a[i++]);
        for (; j<b.length; c[k++] = b[j++]);

        // 拷贝新生成的数组，去掉没有值的元素
        int[] result = new int[k];
        System.arraycopy(c, 0, result, 0, k);
        return result;
    }