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

文章插图
作者介绍
熊燚，笔名四火，现于西雅图 Oracle 任首席软件工程师一职，负责研发云基础设施的分布式工作流引擎。曾先后任职于华为、亚马逊，做过多种类型的研发工作，从大小网站到高可用服务，从数据平台到可视化系统，他带领团队攻克过数个项目难关，在全栈之路上具有丰富的实战经验。
其实很久以前就想谈一谈这个话题了，但是最近才有了足够的动机。因为从最近参加的很多 debrief 来看，我认为身边大多数的软件工程师面试中，在通过技术问题来考察候选人这方面，很多都做得不够好。
比方说，我看到一些对经验丰富的软件工程师候选人的面试，不少面试官依然是草率地扔出一道算法题让做了事，并且将能不能够比较清晰完整地把代码写出来作为裁定工程师级别的最重要的标准。这样的做法我认为是非常不妥的。
首先我要明确的是，这个“问题”指的是技术面试中俗称的 “主要问题” 。具体来说，就是面试官会拿出一个问题和候选人讨论，并通过双方的互相沟通和问题发散来达到考察的目的。因此，这个 “问题”从某种角度来说，更像是一个 “话题” 。这个过程每轮面试中通常会持续几十分钟，接下来的内容，都是建立在这种面试风格和方式之上的。
其次，作为一个 disclaimer ，我想说，以下内容来自于我的认识，并且是针对于技术面试这一个狭窄范围内的认识，所以自然带有主观的倾向性和认知的局限性，它并不来自任何公司或组织的标准。
下面我就来尝试把这个问题讲清楚、讲透彻。我认为这并不是一件容易的事情，如果你对其有不同的看法，欢迎和我一起讨论。
一、典型案例
我先来举这样一个典型的例子，这里面包含了若干个值得商榷的方面，你可以看看是不是似曾相识：
在和候选人谈论完项目和经历以后，面试还有 40 分钟，于是面试官问：你能否实现一个 LRU 队列？
于是候选人想了一下，就开始做题了，也就是在白板上大写特写，于是面试官也就开始忙自己的事儿了。等到 40 分钟后，候选人写了一白板，但是显然，他在这过程中遇到了一些困难，最后虽然实现了，但是代码写得有些复杂，也遗漏了两、三个重要的 corner case 。
于是面试之后，面试官在评语中写道， “候选人能力一般，算法题实现起来磕磕绊绊，最后的代码偏臃肿，而且有明显的 bug” 。
在往下阅读以前，请你想一想，这样的面试形式有哪些值得商榷的地方？
二、技术面试的目的
好，我先卖个关子，先不回答上面的问题。而是先谈一谈，对于软件工程师候选人来说，我们为什么要进行这样的技术面试？
事实上，很多考察项完全不需要技术面试这样麻烦的途径，就可以很容易、高效地实现；而下面我说的这些方面，都是对于软件工程师来说至关重要的方面，而技术面试是合理考察的唯一可行途径。
1、技术能力方面
通常不同轮次的面试会考察不同的技术点，因为这对于不同的团队和职位，都是不一样的。
举例，对于某业务平台团队的一个高级工程师这个职位来说，五轮面试中：一轮考察项目和经验；一轮考察系统设计；两轮考察解决具体问题的思路和方法，特别包括算法和数据结构；还有一轮考察面向对象设计等其它内容，这其中，后三轮都包括白板编码的考察。
对于一个有经验的工程师候选人来说，我认为这是一个比较立体、综合，也是一种比较合理的技术考察点的划分方式。
这五轮中有四轮都会花费大量的时间，同时通过我今天谈到的技术问题，来对候选人进行技术能力方面的评估。这里，有这样几个非常常见的技术方面的考察项：

分析问题，整理需求的能力：一开始问题可能显得很模糊，但是优秀的且有经验的工程师可以识别出核心的诉求。这个 “识别” 的能力，下文我还会详述。这里的诉求可能有多个，但是考虑到时间的关系，面试过程中往往只会从某个角度覆盖其中的一两个；
根据需求来设计系统的能力：这里既包括功能性需求，又包括非功能性需求，前者是必须要涉及到的，但是后者也经常放在一起考量。其实这一点可大可小，它未必指系统设计中功能是否得到实现，并且这个过程中，可能会涉及到系统的扩展性、可用性、一致性等等其它方面；
- 上一页
- 1
- 2
- 3
- 4
- 5
- 6
- 下一页