英文原文:Writing code on whiteboards is hard
我最近收到一封来自印度读者的邮件,让我就技术面试谈下看法。关于这个话题,本文再现了我在 2004 年写的一篇文章。(注意,这是我在参与到 C# 团队之前写的,因此充满了 C++ 的感觉)
下次在 FAIC,我将就同样话题转载另一篇文章。
我偶尔为我的团队和其它 Visual Studio 团队的开发岗位面试应聘人员。关于微软的面试情况,有太多的人写了太多的文章,因此我不再赘述。我今天想提的是,给面试开发岗位的应聘人员提供一些建议。这肯定不是完整的——我想重点谈谈面试的一个重要方面。
应聘开发人员:如果你看过这方面的资料,你就明白,大部分面试都涉及到在白板上写代码。一句忠告:在白板上写代码是有难度的。多加练习!
难的部分原因在于,你不具备平时写代码所拥有的智能感知、语法着色或其它工具。我理解,我会注意到的。我不介意当你想写 memset (&b, 0x00, cb)
时却写成了memset (&b, cb, 0x00)
——我也不记得这个语法。我不介意你是否忘记了半成品或犯了其它的语法错误。我不是要寻找当即能够写出语法正确的、完美代码的人;这根本不是代码练习的初衷。我在试着弄清楚你是怎样解决问题的。
对我而言,这很容易看出来你是有着良好的问题解决技巧、且善于组织的人,不错。留下足够空间——你或许需要深入某些代码行。一边慢慢写、写清楚,一边解释你在做什么。如果代码干净、组织良好、清晰、模糊最少、语法正确,我们两个就更容易分辨出代码是否设计良好、没有 bug。经过一些简单的测试用例——不要只是扔出某些代码说“搞定,没问题了!”
面试者表现出来的、大多数代码问题不需要任何“Aha!”式的领悟或火箭科学式的算法。没人会要求你实现一个带有 4-5 种不同的龙格-库塔法【注1】方程求解。我们将要求你实现一个哈希表或在带有“bar
”的字符串里替换每一个“foo
”的实例。Eric Carter【我当时的经理和合著者】的办公室有一本《C++编程习题与解答》,因为它是面试问题的宝典。有一场技术面试?挑选一本入门级的编程文本,随机挑选一些问题,在白板上搞定。嘿嘿,我会立即随机浏览一下。下面是从这本书不同地方摘录的一些简单问题:
null
。template
上面随便一条都是高度经典的编程问题。在你对它们说“这个简单!”之前,请在写代码之前想想你从这些问题描述中遗漏了什么:
字符串指针:它指向哪种字符编码?7-bit ASCII chars、UTF-8、UTF-16、或某种 ANSI 编码?你打算要求应聘人员,或者你打算假设你正在为以前就有的某种操作系统编写 C 代码,它不存在包含中文字符的字符串?提示:微软为 PDP-11 机编写了非常少的 C 代码。类似地,程序员从来不必处理非罗马字符集。
小于操作符:你不得不处理了非最简分数的情形了吗,比如 2/4
?不合法的分数,比如 2/0
呢?你能够假设关于数字的大小吗?
你正在打乱数组:你注意到了黑客是否能够预测其次序?我们需要加密长度的随机性,或者可重现的伪随机?这是用于涉及金钱的在线扑克游戏、还是一种算法的测试用例?等等。
如果不把这些问题搞清楚,就无法很好地设计,也就无法愉悦地编写生产环境的高质量代码。
应聘人员经常在关注代码上犯错误,就像代码本身凭空存在一样。这是非常不现实的臆测!代码不但要组织精良和正确,而且还要可维护、可测试、且解决一个真正的客户问题。当你去面试时,在写代码的时候,要考虑:
这不是说,当听到“字符串”就不自觉地想到 char *
的人应该被排除在外。但是,如果你知道 BSTR 的存在,我就更加确信你简历上写的“精通 COM 编程”!还有,我明白,刚走出校门的应聘人员经常在这种“真实世界”的考虑上欠缺经验;我将放宽这部分要求,以关注他们天生的智力、代码天赋和长期潜力。
最后,让我重申,技术面试是很难的,甚至聪明人有时候也会搞错。在我面试全职工作时,两个团队没有雇佣我!不过这是另一个故事了。
译文: 《在白板上写代码是有难度的 》 腊八粥