那是常识，然而当你着手雇用一个工程师，设计员，程序员，一个小组的经理时，常识准则经常被搁在一边。你没有要求看一个设计或一个程序或任何东西。事实上，面试只是谈话而已。

  你正在雇用一个人生产一种产品，大概与他或她以前生产的那些产品相类似。你需要检查那些产品中的一个样品，看看候选人的工作质量，那是显而易见的事情，但是这经常被研发经理忽略掉。当你符合一个工作的面试要求时，那是表面上看起来符合工作要求。似乎有一条不成文的规矩，也就是说可以问候选人以前干过的工作，但是不能要求看看工作产品。然而如果你要求的话，候选人总是会乐意提供一个样品。

文件夹

“我带来了一些工作样品。例如，这是一个项目中用 Pascal 语言编写的子系
统，和另一个项目的一套 COBOL 的程序片段。正如你们在这个文件夹里所看到的，
我们用了 Knuth 提倡的 loop-with-exit 扩展，除此之外，它还是纯结构化的代码，
就是你们公司标准需要的那种东西。还有这是那个代码的设计。层次和耦合分析用
的是 Myer 的概念。我设计了整个子系统，在这个小部分里我们用了一些 Orr 方法，
因为在程序结构上要用到数据结构本身。这些是有我们特色的分层的数据流图，相
关的数据字典……”

  当然，这是教授的一个聪明计划，给他的学生增加点吸引力，但是那天晚上给我们印象最深的是，听说面试官总是对那些文件夹感到惊奇。这就是说他们不是规定要求所有的候选人带着文件夹来面试。然而为什么不呢？难道还有什么比要求每一个候选人带一些工作样品来面试更直观的吗？

能力倾向测试

  能力倾向测试几乎总是面向雇员被雇用后立即要做的任务。它们测试他或她擅长统计分析还是编程、还是岗位需要的任何工作。实际上你可以采纳任何科技领域的能力倾向测试，在预测雇员如何很好地执行任务方面，它们都倾向于有十分可观的跟踪记录。但是，即便如此又怎样？一个成功的新雇员做那些任务，做了几年，然后可能会成为团队领导或项目经理或是一个项目头目。那个人可能在结束两年测试所涉及的任务后，花二十年做其它事情。

  读了这本书后，你不会期望作者认同通过能力倾向测试雇用人的观点。但是作者也不认为能力倾向测试不好或者你不应该采用。你应该采用能力倾向测试，但是不仅仅是为了雇用。你采纳或建立的典型能力倾向测试对于你的人而言，可以是美妙的自我评估工具。对于在一个健康的公司工作的员工而言，必须经常让个人有机会进行有趣的自我评估。

举行一次工作试讲

  你要求一个候选人准备一个十至 15 分钟，跟过去工作有关的某个方面的陈述。它可以是一个有关项目新技术和第一次尝试的经验或者是一个有关通过艰苦的方法得来的管理教训或者是一个关于特别有趣的项目。候选人选择主题。规定好日期，召集将是新雇员同事的那些人，组成一支小听众队伍。

  当然这个候选人会紧张，或许甚至会不愿意经受一次这样的经历。你必须向他解释所有的候选人都会对试讲感到紧张，并且说明你支持举办试讲的理由：看看不同的候选人的沟通技巧，并在雇用过程中给未来的同事一个角色。

  试讲结束，候选人走了以后，举行一个任务报告会，每个与会者都要对那个候选人适应工作的能力和他或她是否能够很好地适应团队发表意见。虽然最后是你决定是否雇用那个候选人，但是从未来的同事反馈来的信息肯定是无价的。甚至更重要的是，任何新雇员更能够轻易地吸纳进小组，因为小组的其他所有组员都在选择这个候选人的问题上发了言。

  一个有关试讲的告诫：要确保候选人所谈及的东西与你公司所做的工作有密切的关系。因为它容易受到一个有关左派主题的谈话阻挠，例如“关心患孤独症的孩子”或“酸雨的后果”。如果是这样，你很容易瞥见候选人说话时有一种非常引人注目的激情，但这种激情再也不会在工作中出现。