在白板上写代码是有难度的

我最近收到一封来自印度读者的邮件,让我就技术面试谈下看法。关于这个话题,本文再现了我在 2004 年

我最近收到一封来自印度读者的邮件,让我就技术面试谈下看法。关于这个话题,本文再现了我在 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 的规范了吗、或与之相斥?

它是正确的、健壮的、可维护的、可调试的、可移植的、可扩展的?

你是怎么知道,这是客户想不想要的代码?

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/fc4b60fabbcae1180bdf22c2382e43d1.html