技术管理者当面试官的5种段位

自己负责的摊子大了，难免会遇到招的岗位是自己不熟悉的技术领域的情况。如果是技术面的面试官，让应聘者觉得主管不懂技术倒是小事，如果没能摸透应聘者的技术功底，不小心招来了不能胜任的人，那事情就大了。即便作为综合面的面试官，如果能在面试时摸透应聘者的技术深度、潜在能力，帮技术面的面试官把把关也是好事；让应聘者觉得连部门经理都是懂技术的人，也会对公司的印象大大加分。

现在求职招聘都是双向选择。即便是综合面的负责人，最起码也要不能让应聘者觉得“完全不懂”。观察发现，不够称职的技术面或者综合面的面试官还是能分成几个段位的：

段位1：不懂装懂，故弄玄虚。“为什么你们用git，不用SVN？不用SVN怎么管理好分支的？”

自己都没搞清楚git是什么能干什么，就去怼应聘者，应聘者遇到这样的面试官大概率不会来这样的公司的。

段位2：问题宽泛主观，抢HR饭碗。“说一下过去工作中遇到的一个让你印象深刻的问题，以及后来是怎么解决的？”

这是对应聘者从事的岗位相关的技术领域完全不懂的情况下的问法。有的公司在HR面里面一般也会问类似的问题（当然了特别专业的HR除外）。作为一个不懂这一块的技术主管，被迫营业，也只能问出这样的问题来。

段位3：让应聘者当面试官的老师。“给我介绍一下什么是DDS？”

问了这个问题之后，应聘者可能会滔滔不绝，也可能会支支吾吾。从应聘者的反应来看确实能粗略的估计能力与水平。但应聘者所讲的是否有错误，是否有夸大的地方，这种最应该关注的地方反而无法被面试官抓住，最终结果可能是会吹牛会夸夸其词的面试通过了，真正做事严谨认真的人被刷掉了。

段位4：把面试当成笔试。“下面这段程序的输出结果是什么？”

到了这个段位，面试官已经从“不知道自己不知道”进阶到了“知道自己不知道”了，会提前准备一些题目来考核应聘者，也能从应聘者的回答中大概知道应聘者的水平层级。但这种形式的面试一是有点浪费双方的时间，二是只能给出是或否的判断，三是只能从一个点去评判，准备的题目不一定是应聘者最擅长的，不能挖掘出应聘者全面的知识深度分布图。

段位5及以上才是正常的面试。

正常的面试与“能力图谱”

正常的面试除了面试基本原则诸如充分准备、清晰结构、尊重与礼貌、开放性问题、有效倾听、互动交流、公正无私、透明反馈、专业发展建议、合规性之外，我认为应该是能充分且完全的挖掘到应聘者的能力图谱。能力图谱是我自己造的名词，指的是应聘者在不同的知识领域、不同的能力维度内的经验、能力强度的3D曲面图。形如下图，可以一眼看出应聘者哪方面的能力最强，最强的这一方面有多强，以及薄弱点在哪里，薄弱点与擅长点之间有多强的相关性。

正因为如此，我比较反对在面试中，很突兀的询问应聘者“你了解xx吗/你知道xx里面的xxx是怎么计算出来的吗？”。纵然xx可能是在公司里面最需要、最常见、最普遍的一个技术，但这种问法只能问到一个点，而没法了解到应聘者的真实能力图谱。

我一直使用的一个方法是在面试开场的时候，询问应聘者“在你简历这么多项目里，你最熟悉、参与度最高的项目是哪个，你在里面负责哪一块”，然后再就应聘者了解的最深入的领域进行探查，了解他的方案、他的考虑点以及其中容易出问题的地方的规避措施，探查出他在讲述这些的时候暴露出来的逻辑漏洞，探出应聘者的真实水平。一般来说，沿着应聘者最深入的领域不断地往上游或者往下游摸索，很快就能探清应聘者全部的能力图谱，既弄清楚了应聘者有哪些经验，也能搞清楚能力擅长点在哪，同时能够摸清楚能力上限有多高。

如何面试不懂的岗位

既然在正常的面试中，要直面应聘者最擅长的领域，难免会遇到人家擅长的、刚好自己不熟悉的情况。遇到不熟悉的领域，我又不甘愿将自己降为段位5以下。经过这么多年的摸爬滚打，我摸索出来了几种应对这种情况的方案，能让自己快速提升到段位5。其实，作为一个面试官，同时也是分管这个领域的负责人，对于自己所面试的领域再不熟悉，也得对里面的概念有一个初步的了解，好让自己跟应聘者能有共同语言，聊到相同的频道上。要不然面试一位嵌入式开发工程师，人家跟你讲配了什么寄存器，而你连什么是寄存器都不知道，那技术这一块就聊不下去了。

1. 考察上游的知识

面试公司的AUTOSAR开发工程师时，我之前没用过AUTOSAR，而AUTOSAR是一个“一年略知一二，两年开始上手，三年才能出徒”的东西，仅仅凭借我几个小时的学习了解，是很难考察出一年以上AUTOSAR经验的工程师的技术功底的区别的。但我知道AUTOSAR工程师在开发的时候大多只需要在图形化界面上做一些配置，不需要接触代码。他们在工作时，普遍的一个现象就是工程师接到需求就一头扎进去，开始做自己负责的模块，做完一个项目之后又去做另外一个项目，而不会去思考自己配置的模块的工作原理是什么，核心的实现方式是什么，这种方式对资源的消耗有多少。

