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

分析问题，整理需求的能力：一开始问题可能显得很模糊，但是优秀的且有经验的工程师可以识别出核心的诉求。这个 “识别” 的能力，下文我还会详述。这里的诉求可能有多个，但是考虑到时间的关系，面试过程中往往只会从某个角度覆盖其中的一两个；
根据需求来设计系统的能力：这里既包括功能性需求，又包括非功能性需求，前者是必须要涉及到的，但是后者也经常放在一起考量。其实这一点可大可小，它未必指系统设计中功能是否得到实现，并且这个过程中，可能会涉及到系统的扩展性、可用性、一致性等等其它方面；
将核心逻辑实现的能力：如今，考察比重容易被高估的算法和数据结构就大体上属于这一部分。它也分为功能和非功能的两个角度——功能上算法能否实现需求，非功能上算法是否具备足够的性能、编码是否遵循最佳实践、代码是否具备良好的可扩展性等等。而编码能力，指的是在思路达成一致以后，核心逻辑能不能落到纸面（代码）上。毕竟， “空谈误国，实战兴邦”；
经验和其它工程能力：这部分相对更为灵活。比如对测试能力的考察，即可以做怎样的测试来实现对于功能需求和非功能需求正确性的保证。对于特定的团队和项目来说，有时候会特别专注于特定的技术能力，比如前端的团队，需要考察前端的基础技能的。

考虑到时间、覆盖面和覆盖深度的权衡，上面这四点有时候不能在一轮面试中完全覆盖，但往往也会包含其中三点。比如，系统设计的面试可以着重覆盖 1、2、4 点，而编码为主的面试可以着重覆盖 1、3、4 点。
2、非技术能力方面
和技术能力考察不同的是，非技术能力考察在不同面试官中的特异性更大，换言之，每个人的角度和标准都可能不相同。
但我觉得下面这几条特别重要，因而是必须要覆盖到的：

沟通合作的能力：如果不计时间成本，最理想的面试是什么？其实就是一起工作，工作中才会有足够多必要的沟通，所以无论是正面的品质还是负面的问题都会无所遁形。可是面试的时间有限，我们没有办法实现真正的工作氛围，但依然可以模拟工作中一起考察、分析和解决问题的过程，而这个过程，就是要通过 “沟通” 串起来的。沟通是一个大的话题，具体的考察项有很多，比如，能不能接受建议？能不能讨论想法？有些候选人一旦进入自己的思考模式就听不进别的话了，于是一个点要反复强调几遍；而有的则是缺少 backbone ，稍微追问一下，也不思考，就立马改变主意；
热情和兴趣：热情和兴趣的影响是巨大的，都说兴趣是最好的老师，这部分是很难 “教出来” 的，对于初级工程师来说更是如此。热情和兴趣不但会影响到他们自己的未来发展，也会影响到整个团队的氛围；
学习能力：学习能力很大程度决定了候选人在新的岗位上进步的潜力。同样的基础和基本问题的解决能力，有的候选人能够 “一点就透” ，触类旁通，这就在一定程度上就反映了学习的能力。毫无疑问，软件工程师每天都在面对新问题，入职以后就会发现，不止问题是新的，代码是新的，连类库和工具都是新的。所以在成熟到能够有一定产出之前，这一步一定是学习。

技术能力和非技术能力，哪个更占主导？事实上，这二者都很重要，并且二者各自又具备不同的特点。
当然相对来说，非技术能力更加难以提高，因而这方面的问题要更加引起重视。比方说，要让一个对于软件领域缺乏热情和兴趣的候选人，在入职以后改头换面，是几乎不可能的一件事情。
3、其它方面
上面说的是技术面试中对于 “能力” 的考察。其实，还有一些考察项，严格来说并不能算是 “能力” ，因此我就没有归类在上面，也不算是本文的重点，但这并不是说它们不重要。