Oracle首席工程师：技术面试中，怎样的问题才是好问题？( 三 ) 作者介绍熊燚

比如，候选人是否具备正直的品格。在 OCI ， debrief 的结果，通常有 hire 和 no hire 两种。但是有一种情况，可以归结到一个特殊的 “never hire” 里面去，这样的候选人没有面试冷冻期，不会有职位和级别的讨论，就是一个 “永不考虑” 聘用——这就是品格问题。品格问题会导致 never hire 的出现，比如候选人对当前的所在职位说谎了。
再比如，和团队的契合程度。不同的团队，接纳候选人的程度和要求都是不一样的。一个典型的例子是，有时候我们发现，有的候选人在投票的边界线上，即本身是具备相当的潜力的，但是由于缺乏相关领域经验，且在某些方面显示出方法明显不得要领。如果团队中有成熟、有经验的工程师可以带着，团队也有一定的空间允许他花更长的时间学习和成长，那么最后的结论就是 hire ，否则就是 no hire 。你也可以看出，很多时候这样的决定都不是非黑即白的，影响的因素是多方面的。
再再比如，性格不兼容导致的风险。我遇到过一例，候选人在面试过程中，在多轮面试中都表现出高傲和自满的个性。这成为了一个担心招聘进来以后风险过高的重要方面，于是最后我们放弃了这个候选人，尽管这个候选人的技术方面是没有问题的。那么有人可能会说，聪明人都是有个性的。但其实 “有个性” 和 “难相处” 有着微妙的差别，再包容的团队也有自己的底线。我们当然不希望错过优秀的人才，但是这并不代表不计代价。
从这几个方面也能看出，这些 “非能力” 的考察项，往往具备着或 0 或 1 的 “red flag” 的特点。
面试官一般不会花心思在这部分的考察上，但如果发现这方面的问题，且了解过后。那结果往往就会是一个明确的否决票，而这个否决票是和级别、职位无关的。
三、回看那个案例
讲完了技术面试的目的，再来回看最初那个案例。那个案例中所记叙的面试过程，对于技术面试的技术能力和非技术能力的考察，是否有覆盖呢？我们不妨一条一条看吧：
1、技术能力方面
分析问题，整理需求的能力：这一条考察的程度明显是不够的。给出的问题，是一个明确的、具体的算法题，也就是要实现一个 LRU 队列。也许这其中存在着问题分析和需求整理的空间，但对于具体算法题来说，这个空间显然并不大。而且候选人闷头就写了，这方面无从考察。
这个问题对于一个初级工程师的面试来说可能还好一些，我通常没有微词。可要用来面试一个经验丰富的工程师，我是很不赞成纯算法题面试的，这就是其中的一个重要原因。
根据需求来设计系统的能力：这一点的覆盖基本为 0 。上来就写代码了，不清楚思考的过程，也更谈不上什么系统设计了。
将核心逻辑实现的能力：这条确实是这种面试方式能够覆盖的部分。因为整个过程，就是候选人思考并实现编码的过程，只不过面试官能得到的只有一个 “结果” ，而非整个 “过程” 。这样的数据，反映出来在核心逻辑实现方面的价值，就要大打折扣了。
经验和其它工程能力：也许能够从代码的实现上获知一部分，但这一条考察的程度也显然是很不够的。
2、非技术能力方面
沟通合作的能力：这是最大的问题，因为这方面是远远不足的。整个过程没有沟通，没有合作，只有默默地做题。
热情和兴趣：这个过程很难从这个角度获取足够的候选人在热情和兴趣方面展示出来的信息。
学习能力：同上。
小结
总的来说，“将核心逻辑实现的能力” 可能还勉强过得去。这样的面试方式，并不能全面、合理地考察候选人作为软件工程师的综合素质。
事实上，联想实际工作。如果你的团队中有这样一个工程师，拿到一句简单的需求，不确认问题，不沟通设计，不讨论方案，直接就开始埋头苦干，就算能写出可以工作的代码来，这是不是依然是一件无比恐怖的事情？