# 16 雇一名杂耍演员 马戏团经理：你玩杂耍有多少年了啊？ 候选人：嗯，大约六年了。 经理：你能玩三球、四球和五球吗？ 候选人：是的，都可以。 经理：你能玩带火焰的吗？ 候选人：当然。 经理：……刀子、斧子、打开的雪茄盒、伸缩帽子呢？ 候选人：我可以拿任何东西来杂耍。 经理：你杂耍过程中会配上一系列有趣的啪嗒声吗？ 候选人：非常搞笑的。 经理：听起来不错啊，我想你被雇佣啦。 候选人：呓……您不想看看我怎么杂耍的吗？ 经理：呃，我好像从来没想过。 雇一名杂耍演员却不先看看他的表演，可真够滑稽的，这可是生活常识啊。但要是派你去招聘一位工程师、设计师、程序员或者一名团队经理，这样的常识却被抛在了脑后。你不会去看他的设计、程序或者其他东西。面试完全靠说。 你想雇一个人来制造一种产品，这种产品很可能跟他以前做的类似。你当然需要看看候选人以前生产的产品样品。这应该是显而易见的，却往往被开发团队的管理者给忽略了。当你负责职位面试时，似乎有一条约定成俗的边界。这种不成文的规矩认为：可以只跟候选人聊聊过去的工作，但不用看到实物；其实，只要你问了候选人，大部分人都会很高兴地带来一件样品。 ### 作品集 在我们联合参加加拿大西部的一个教学项目时，我们接到当地技术学院一个计算机教授的电话。他提议说哪天晚上下课后来我们的宾馆聊聊，并愿意给我们买杯啤酒来换取些想法。对于这样的邀请，我们很少会拒之门外。那天晚上，我们从他身上学到的东西，可能比他从我们身上学到的还要多。 这位老师非常坦诚地谈到如何评价他的工作是否成功：他需要他的学生毕业后能够找到一份好的工作，而且越多越好。“哈佛的文凭可能本身就具有价值和说服力，但我们的文凭没有。如果今年学生找不到好工作，明年就不会有学生了，那我也就失业了。”所以，他找到了一剂良方，能够让他的学生在就业市场上具有吸引力。他教给他们各种建立系统的技术方法，同时也让学生有机会在附近公司或机构的真实应用中去工作。但是．这剂良方最核心的部分，则是让每个学生自己收集作品集，以展示他们的工作成果。 他讲述了如何指导学生在每次面试过程中展示他们的作品集： 我带来了一些我工作的样例来二像这个是我在一个项目中用 C++编写的子过程，这一组 SAP 脚本则来自于另外一个项目。这部分我们使用了克鲁斯提倡的 loop-with-exit 扩展，除此之外都是完全结构化的代码，贵公司应该也是这样的标准二这里是代码相应的设计，还有根据需求的分层数据流设计图以及相关的数据字典…… 从那以后，我们经常听到这所不知名的学院以及那些作品集。我们甚至见过来自于三角创业园、北卡罗纳州和佛罗里达州坦帕的招聘专员，经常不远千里来到这所遥远的加拿大校园，以求发现毕业生中的千里马。 诚然，这位教授聪明的设计使得毕业生们在就业市场上具备很强的竞争力，但在那晚的谈话过程中，最让我们吃惊的还是他提到：面试官经常都会被这样的作品集震惊。这说明，这些面试官并不要求所有候选人都带着作品集来参加面试：但为什么不呢？有什么比让候选人带着自己的工作案例来面试更合理的呢？ ### 技能测试 如果重视新聘员工所具备的用于工作中的各种技能，那么，我们为何不设计一个测试来度量这些技能呢？我们这个行业和技能测试的想法之间有过很长一段不够稳定的“暖昧”关系。在上世纪 60 年代，这个想法是很流行的：到现在，你和你的组织可能已经放弃这个概念了；如果你没有，我们给你一个应该放弃的理由：这种测试度量了错误的东西。 技能测试一般都会针对被雇用者进入公司后马上会面临的任务来进行。他会被测试是否胜任于职位需要的统计分析、程序设计或其他知识。在几乎所有的技术领域，你都能买到这种技能测试，它们也或多或少能够预测一个新进员工的表现。但这又如何？这位被成功招聘来的员工可能在做这些任务的几年后，变成了团队领导、项目经理或者项目总负责人。测试时所度量的任务他可能只做了两年，之后的 20 年时间，他都在忙其他事情。 我们发现，大部分技能测试都针对左脑。这是因为一名新员工的任务大部分都依赖左脑。但在接下来的职业生涯中，他们做的事情会很大程度上依靠右脑，比如说管理就需要整体思考、启发性判断和机遇经验的直觉判断。所以，技能测试可能造成你招进来的人，短期表现良好却无法获得长期成功。也许你应该尝试着只雇用那些技能测试失败的人。 读到这里，你已经预料到了我们并不鼓励在招聘中采用技能测试。这并不是说技能测试就不好．你就该坚决不用。相反，你应该去用，只是不该用于招聘。通过购买或自己开发的经典技能测试是给员工提供的很好的自我评价工具。一个健康组织所必需的，是能够为员工经常性地提供独立的自我评价机会。（第 37 章中会有更多讨论。） ### 组织一场试演 在我们所在的行业，社会成分比技术成分多，更多是依靠员工和其他人交流的能力而不是他们跟机器交流的能力。所以在招聘过程中，至少需要关注那些社会和人际交流的特征。我们发现，最有效的方法就是为应聘者组织一场试演。 这个想法很简单。你让应聘者按自己过去工作的某个方面准备一个 10 或 15 分钟的演讲，可以是关于一种新技术的第一手体验，或者是从痛苦经历中学到的管理知识，或者是关于一个很有趣的项目。应聘者自己选择话题，然后你定一个日子并且邀请未来可能和他一起工作的人来当听众。 应聘者当然会紧张，甚至可能不接受这样的安排。你应该解释清楚所有应聘者都会在试演时感到紧张，然而，之所以要组织这样的会，就是要考察应聘者的交流技巧，同时，也给未来同事们一个参加招聘过程的机会。 在试演完成、应聘者离开后，你可以组织一次听众讨论。每个人都评价一下应聘者跟工作的契合度，以及是否能够融入团队。虽然决定最后是否招聘仍然是你的职责，但来自未来同事们的反馈是无价的。更为重要的是，这位新招进来的员工可能在未来很容易就能融人到团队中，因为其他团队成员在招聘过程中都表达了自己的意见。 我的第一次试演经历是招聘顾问和讲师。我折磨那些候选人的动机很简单：我想知道他们是否能够自然地解释清楚或易或难的问题，或者能够被教会如何去解释这些问题，抑或根本就不能向别人解释清楚。我同时也希望听到其他人的意见，所以我让当时在办公室的同事们都参加了演讲。在 5 年时间内，我们组织了大约 200 场试演。 很快，试演作为融合新人和老员工的催化剂作用就显现出来了。一次成功的试演就像是一次同行认证；反之似乎也成立，一次失败的试演也能提升已有员工的士气，它不停地告诉大家，你之所以能够被雇用，并不是机缘巧合，凭借好运气，在合适的时间让自己的简历出现在了我的办公桌上。 -TRL 关于试演的一个警告：确保应聘者讲述的是跟你组织从事的工作紧密相关的事情，要不很容易就被一些极左的话题讨论给蒙蔽了，比如讨论“三胞胎的养老计划”或者“软饮料对白萝卜生长的影响”。你一定会被演讲者在这个话题上表达出的强烈热情而吸引，但是，这种热情在未来的工作中却根本见不到。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.shiker.tech/ren-jian/di-san-bu-fen-zheng-que-de-ren/16-gu-yi-ming-za-shua-yan-yuan.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.