我最近收到一封来自印度读者的邮件，让我就技术面试谈下看法。关于这个话题，本文再现了我在 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 呢？你能够假设关于数字的大小吗？
你正在打乱数组：你注意到了黑客是否能够预测其次序？我们需要加密长度的随机性，或者可重现的伪随机？这是用于涉及金钱的在线扑克游戏、还是一种算法的测试用例？等等。
如果不把这些问题搞清楚，就无法很好地设计，也就无法愉悦地编写生产环境的高质量代码。
应聘人员经常在关注代码上犯错误，就像代码本身凭空存在一样。这是非常不现实的臆测！代码不但要组织精良和正确，而且还要可维护、可测试、且解决一个真正的客户问题。当你去面试时，在写代码的时候，要考虑：
测试人员将怎样攻击它？这份设计是可测试的吗？
对于友好的/糟糕的调用器将来抛出的东东，能做处理吗？空指针、大分母、大数组？
和其它技术能协同工作吗？它使用了 COM 或 ALT 的规范了吗、或与之相斥？
它是正确的、健壮的、可维护的、可调试的、可移植的、可扩展的？
你是怎么知道，这是客户想不想要的代码？