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

从这几个方面也能看出，这些 “非能力” 的考察项，往往具备着或 0 或 1 的 “red flag” 的特点。
面试官一般不会花心思在这部分的考察上，但如果发现这方面的问题，且了解过后。那结果往往就会是一个明确的否决票，而这个否决票是和级别、职位无关的。
三、回看那个案例
讲完了技术面试的目的，再来回看最初那个案例。那个案例中所记叙的面试过程，对于技术面试的技术能力和非技术能力的考察，是否有覆盖呢？我们不妨一条一条看吧：
1、技术能力方面
分析问题，整理需求的能力：这一条考察的程度明显是不够的。给出的问题，是一个明确的、具体的算法题，也就是要实现一个 LRU 队列。也许这其中存在着问题分析和需求整理的空间，但对于具体算法题来说，这个空间显然并不大。而且候选人闷头就写了，这方面无从考察。
这个问题对于一个初级工程师的面试来说可能还好一些，我通常没有微词。可要用来面试一个经验丰富的工程师，我是很不赞成纯算法题面试的，这就是其中的一个重要原因。
根据需求来设计系统的能力：这一点的覆盖基本为 0 。上来就写代码了，不清楚思考的过程，也更谈不上什么系统设计了。
将核心逻辑实现的能力：这条确实是这种面试方式能够覆盖的部分。因为整个过程，就是候选人思考并实现编码的过程，只不过面试官能得到的只有一个 “结果” ，而非整个 “过程” 。这样的数据，反映出来在核心逻辑实现方面的价值，就要大打折扣了。
经验和其它工程能力：也许能够从代码的实现上获知一部分，但这一条考察的程度也显然是很不够的。
2、非技术能力方面
沟通合作的能力：这是最大的问题，因为这方面是远远不足的。整个过程没有沟通，没有合作，只有默默地做题。
热情和兴趣：这个过程很难从这个角度获取足够的候选人在热情和兴趣方面展示出来的信息。
学习能力：同上。
小结
总的来说，“将核心逻辑实现的能力” 可能还勉强过得去。这样的面试方式，并不能全面、合理地考察候选人作为软件工程师的综合素质。
事实上，联想实际工作。如果你的团队中有这样一个工程师，拿到一句简单的需求，不确认问题，不沟通设计，不讨论方案，直接就开始埋头苦干，就算能写出可以工作的代码来，这是不是依然是一件无比恐怖的事情？
显然，我们的面试要尽可能避免这样的事情在真实世界中发生。我们要找的是软件工程师，不是只会刷题编码者。
这也是我把这个案例放在开头，作为反面案例的原因之一。等等， “之一”？！难道还有别的原因？
是的，这还没完，这个案例还有着其它弊端，我想再卖个关子——而现在，你可以想一想，再往下看。
四、怎样的问题才是 “好” 问题？
终于要正面回答标题中的问题了，到底怎样的问题才能真正称得上 “好” 问题呢？
下面是我认为最重要的几条衡量标准：
1、从模糊到清晰
首先，这个问题在一开始要足够模糊，以便让候选人可以逐层递进，逐步细化，寻根究底。
这个过程，其实就是将 “具体问题” 经过分析、归纳、思考、抽象并将其映射成为一个 “软件问题” 的过程。
在问题变得清晰的过程中，理想的情况是，候选人可以表现出主动性，即候选人可以在多数情况下引领讨论的思路，而不是面试官。面试官需要顺着候选人的思路，逐步框定下问题的讨论范畴，并明确到其核心实现是确实可以用软件的办法实现的。
在这样的状态下，候选人可以以自然的状态，具备相当自由度地发挥自己的能力。从这个过程中，可以观察得到候选人不同角度的特质了。
通过这种方式，也可以很大程度避免了已经知道 “标准答案” 的面试官，由于思路的局限性，而给面试施加源自于主观偏好的影响。
这就好像是开放世界的 RPG 游戏，有多个不同的路径都可以完成任务，玩家可以决策并决定主角的走向，但是这一切始终还要在游戏设计者的掌控之内。这当然是说的理想状态，有时候会有偏差，但我们朝着这个方向努力。
所以这也对面试官驾驭不同的状况有着很高的要求，毕竟面试官要对这个问题前前后后足够的熟悉，以便应对各种不同的细化场景。有一个常见的方式，是可以从一个自己已经足够熟悉的问题开始，比如自己曾经多年工作涉及的某类系统。