针对这样的情况，我提前花了两个小时读了AUTOSAR各个模块内部的工作机理，以及模块之间交互的机理的文章，让我对整个AUTOSAR的运作机制有了比较全面、比较宏观的理解。后面再去面试AUTOSAR工程师时，他们平时的工作是怎么用AUTOSAR的各个模块，而我问的问题是AUTOSAR各个模块背后的工作机理。这问题一下子就提升了一个档次，而且能很明显的探查出AUTOSAR工程师的技术能力、全局的思维以及思维能力的差异。

2. 研读法规

功能安全对我来说又是一个不得不面对的并不熟悉的技术领域。功能安全里面一大堆新的概念、新的理论、新的理念、新的方法论以及新的工具，都需要大量的时间去熟悉、去理解。但我知道整个功能安全的理论都是基于ISO26262（在ISO26262以前是IEC61508）这个标准的，功能安全工程师对ISO26262标准的理解水平跟自身的能力与功能安全经验密切相关。初级的功能安全工程师能够知晓ISO26262里面的思路，中级工程师能知晓ISO26262里面的细节，而高级以及资深的工程师能知道ISO26262里面的每一条都是为什么。

针对这样的情况，稍微熟悉一下ISO26262的框架之后，可以针对应聘者最熟悉的章节，去揪ISO26262里面的细节，针对某一个很小的点去跟功能安全工程师进行探讨。可以去找ISO26262里面不太容易理解的地方，让应聘者去阐明ISO26262这么设置的考量点在哪里。也可以去找一个ISO26262里面的公式，去探讨公式是怎么推导出来的，去探讨这个公式的适用条件是什么，以及背后所代表的实际物理意义是什么。

同样的，对于一些测试工程师，整体的工作也是基于法规，这个时候完全可以通过法规来了解清楚应聘者的能力图谱。

3. 考察基本功

对于一些需要写一些测试脚本的岗位，比如软件测试、总线测试以及集成测试的工程师，他们本职工作可能是一些非常细分领域的细分场景的测试，具有很强的专业性，如果之前没有接触过，可能无法理解他们的工作内容以及主动做的一些事情的含金量。但这些工程师做到一定的程度一定的级别，一定是要能掌握自动化测试的。而掌握自动化测试就一定要会写代码。而写代码作为一项通用的技能，就好考察多了。

同样的，对于一些开发人员来说，不管开发的是什么奇奇怪怪的东西，万变不离其宗，最终都会回归到大学里面学到的那些东西。

4. 从测试验证方法谈起

有时候会碰到一些从事的工作非常专业的应聘者，当然这个“专业”是相对自己的认知水平而言的。有一次遇到了一位应聘者，他说他自己做的是相机上的相位自动对焦算法（PDAF算法）。在那之前，PDAF的工作原理我没有听说过，不明白这种对焦方式带来的好处是什么，当然了也就不知道他所开创的那种算法有什么先进性了。但我当时直接问他，在设计这个算法之初，相比之前的算法，目标是优化哪几个参数，这几个参数是怎么测试的，为什么这么测试，以及最终的测试结果如何。在他回答重点关注哪几个指标的时候，我一下子就明白了这种算法能带来的好处是什么，限制又在哪里。而当我下一个问题问到基于这几个参数的快速迭代优化，是怎么搭建的测试台架与测试环境的时候，他想了一会儿说是通过实际的整机测试去验证。基于这样的回答，我推测他本人并没有参与PDAF算法的前期快速迭代开发，只是后期维护修复了几个bug，并在面试前对PDAF做了一些理论性的了解。这个推测也在随后的面试中得到了印证。

我相信，一个对原理摸透的人，了解真正的性能瓶颈所在之后，才能提出完整的、有意义的测评方案来。而测评方案，又是从测试验证角度能明显能看到的。

5. 考察意识

以软件开发人员为例，工作年限不同的工程师，在开发代码的时候脑袋里想的东西是不一样的，交付的时候也就会表现出来看得见的不同。就如同新司机上路之后只能看前面一个车道，而老司机可以做到眼观四路耳听八方一样，软件开发新手在交付的时候只会想自己需求终于开发完了，而老程序员会在开发的时候就想架构是否可靠、代码是否可读性高、模块是否复用了、接口是否封装好了，以及相应的逻辑是否理清楚了、是否做了面向测试的开发，等等等等。

一般来说，软件开发人员在工作一年之后，开始有了写注释的意识。在工作两三年之后，开始有了交付前先做自测的意识。在工作四五年之后，开始有了开发前先写文档、开发后把文档补全的意识。工作更长时间之后，开始有了软件工程的意识与行为。如果意识形成的时间比上面所说的短，那说明这个开发人员相比同龄人有更多的经验，能力与水平也相对同龄人会更高一些。我遇到的最优秀的人，在毕业入职半年之后，就已经有了刻骨铭心般的交付前自测意识，而且在交付的时候会主动附上自己的自测报告。这样的好苗子，大概率是在读书期间就已经积攒了不少经验，也吃过交付前没有自测的亏，才拥有了如此之强的自测意识。