薨谠谀抢铮乙步怀隽怂枪娑ㄗ质诘奈淖帧�
《Interface》上的文章是“度量开发者的生产力”，它很好地在用于衡量开发者的各种度量，与极度使用度量的弊病之间做出了平衡。这些弊病中最主要的是，度量很容易被当作“游戏”。管理者基本上总会得到他们所要求的东西。如果写更多行的代码能够让度量结果更好，那他们得到的代码行会比较多。如果更少的代码签入能够让度量结果更好，那他们看到的代码签入会比较少。并不是因为代码变好了或者开发者变好了，而只是因为那样做可以使度量的结果更好看。
只要人们相信他们被用数字来判断，他们就会采取任何必要的措施去确保他们的数字很好看，而不会去管那个度量系统的初衷。毕竟，如果抛开你的方式去做正确的事，结果却得不到你的肯定，他们又何必呢？
那是不是所有的度量都没用呢？不是，只要度量用于跟踪团队和产品的进度，以便达到明确而公认的目标（比如绩效、回归率、发现和修复率、解决客户问题所用的天数等），那它们就很有价值。度量有助于推动团队前进，并且赋予成就客观的内涵。然而，它们绝对不可以代替出色的判断。
作者注：我后来对建设性的度量有了更多的认识。你应该用它们度量令人想要的结果——在理想情况下，应该是基于团队的结果。结果关注在“什么”，而不是“如何”，这样就给大家的改进留出了空间。团队度量驱动的是共享的目标，而不是带有竞争性的病态。“代码行数”不大可能是令人想要的结果，而“从开始到结束，使用更少的时间开发出高质量的功能”才是令人想要的结果，而且这个结果取决于整个团队，而不是个人。
不要试图只在个体开发者的生产力上给一个数字，管理者更应该回答这样的问题，“一个优秀的开发者是由什么组成的呢？”如果答案跟指定一个数字那么简单，可能很久以前我们就都被定理证明的机器取代了。
扮演一个角色
度量开发者的价值的关键是，多想一想开发团队，而不是个人。不同的人给团队带来不同的力量。在判定各个开发者的贡献时，要考虑到他们在团队里扮演的角色。最好的开发者往往不是那些代码写得最好或最快的人。
你不希望整个团队都是主管或都是代码工人，也不希望整个团队都是架构师。每个团队都需要有一个才能上的平衡，这样才会有最好的效力和生产力。
卓越开发者的素质
不过，在“度量开发者”方面还有很多的边缘问题。下面，我将列出我认为的、卓越开发者具备的一些明显特征：
？ 他们知道他们正在做什么。当你问卓越开发者，为什么那里有特定的某行代码或某个变量，他们都能说出理由。有时候他们给的理由不那么美妙（“那行代码是我从其他地方抄过来的，它使用了那个结构”），但他们的理由永远不会是，“哈，我不知道，它看起来能够工作。”
？ 他们不相信魔法。这是上一条的必然结果，既然他们知道自己正在做什么。对于黑盒的应用程序编程接口、组件或算法，卓越开发者会感觉不舒服。他们想要知道那些代码是怎样工作的，以免被错误的假设或“有漏洞的”抽象伤害到（比如一个字符串类，它在实现简单的字符串连接时，隐藏了内存分配故障或所需的O（n2）运行时间）。
作者注：赏你一个我最喜欢的“Joel on Software”栏目：“The Law of Leaky Abstractions”。请访问。
译者注：有一种衡量算法复杂度的方法叫大O表示法，它把一个算法的运行时间用输入量n的函数来表示，典型如O（1）、O（log（n））、O（n）、O（n*log（n））、O（n2）等。O（n2）表示某个算法的运行时间随着元素个数的增加呈平方增长，显然其效率比较差。
？ 他们了解客户和业务。我在第7章“职业生涯历险”的“生活是不公平的”栏目中详细讨论了这一点。卓越开发者知道事情的实质，他们能够分出轻重缓急并且做出恰当的权衡。
？ 他们把客户和团队放在优先于自己的位置。卓越开发者不会亵渎任何任务，他们认为没有哪个客户是不重要的。
？ 他们有不妥协的精神和道德规范。尽管个人喜好可能会改变，卓越开发者会一如既往地关注他们如何完成工作，以及怎样去跟其他人互动。不管是他们选择的算法还是他们写的e…mail，他们都会对自己高标准、严要求，始终不会动摇他们的核心价值观。
？ 他们有杰出的人际沟通技能。尽管没有很多的开发者能够主持好游戏或演出，卓越开发者能够很好地跟别人相处，尊重别人，并且跟人进行清晰、有效、恰当的沟通。他们不选择欺凌或胁迫（尽管他们可以那么做），而选择合作。（关于这一点，请同时参考第8章“自我完善”的“要么听我的，要么走人”栏目。）
？ 他们有一个宽广的支持网络。卓越开发者能够认识到别人身上的卓越之处，并且他们相互欣赏。他们能快速发展起一个相互支持的联系网络，使得他们比单一个体要有效力得多。
关于卓越开发者的概括性特征，我还能列出其他更多的方面：关注质量、指导别人、表现出非凡的设计技能等等。
这些形容卓越工程师的特征中，没有哪个是可以被很容易地度量的。
你要做法官
在迫不得已的时候，作为管理者的你必须评判你的团队，你要尽可能地做到公平，并且考虑到他们每一个人所扮演的角色。从其他团队拿些例子过来参考，会有助于你观察你自己团队的开发者；这也是为什么说标度会议如此有价值、有启发性、并且承受它的痛苦也值得的原因了。
但是请记住，没有哪个标度或等级可以代表一个人。人实在是太复杂了，即使是最客观的度量也会被所用的透视法所扭曲。作为高等动物的人类，我们要去了解和尊重，这是完全释放人类潜能的关键！
2004年9月1日：“面试流程之外”
招聘像一个巨大的吸尘器，它把我所有的时间都吸到了校园。但在快速聘用到一位高质量的候选人之后，我就会觉得曾经花费的每一分钟都是值得的。所幸的是，在招聘过程的大部分时间内，我不依赖于任何人。这让大量候选人向我“滚滚涌来”。不过到了面试流程，情况就不一样了。
嘿，如果我能够跳过面试流程的话，我真想那么做！再没有时间安排的麻烦，没有为了一个时间空档而延误几个星期，没有可怕的面试问题，没有失踪的反馈，没有“两可”的聘用，没有含糊杜撰的垃圾标准，没有重复思想的负担，没有最后时刻的放弃。
但是，你不能跳过面试流程——绝对不允许。如果比尔？盖茨想要到我的团队来任职，我也将让他经历面试流程。我不是想冒犯他！只是想让他走过这个流程，确信他是否能够成功地融入到团队中去——如果他得不到聘用，那我也会振奋起精神来。
抱怨得不到帮助
我说过，在面试流程之前我不依赖于任何人。有一些急着招人的管理者对此提出了质疑。他们可能会说，“那我的招聘专员呢？招聘专员没给我留时间。他已经几个月没有给我发送任何简历了。招聘专员是我的瓶颈。”嘿，如果我跟你一起竞争招聘的话，我会非常高兴的。你这个懒惰、脑子不健全的傻瓜，我会悄悄地抢走你所有优秀的候选人。
招聘专员是你的合作伙伴、朋友和资源——不是你的佣人。招聘专员要去补给的职位太多太多了。除非你的副总裁认为你空缺的职位很危急，招聘专员是不可能做下所有你托付过来的工作的。因此，你自己要克服一下，主动到招聘专员的办公室去，然后翻看他们手上所有的简历。要不然，你就等我把我所有的空缺职位都补上之后再说吧。
作者注：如今，所有的简历当然都是在线的了。（那时真的是相当地落后！）不过，有一点还是对的，那就是如果你不去找到你自己的候选人，那你的候选人就会找到其他的工作。
。 想看书来
90％是准备
接下去，我们回到面试流程这个话题上。（关于招聘的总体看法，我打算在未来的某个栏目中再讨论。）有如此多的、想要招人的管理者误解了面试流程。不过，我马上就会为你拨乱反正。一个成功的面试流程其中90％是准备，剩下的取决于你的AA面试官。准备工作分成如下的3步：
？ 帮面试官准备。
？ 帮招聘专员准备。
？ 再次帮面试官准备。
任何有资格去面试别人的人，都应该预先做如下的准备：
？ 参加面试官培训。
？ 精心设计面试问题。
如果不参加面试培训，初级人员就无法学会适当的面试方法，而高级人员也意识不到他们已经养成的坏习惯。如果没有精心设计的面试问题，你也可能把Jason Voorhees招聘进来。
译者注：Jason Voorhees是美国“鬼魔消遣小说”创作出来的一个惊悚杀人的虚构鬼物。1980年的《13号星期五》是它成功问世的电影。Jason Voorhees衣衫褴褛，智商低下，它的身躯很笨重，从不说话，不善奔跑却总能追到它想害的人。
。 想看书来
那就是问题
哈，面试问题！怎样才算是一个好的面试问题呢？根据我多年的面试经验，我得出了一个结论，那就是只有下面两种类型的面试问题才是有价值的：
？ 能够暴露应聘者性格特征的问题。
？ 能够展示应聘者将如何开展工作的问题。
脑筋急转弯是没有意义的，关于个人背景的问题也很无聊，只是问“你将如何做这个工作”这样的问题更是没有大脑。这些类型的问题很少会直接暴露应聘者的性格特征，或者真实地展示他们的绩效。也就是说，除非你对这些问题追问，“为什么？”，否则你将达不到目的。不是一次或两次，而是要重复地问“为什么”，直到你了解到应聘者关键的性格特征或绩效水平。
更好的做法是，从一开始就问“为什么”这样的问题。比如说，“为什么你想要得到这份工作？为什么你要抛弃以前的那份工作？为什么你仍然在微软工作？为什么你想要为微软工作？”再说一遍，如果你在得到第一次回答之后停止了问“为什么”，那么这些问题可能仍然收效甚微。
你要寻找的人，是要和我们的关键资质要求看齐的，尤其是激情、坚持到底、适应能力、正直和职业精神。任何人都可以把这些特征表现出来的。坚持问“为什么”，设法拨开表面的东西，找到真实的证据。
电子书 分享网站
白板编译器
除了带“为什么”的问题之外，还有编程问题（或者其他类似的关于解决技术难题的问题），也能揭示应聘者将如何开展工作。这些可以成为强有效的面试问题。问题是，哪里去找到这些合适的问题。
不用费神去找网上宣扬的、被人过度使用的、无数的糟糕样例。接下去，我会一步一步教你如何得到属于你自己的全新的好问题：
1。 选择2~3个在过去18个月内你或你的团队碰到过的真实问题。它们的解决方案应该只用一块白板就能写出来，并且至少要引用3个不同的变量。这确保你选择的问题具有挑战性，并且解决方案也要求简短而非凡。通常来说，他们是一些小的函数，某个设计问题的片断，或一些特别的测试案例。
2。 把每个难题分解成一个简单的核心问题，并把它用作第一个问题。当应聘者建立起信心，就增加更多的复杂性以提高难度。比如说，让应聘者找出更好的解决方案，引入新的情况，或者要求给出一个更加健壮的“产品级质量”的解决方案。
3。 指出他们在分析的过程中略过的地方，追着应聘者一定要给出答案，这样可以看出他们对安全地带之外的问题做出怎样的回应。
4。 准备好多种问题解决方案，并且指出你真实的难题中真正的问题所在。
2~3年前的问题就不要再用了。你总是会碰到新问题，因此可以依次把最老的问题扔掉。这使得面试对你来说更加有趣味，对应聘者来说也更加贴切。这还使得应聘者从互联网上获取答案要困难了许多。
作者注：人们非常倾向于保留老问题，因为那样比较容易，而且他们已经了解了怎样去评估应聘者的解决方案。把这个习惯克服掉吧！最近的问题会更好。
这里的目的是，去了解每一位应聘者如何一步一步地解决问题，而不是必须得到正确的解决方案。他们跟你在一起的短短几分钟内未必能找到任何解决方案，哪怕他们是非常优秀的应聘者，而其中的原因是多方面的。你要看的是，他们在解决问题的时候是如何表现出他们的核心能力的，比如：
？ 他们是否在一个策略行不通时把它标出来？
？ 他们是否问你问题，以帮助他们正确理解问题？他们是否听从你的暗示？
？ 他们分析了他们的过程和结果吗？
？ 他们是否应用了多个策略？
当应聘者专注在白板上的时候，你也要聚精会神地跟他在一起。你要的不是答案；你要知道的是他如何得到答案的过程。
我说的这些很多都可以从“面试官工具包”中找到——那是人力资源部门在许多开发经理（包括我）的帮助下收集起来的一个巨大的资源。你也可以跟你的朋友和开发团队就一些问题进行分享和评论，但小心不要重复他们的问题，否则解决方案很快就会在网上发布出来了。
作者注：如今我常常需要在不借助白板的情况下评估应聘者的能力，因此我使用了角色扮演。其基本依据很简单：如果你想评估某个人代码写得怎么样，那就让他写代码；如果想要评估某个人对他所做决定的信心怎么样，那就对他们的决定提出质疑。
在线资料：一篇指导你如何进行面试角色扮演的文章（）。
帮招聘专员准备
在你的面试官为应聘者准备了一些备用问题之后，你还