白板编程浅谈——Why, What, How.docx

目录前言3技术面试中的常见问题4为什么要进行白板编程5什么是合适的白板编程题目6什么不该问6应该问什么问题6如何进行白板编程7面试官应该做什么7面试者应该做什么7参考8前言作者：Lucida微博：@peng_gong豆瓣：@figure9原文链接：http://lucida.me/blog/whiteboard-coding-demystified/这篇文章节选自我正在撰写的一本关于应届生面试求职的书籍，欢迎在评论或微博（@peng_gong）上留言反馈。面试很困难，技术面试更加困难——只用 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 倍，因为前者不需要浪费大量时间在?编码-调试-编码?这个极其耗时的循环上。通过白板编程，面试官可以有效的判定出面试者属于前者还是后者，从而招进合适的人才，并把老油条或是嘴遁者排除在外。除了判定面试者的开发效率，白板编程还有助于展示面试者的编程思路，并