[白板编程浅谈.docxVIP

白板编程浅谈——Why, What, How面试很困难，技术面试更加困难——只用 45 ~ 60 分钟是很难考察出面试者的水平的。所以刘未鹏在他的怎样花两年时间去面试一个人一文中鼓励面试者创建GitHub账号，阅读技术书籍，建立技术影响力，从而提供给面试官真实，明确，可度量的经历。这种方法对面试者效果很好，但对面试官效果就很一般——面试官要面对大量的面试者，这些面试者之中可能只有很少人拥有技术博客，但这并不代表他们的技术能力不够强（也许他们对写作不感兴趣）；另一方面，一些人拥有技术博客，但这也不能说明他们的水平就一定会很牛（也许他们在嘴遁呢）。总之，技术博客和GitHub账号是加分项，但技术面试仍然必不可少。所以，问题又回来了，如何进行高效的技术面试？或者说，如何在 45 ~ 60 分钟内尽可能准确的考察出面试者的技术水平？回答这个问题之前，让我们先看下技术面试中的常见问题都有什么：技术面试中的常见问题技术面试中的问题大致可以分为 5 类：编码：考察面试者的编码能力，一般要求面试者在 20 ~ 30 分钟之内编写一段需求明确的小程序（例：编写一个函数划分一个整形数组，把负数放在左边，零放在中间，正数放在右边）；设计：考察面试者的设计/表达能力，一般要求面试者在 30 分钟左右内给出一个系统的大致设计（例：设计一个类似微博的系统）项目：考察面试者的设计/表达能力以及其简历的真实度（例：描述你做过的 xxx 系统中的难点，以及你是如何克服这些难点）脑筋急转弯：考察面试者的『反应/智力』（例：如果你变成蚂蚁大小然后被扔进一个搅拌机里，你将如何脱身？）查漏：考察面试者对某种技术的熟练度（例：Java 的基本类型有几种？）这 5 类问题中，脑筋急转弯在外企中早已绝迹（因为它无法判定面试者的真实能力），查漏类问题因为实际价值不大（毕竟我们可以用 Google）在外企中出现率也越来越低，剩下的 3 类问题里，项目类和设计类问题要求面试官拥有同类项目经验，只有编码类问题不需要任何前提，所以，几乎所有的技术面试中都包含编码类问题。然而，最令面试者头痛的也是这些编码类问题——因为几乎所有的当面（On-site）技术面试均要求面试者在白板上写出代码，而不是在面试者熟悉的 IDE 或是编辑器中写出。在我的面试经历里，不止一个被面试者向我抱怨：『如果能在计算机上编程，我早就把它搞定了！』就连我自己在面试初期也曾怀疑白板代码的有效性：『为什么不让面试者在计算机上写代码呢？』然而在经历了若干轮被面试与面试之后，我惊奇的发现白板编程竟然是一种相当有效的技术考察方式。这也是我写这篇文章的原因——我希望通过这篇文章来阐述为什么要进行白板编程（WHY），什么是合适的白板编程题目（WHAT），以及如何进行白板编程（HOW），从而既帮助面试者更好的准备面试，也帮助面试官更好的进行面试。为什么要进行白板编程很多面试者希望能够在 IDE 中（而不是白板上）编写代码，因为：主流 IDE 均带有智能提示，从而大大提升了编码速度IDE 可以保证程序能够编译通过可以通过 IDE 运行/调试代码，找到程序的 Bug我承认第 1 点，白板编程要比 IDE 编程慢很多，但这并不能做为否认白板编程的理由——因为白板编程往往是 API 无关（因此并不需要你去背诵 API）的一小段（一般不超过 30 行）代码，而且面试官也会允许面试者进行适当的缩写（比如把Iterable类型缩写为Iter），因此它并不能成为否认白板编程的理由。至于第 2 点和第 3 点，它们更不能成为否认白板编程的借口——如果你使用 IDE 只是为了在其帮助下写出能过编译的代码，或是为了调试改 Bug，那么我不认为你是一名合格的程序员——我认为程序员可以被分为两种：先确认前条件/不变式/终止条件/边界条件，然后写出正确的代码先编写代码，然后通过各种用例/测试/调试对程序进行调整，最后得到似乎正确的代码我个人保守估计前者开发效率至少是后者的 10 倍，因为前者不需要浪费大量时间在编码-调试-编码这个极其耗时的循环上。通过白板编程，面试官可以有效的判定出面试者属于前者还是后者，从而招进合适的人才，并把老油条或是嘴遁者排除在外。除了判定面试者的开发效率，白板编程还有助于展示面试者的编程思路，并便于面试者和面试官进行交流：白板编程的目标并不是要求面试者一下子写出完美无缺的代码，而是：让面试者在解题的过程中将他/他的思维过程和编码习惯展现在面试官面前，以便面试官判定面试者是否具备清晰的逻辑思维和良好的编程素养如果面试者陷入困境或是陷阱，面试官也可以为其提供适当的辅助，以免面试陷入无人发言的尴尬境地什么是合适的白板编程题目正如前文所述，白板编程是一种很有效的技术面试方式，但这是建立在有效的编程题目的基础之上：如果编程题目过难，那么面试