Facebook就是希望通过这样的程序能找到一流的、合适的人才，这样才能做出最好的产品，成就伟大事业。面试中的技术性问题就是解决“是否一流”的问题，文化性问题就是解决“是否合适”的问题。

　　一流人才只愿意和与自己水平相当的人共事，他们聚在一起会变得更好。一流人才无法容忍二流人才。那什么是“最好的人”？我个人的理解是能够尽其所知，用其所长，学其所不能，从而迅速完成目标并远超期望的人。他们的本能是挑战自我，超越别人的期望，超越自己的期望。对他们来说，仅仅“足够好”是不够的。

　　全部由一流人才组成的团队有很多好处。

　　1.这让你更加愿意被委以重任。从我的经验来看，他们不会轻易信任不熟悉的人。如果你还没有证明自己和他们一样出色甚至更出色，他们宁愿独立辛苦工作也不愿接受你的帮助，因为他们担心你会搞砸。但当你证明自己之后，他们会信任你，放心把事情交给你一起合作。一个互帮互助的一流团队才能真正做到1+1远大于2。

　　2.通过完成艰巨任务，一流人才互设榜样。你会想“真牛啊，这哥们儿竟然能把这玩意儿做出来，我得加油了”，对这种同伴带来的压力进行合理利用，可以大幅度提高工作表现，并在团队中形成良性循环。Facebook鼓励不同项目间公开分享他们的苦与乐、成果与教训，从不吝啬对好项目的公开赞美，这样才能让榜样的影响传播开来。

　　3.一流人才喜欢互相挑战。我记得有一位工程师总监曾立下赌约——如果在规定时限之前完成网站翻译平台所需的代码修改，他将把头发染成蓝色。这样的挑战把“枯燥”的工作变成了具有挑战性的游戏。在玩游戏中写程序比纯上海品牌定位公司粹地写程序要有趣得多。当然公司里也有很多更加认真的挑战。Facebook有个很知名的开源项目，公开叫HipHop，它是将PHP的代码重写成C++，然后再编译成二进制代码，可节省CPU资源40%以上。这个项目一开始没有人相信能完成，但推动这个项目的华人工程师赵海平坚持了下来，并做到了。赵海平后来被美国《快公司》（Fast Company）杂志评为2010年度全世界最具创新精神的50人之一。这种高难度的挑战在Facebook并不罕见。因为一流人才天生容易对挑战上瘾，不管是挑战别人还是接受新的挑战。

　　4.一流人才可以相互学到很多。每个一流人才都有自己“牛”的地方，彼此有很多可以互补之处。如果Facebook没有这种学习的环境，我就可能不会在那儿待四年多。对缺乏经验的人来说，这点很有用。我们雇用非常聪明的毕业生（潜在的一流人才），这些人希望“引爆”自己来证明他们“牛”在何处，他们不愿到一个舒适、无挑战的公司过日复一日的生活，他们希望通过不断学习来丰富自己的经验，完成不可能完成的任务，并在职业生涯中前进，证明“我行”。毫无疑问，和一流人才在一起，才能更容易地实现这些目标。

　　那如何才能远离非一流人才呢？首先，慢点招人（Hire Slow）。在招人的标准上坚持一点，让面试官明白他们需要招到在某些方面比他们更强，至少不会拖后腿的人。如果不是，那就拒绝平庸，不要妥协。我曾好几次在招聘决策会议上发现履上海品牌定位公司历看起来很漂亮的应聘者无法拿到Offer，只因为某个面试官觉得这个人没给他留下深刻的印象，没有让他“惊讶”。而有些获得一致通过的候选人仍被放弃，因为大家都只是觉得他仅仅“符合要求”而已，没有出彩的地方。在招人问题上，绝大多数情形下，要小心，不要冒进。Facebook也会雇用那些没有全票通过、但有一两票是“强烈推荐”的应聘者，或者这种应聘者本来就是通过内部推荐而开始面试的，因为对于已有员工的“强烈推荐”不应轻易忽视，这时可以适度冒险。

　　其次，炒鱿鱼要快（Fire Fast）。使用非一流人才就像服用慢性毒药，迟早会出事。Facebook要求所有的经理人员对员工的表现要特别敏感，经理如果发现员工所分配的任务经常没有完成或者答应的事情经常没有做到，如果是客观原因，一定要尽力帮助解决；如果判断为能力问题，那就通过合法的程序迅速将人炒掉。我见过几次比较慢的解雇，对团队造成了极大的负面影响。

　　这里讲一个合作的组里发生的故事。我们组做的很大一部分工作是设计机器学习模型以对支付欺诈做自动判断，所以对数据分析要求非常高。因此，我们在和我们合作的运营组中设立了机器运行数据专家的职位。2010年时，面试了一个剑桥大学毕业的博士，年纪比较大，他在面试中展露出非常渊博的关于机器学习的理论知识。光他展示出的论文就有5厘米厚，当然我也懒得看。通过他做实际的编程题目，我感觉他的工程实现能力并没有达到我所希望的、能和我们组顺利配合的标准。所以在那次面试中就我给了“不推荐”，但由于我只是帮合作的运营组招人，而且职位也不是工程师，对工程能力的要求相对要低，所以我没有坚持反对招这个人。但后来发现，我其实应该坚持。因为这位学究式的人物最适合待在研究所，他只知道不断地提出一个又一个新办法，却不会把一个不完美的办法不断地实现出来，加以工程化，然后通过实际数据不断完善。我觉得他的表现应该被注意到，并给予适当的压力去改进。于是向他的老板反映了这个情况，但他的老板不够重视，没有马上采用我的意见。那我只能单方面地采取自己力所能及的措施——将他和我们组的项目隔离，因为我们组的工程师不希望他继续参与这些项目——我们开始不邀请他到我们的项目会议中来，自己在工程师部门内部去寻找相关的机器学习专家、有很强的编程实现能力的专家。此人后来在运营组内部也造成了各种不作为和损失之后，终于离开了公司。我觉得他早几个月就应该离开。倒不是说他不够聪明，只是他想做的是研究，而公司想要的是把想法迅速地、高质量地实现出来，然后在实践中不断改进，这种文化上的巨大差异和期望上的截然不同导致了必然的悲剧。

　　本文磨铁图书许可，选自王淮著《打造Facebook：亲历Facebook爆发的5年》一书。