作者：王淮、祝文让
出版社：印刷工业出版社
版本：2013年2月第1版 2013年3月第2次印刷
来源：下载的mobi版本
书写的比较随意，出版社做的也比较随意，作者最后还夹了很多的私货，读过之后如鲠在喉，本来是非常好的题材，内容也有很多的可出彩部分，但是却并不能被称为一本好书
非常有意思的招聘形式，把招聘环境打造成了一个内部小市场：
除非有特殊情况，一般某个新员工选定的组都会接收他，不能拒绝。因为如果你拒绝的理由是“他不行”的话，那不如解雇他；如果说你不愿意让他到你的组但可以到其他组，这种想法违背Facebook的文化。我在前面就强调过这一点，“我们都是为Facebook工作的，而不是为了某个小组工作”，所以如果你觉得某个新员工不行，那其他组也不应该要他。如果原因是“他的背景不适合”，那一开始就不应该见面会谈。导师极力避免把新人介绍到明显不适合的组里面，所以这个理由也不成立。
摘录：
扎克伯格最喜欢三句话。1．维吉尔：“天佑勇者。”2．毕加索：“每一个孩子都是天生的艺术家，问题是长大后如何保持童心。”3．爱因斯坦：“凡事都应简化到不能再简化。”
据我所知，进入Facebook绝非易事。Facebook在人才济济的硅谷坚持非常苛刻的面试标准，他们“只和最好的人合作”的招人策略被执行得非常彻底，更何况是在早期的时候。
我记得我第一次把Facebook弄得无法访问，并持续了半个小时左右时的情景。在修复完仍惴惴不安的时候，我记得一位公司前20号的资深工程师对我说“Harry（我的英文名），you cannot claim you are a Facebook engineer if you have never brought the site down!（如果你从来都没有让整个网站崩溃的话，你就不能说自己真正是Facebook的工程师！）”
Facebook的逻辑很简单：在你正式获得一个新的职位之前，你必须已经在这个职位上成功地运作了6个月。这个组里的每一个人都是我自己从新兵营或者其他组挖过来的，我很怀念这当中的艰辛。
其实，从一个Facebook员工的角度来看，扎克伯格并不像老板，而是个“天才”的年轻人，并且是有点内向、会害羞的年轻人。是的，大家都很尊重他，但并不仅仅因为他是CEO（首席执行官），更重要的是他在产品、技术方面的敏感和洞察力。他毫无疑问是为这家公司指引方向的人，而且被大家所信服。
扎克伯格是个容易害羞的人，尤其是面对陌生人时。在三四年前，你可以很容易发现他在公开讲话时会有些紧张，身体会轻微颤抖。经过这几年的磨炼后，他这方面的表现已经很好了，比如他在2011年的F8开发大会上的演讲，就很精彩，非常老道。这是一个仍在不断学习、不断进步的年轻人。
公司有明确的规定，就是包括这些数据在内的相关情况，不要对外人讲，扎克伯格曾这么说，“员工只有做到对外守口如瓶，我们才能做到对内知无不言”。Facebook曾发生过几次内部秘密泄露出去的事件，公司的态度非常坚决，不管是谁，不管对公司做过什么贡献，一旦发现就马上解雇，这是一条铁律。
扎克伯格每年都会给自己制订一项“挑战”，为了学习中文，他每周在公司里搞一次小规模的中文讨论会。
他的学习能力非常强，每年都会给自己制订一项“挑战”。就像2010年要学中文一样，他2009年的挑战是每天坚持打领带（呃，大多数人都知道他平时是一副什么装扮），2011年的挑战是只吃自己亲手屠宰的动物（所以，他几乎成了素食主义者），而2012年的挑战是坚持每天写代码，因为他希望能与员工变得更亲近，以及从细节处了解Facebook。
在工作场合里接触扎克伯格，基本都是在开产品研讨（Product Review）会议的时候。不同的产品，进行研讨的频率也不一样：比较核心的产品可能每周1～2次，整个公司可能也就五六个这样的项目，其他产品可能1～2个月一次。我早期开发社交广告、礼物商店、虚拟货币等产品时，跟他一起做过几次产品评价，主要是工程师讲思路、想法，扎克伯格很仔细地听，有时会提很多问题，有时则很少。对于特别关心的问题，他会非常坚持自己的意见。我记得扎克伯格在一封邮件中曾经对开发平台的一个页面设计提出了非常细节的建议，细到甚至其中一个按钮离边界的距离应该减少几个像素。
对于自己比较坚持的方面，他会明确地提出意见。比如做虚拟货币涉及支付的时候，他希望越简单越好，不要让虚拟货币的存在妨碍到用户的支付流程，增加操作步骤。当时做虚拟货币的出发点，是希望用户都能用这种方式支付，不再依赖外部各种支付工具，但扎克伯格担心多了一个虚拟货币的概念，就必然会多出一个操作步骤，他强调一定要处理好用户体验（最近的消息显示，Facebook越过了虚拟货币环节，又开始采用直接用当地货币进行支付的方式）。对于有些产品的细节，他也非常关注，比如他常用的公司核心产品——“相册”，他对其中的每一个环节都会提出建议，像某个操作按钮的设计，可能只是几个像素的差别，如果他感觉不舒服，都要提出来讨论，非常在意用户体验。
当然，随着公司规模的扩大，扎克伯格不可能关注每一个环节，他的主要精力还是放在重大产品的发展方向上。比如前面提到的，“Facebook是否要成为一个对外开放的开发平台”这个项目，那他一定要在公司充分讨论的基础上做出最后的决定，然后朝着这个方向全力推进。相反，比如我后期主要做的支付安全、防欺诈的开发，就不会跟他进行产品研讨，一个原因是他确实不懂这些，另外一个原因是支付安全这些都是基础性、系统性、工具性的工作，不是独立存在的产品。
毫无疑问，Facebook的成功很大程度上归功于扎克伯格的强势和正确领导，但也绝不是他一个人的功劳。Facebook在硅谷吸引了很多最优秀的人才加入，这些人在不停地影响公司的做事方式，同时也在不停地被影响着，最终成就了这家独特的公司。
当时雅虎已经不是它最好的时候了（股价从2006年初40美元以上回落到2007年初的30美元左右，但主要是其文化氛围出了问题——无挑战、无效工作太多、踢皮球太多、CEO没有技术产品背景等原因），但在那时工作还不错，不像现在已经江河日下了（最近，Google的梅耶尔出任雅虎新CEO，希望能扭转公司颓势），大家都会觉得离开那里很自然。
雅虎当时已经有十多年历史，创始人也不再主导公司的发展，感觉就是一个成熟的大公司。两位创始人，一个作为公司的形象代表到处跑（杨致远），一个关注公司里大的技术问题和框架（大卫·费罗）。但他们并不像Google的两位创始人那样对公司的发展方向深具影响力。在塞梅尔（Terry Semel）担任CEO之后，雅虎就再也不是一家产品技术驱动的公司，而是定位于媒体公司。我发现雅虎所谓的“公司政治”问题比较严重，没有那种很强烈的“所有人做事情都是为了雅虎”的理念，他们内部是以BU（业务单元）这种方式运作的，小组与小组之间存在隔膜，都主要考虑自身那一小块的利益，相互之间的配合支持度较差。好多产品组称自己为Studio（创作室），这是一种在媒体公司盛行的做法。创作室运营的典型特点是财务独立、运作独立。虽然雅虎没有做得那么彻底，但这种特点还是多少被继承下来。我感觉日子过得有点混沌。后来到了Facebook，感觉完全不一样，绝大多数人都很清楚，“我们并不是为某个小组工作的，我们的目标是整个Facebook的发展”。而这种理念，让Facebook内部的协同作战、互帮互助成了家常便饭，让组与组之间的合作或妥协不再那么困难。
有一次，我们组的工作需要找另外一个组的工程师，他答应在他们的服务中帮我做一个API（应用程序接口），但我多次催促也没有结果。那个工程师说自己也没办法，因为他被自己的老板逼着做其他事情，这个API不在他们组计划的优先级之中。在我与这个工程师多次沟通的过程中，他的老板找我的老板说了一次，意思就是应该通过我的老板来发送这个请求，然后由他来分配那边工程师的时间。他认为自己的“管理权”受到了“冒犯”。
在这种大公司里面，一个组不关心其他组的需求，这让我非常惊讶，感觉也很不舒服。我觉得雅虎已经丧失了创业文化，变成了一个官僚型机构。我在雅虎具体要做什么工作，都是由老板和产品经理决定的，这种任务的产生和分配，我的参与非常有限。工程师更多的是被分配做某个任务，没有太多的主动性在里面。
这些做法在Facebook是不可想象的。如果需要跨组协作的话，Facebook会尽可能地让两边直接对接的工程师来沟通，做不做、什么时候做、做到什么程度，让他们自己来定，除非涉及的工作量很大，大到会影响到整个组的进度，基本都是把这些工作的计划权和决定权往下“推”，而不是往上“揽”。
再举一个例子。比如在雅虎要做一个产品，有十项功能的产品，那产品经理会列出一个表来，让工程师看可不可以做，每个功能又需要多少天完成，还要签字确认，就等于你承诺了多久要做完，并变成了工程师的“责任”，感觉很像是被迫签了一份卖身契。其实，每个产品当然要估算一个完成的时间，但是这种做法对工程师的负面影响就在于，更多关注在“时间”上，而不是要把工作“做好”，只是把工程师当作工具。
其实，包括像产品开发流程、工作表现评估等，雅虎有自己的一套做法，只不过与Facebook完全不一样。我最终加入Facebook，就是想寻找另外一种视角，在两者之间可以做一个对比，对这些内容有更全面的认识，将来自己创业时就知道应该选择哪种方式更有效。
目前Facebook招聘工程师时都安排四位面试官，每人45分钟时间，其中有2.5人会集中考察编程的情况，也就是技术性问题，0.5人考察文化适应性问题，1个人专注于系统设计方面。
先谈谈文化适应性问题。关注应聘者的性格特点是不是能和Facebook的文化兼容。不求完全共鸣，但不能存在极大差异。这些讨论，基本上基于对应聘者以往项目的讨论。下面是我主导的文化适应性面试的典型过程。
1分钟：我大致描述下本次面试。
4分钟：我先花1分钟介绍自己，什么时候加入Facebook，做过哪些东西，目前在Facebook哪个部门，负责什么。然后给应聘者3分钟进行自我介绍。
3～5分钟：让他回答“为什么对Facebook感兴趣”的问题。我们最不想听到的就是强调潜在的财务回报，虽然大家都知道这肯定是一个因素。但在如此宝贵的时间里去强调这一点，而不是其他更有意思的方面，会让面试人员产生反感。如果Facebook的财务表现在短期内不符合他们的想象，这些人会很快走掉。
10～15分钟：让应聘者谈谈之前最让他感觉骄傲的一个项目。然后我会深入追问很多跟这个项目相关的问题。比如“这个项目最大的挑战是什么”“几个人完成的，你在里面的角色和贡献”“有没有出现你的想法和其他人不同的情况，你是如何应对的”“这个项目让你学习了什么东西，或者锻炼了哪些地方”，我们还会挑一些相关的技术细节提问，等等。
20分钟：文化相关性问题只占一半时间。所以这里我们还是会集中在一个具体的技术问题上。
5分钟：留给应聘者来提问，针对Facebook或者针对我在Facebook所做的事情。我们希望应聘者较为关心的是公司文化、产品或技术，而非财务上的。
说到文化性问题，可能有人会有疑问，认为这样招聘来的都是一种风格的人，会不会限制了公司内部文化的多元化，反而不利于创新？其实，Facebook追求的只是在核心价值上想法一致，如果这方面有冲突，这样的人招过来可能会麻烦不断。Facebook的核心价值，比如把事情完成比完美更重要，这是最关键的，又比如，要做整体上对公司最有影响的事情，而不是做那些可有可无的事情；愿意进行团队合作，而不是习惯于单枪匹马；不要永远只会听你老板的话，要做一些你自己的决定和判断……至于说你喜欢用某种调试工具，他喜欢某种程序编辑器，这都不会造成什么影响，完全依据你个人的喜好。
设计方面的问题主要是让应聘者针对某个大系统提出自己的设计方案。比如要让你来做Facebook的“动态消息”（News Feed），你会怎么实现，需要哪些部件（Components），数据如何传输，你的设计会有什么优点和缺点，等等。我会希望应聘者先谈论这个系统可以提供的一些性能要求或特点（Specification），因为这些要求会决定设计上的不同。比如动态消息系统是设计成方便读还是方便写，这会让实现方式大不同。每个人都有不同的方式，这没有问题，但这中间的交流可以体现出一些设计思想的深度，这才是面试的目的。系统设计能力考察的权重对于不同职位也不相同，比如后台的要多一些，前台的就少一些；刚从学校出来的要轻一些，有多年经验的要重一些。而Facebook的面试会回避类似脑筋急转弯那种所谓智力型题目，因为那根本体现不出什么智商，重点都放在具体的编程问题上。
还有一点，是对应聘者学习新东西的意愿和能力的判断，这个要求非常高。比如我们希望他知道一些新的技术，即使他不知道，但是在聊的过程中，也能从表情和反应中看出他是否有兴趣去学习。
面试结束后，面试官都会给应聘者打分，依强弱程度分别为：Strong Hire（强烈推荐），Hire（推荐），Weak Hire（一般推荐），Weak No Hire（一般不推荐），No Hire（不推荐），Strong No Hire（强烈不推荐），还会写出具体的评价以及理由（比如，我问了什么问题，应聘者如何回答）。一般要求面试人员在面试的当天提供反馈。这样Facebook可以在尽可能短的时间内完成对应聘者的评估以便给他们一个面试结果。这可以显示出对应聘者的尊重，也同时希望这种高效率能够给应聘者留下好的印象，如果给Offer的话，更能说服应聘者接受。在Facebook，招人是当作第一优先级的工作来对待的。
Facebook就是希望通过这样的程序能找到一流的、合适的人才，这样才能做出最好的产品，成就伟大事业。面试中的技术性问题就是解决“是否一流”的问题，文化性问题就是解决“是否合适”的问题。
一流人才只愿意和与自己水平相当的人共事，他们聚在一起会变得更好。一流人才无法容忍二流人才。那什么是“最好的人”？我个人的理解是能够尽其所知，用其所长，学其所不能，从而迅速完成目标并远超期望的人。他们的本能是挑战自我，超越别人的期望，超越自己的期望。对他们来说，仅仅“足够好”是不够的。
全部由一流人才组成的团队有很多好处。
1．这让你更加愿意被委以重任。从我的经验来看，他们不会轻易信任不熟悉的人。如果你还没有证明自己和他们一样出色甚至更出色，他们宁愿独立辛苦工作也不愿接受你的帮助，因为他们担心你会搞砸。但当你证明自己之后，他们会信任你，放心把事情交给你一起合作。一个互帮互助的一流团队才能真正做到1＋1远大于2。
2．通过完成艰巨任务，一流人才互设榜样。你会想“真牛啊，这哥们儿竟然能把这玩意儿做出来，我得加油了”，对这种同伴带来的压力进行合理利用，可以大幅度提高工作表现，并在团队中形成良性循环。Facebook鼓励不同项目间公开分享他们的苦与乐、成果与教训，从不吝啬对好项目的公开赞美，这样才能让榜样的影响传播开来。
3．一流人才喜欢互相挑战。我记得有一位工程师总监曾立下赌约——如果在规定时限之前完成网站翻译平台所需的代码修改，他将把头发染成蓝色。这样的挑战把“枯燥”的工作变成了具有挑战性的游戏。在玩游戏中写程序比纯粹地写程序要有趣得多。当然公司里也有很多更加认真的挑战。Facebook有个很知名的开源项目，公开叫HipHop，它是将PHP的代码重写成C++，然后再编译成二进制代码，可节省CPU资源40％以上。这个项目一开始没有人相信能完成，但推动这个项目的华人工程师赵海平坚持了下来，并做到了。赵海平后来被美国《快公司》（Fast Company）杂志评为2010年度全世界最具创新精神的50人之一。这种高难度的挑战在Facebook并不罕见。因为一流人才天生容易对挑战上瘾，不管是挑战别人还是接受新的挑战。
4．一流人才可以相互学到很多。每个一流人才都有自己“牛”的地方，彼此有很多可以互补之处。如果Facebook没有这种学习的环境，我就可能不会在那儿待四年多。对缺乏经验的人来说，这点很有用。我们雇用非常聪明的毕业生（潜在的一流人才），这些人希望“引爆”自己来证明他们“牛”在何处，他们不愿到一个舒适、无挑战的公司过日复一日的生活，他们希望通过不断学习来丰富自己的经验，完成不可能完成的任务，并在职业生涯中前进，证明“我行”。毫无疑问，和一流人才在一起，才能更容易地实现这些目标。
这一计划的主要推动者是安德鲁·博斯沃思（Andrew Bosworth），大家都习惯叫他“Boz”，他是扎克伯格在哈佛大学读书时的老师，曾经教过后者人工智能这门课程，于2006年加盟Facebook，当时公司只有15位员工。他帮助设计了网站的一些重要功能，比如动态消息（News Feed）。我刚去Facebook时，热身的第一个项目就是和Boz一起合作的——我们要在动态消息中插入一些关于整个Facebook社区的新闻或用户自己所在社区的新闻。Boz非常强势，很有主见。这个特点让他在运作新兵训练营以及和很多工程总监打交道时，能够坚持己见，在新兵训练营为团队输送人才的时候不会因为对方强势而屈服于某位研发经理。
博斯沃斯是公司文化的主要捍卫者。“上帝不允许我们有一天不为Facebook的未来做准备。我们曾见过一家又一家公司在做大后因为规模陷入麻烦，或因为文化陷入麻烦。”2008年初，博斯沃斯开始意识到，Facebook的文化可能面临挑战甚至失败。他刚进公司时，所有人都彼此认识，可是，2008年夏季的一天，当他在公司餐厅排队时，遇到了一位之前从未见过的工程师。于是博斯沃斯问他，在公司干了多久。对方的回答让他震惊：一年。他感觉有点不对劲儿。他想：“我们是Facebook，如果我们不能规划一个超过150人的沟通网络，就真的有麻烦了。”
Facebook希望工程师在第一天就把所有编程环境设置好，在第一天就提交代码。这样可以在周二参与每周例行的代码发布活动，将代码同步到Facebook几十万台服务器中。
第一周的周一，新来的工程师们在公司自助餐厅里和他们的导师（Mentor）吃完午餐后，为期六周的强制性训练营就拉开序幕了。这位导师将全权负责回答新人们的各种问题，从工作、生活到八卦，如果新人感兴趣的话。简短的介绍之后（博斯沃斯和其他老员工会在这个环节介绍公司的文化），每人会分到一台电脑和一张办公桌。第一次打开电脑时，他们会收到6封电子邮件，其中1封是欢迎信，另外5封介绍了他们将要执行的任务，包括修复Facebook网站上的错误。训练的目的很多，其中之一就是让新员工充分认识到，他们拥有直接改变Facebook网站的力量。
Facebook希望工程师在第一天就把所有编程环境设置好，在第一天就提交代码。这样可以在周二参与每周例行的代码发布活动，将代码同步到Facebook几十万台服务器中。Facebook并不希望新人在第一天提交复杂的代码，基本都是很简单的改编，希望通过练手让工程师能迅速了解整个流程，迅速进入角色。
前三周有很多课程要上。一般公司的COO（首席运营官）、CPO（首席产品官）、工程副总裁都会在第一周给新人们介绍各个部门的概况，使大家有一个全局的认识。第二周，重点在于公司各个重要产品、常用的技术框架和技术工具的介绍。第三周，集中在公司的运营（包括市场、销售等部门），商业模式（Facebook主要的广告模式和虚拟货币的赢利手段）和其他非产品技术部门的介绍。
从第三周开始，新人们就开始接触很多相关的需要招人的组，和这些组的经理交流，了解这些组的产品，参加这些组的会议和讨论。一般要求在第三周的周末，新人要选出不多于三个组作为他们感兴趣的备选组。接下来每一周的事情就是进一步缩小目标范围，以达到在第六周时只剩一个备选组的目的。这个组当然就是新人最后要加入的组。
从第一周到第六周，所有新人60％以上的时间，都需要花在修复代码错误上面。其他所有的事情应该在剩余的40％时间内完成。Facebook相信，让工程师融入公司最好的办法是通过代码的交流。毕竟，产生高质量的代码是所有工程师最主要的工作。
不懂就问，而不是自己先钻研的人，在Facebook不受欢迎。
除非有特殊情况，一般某个新员工选定的组都会接收他，不能拒绝。因为如果你拒绝的理由是“他不行”的话，那不如解雇他；如果说你不愿意让他到你的组但可以到其他组，这种想法违背Facebook的文化。我在前面就强调过这一点，“我们都是为Facebook工作的，而不是为了某个小组工作”，所以如果你觉得某个新员工不行，那其他组也不应该要他。如果原因是“他的背景不适合”，那一开始就不应该见面会谈。导师极力避免把新人介绍到明显不适合的组里面，所以这个理由也不成立。
据我了解，国内的很多公司里，升职跟员工的薪酬水平是直接相关的，只有向经理、总监这样往上爬才能获得更高的收入，而单纯做工程师，薪酬的增长空间相对有限。所以，不少工程师很想得到升职机会，但公司里能提供的职位毕竟有限。而像包括Facebook在内的很多硅谷公司，工程师跟行政管理者是两套不同的体系，即便你一直做工程师，只要你做得很出色，一样可以达到很高的薪酬水平，并不比你向经理、总监、副总裁这么一步步爬上去差。像我们组里优秀的资深工程师，就有比我拿更多薪水的。这一点，我一点都不在乎。
员工股份的基本种类分两种，一种是期权（Options），一种是受限股票单元（Restricted Stock Unit，简称“RSU”）。期权需要员工行权（Exercise Options）后才能购买股票（Shares）。所谓的期权行权就是以员工入职当天的市场合理价格（Fa ir Market Value，由会计公司审计后参考各种因素决定）来购买股票，即使你要行权时的股票价格已经是入职当天的几十倍。比如，如果入职的当天价格是1分，而今天股价是1元，那么员工可以花1分钱购买价值1元钱的股份。如果私下市场存在和公司允许，可以直接卖出，或者等到将来公司上市后再以市场价格卖出。这里面还有很多合理、合法优化税率的办法，在美国可以买到很多关于这方面砖头一样厚的书。而受限股票单元是直接发放到员工名下，但只能上市之后在公开市场上才能兑现。受限股票单元一个很大的问题是其税率很高，基本没有什么优惠策略，在上市兑现的时候马上算作收入，45％左右的股票是要送给美国政府交税的。
在Facebook拿期权的员工基本上都是在2007年9月左右微软花2.4亿美金投资Facebook之前加入公司的，这样的员工有300人左右，之后发放的即是受限股票单元。原因在于微软的这次投资把公司市场合理价格顶上去了，如果再发放期权，留给员工的利益空间很小。这就是为什么期权一般是在股价还非常低时发放，股价较高时，就改成了受限股票单元。
和硅谷其他科技公司一样，在Facebook获得股份的方式有两种：第一种是在入职之前Offer中谈条件的时候定好的；第二种是入职之后在每次业绩评价之后作为激励加送。如果公司发展很快，第二种往往比第一种的数量小很多。不管是期权还是受限股票单元一般是分4年付清，也有少数公司是5年。在第一个周年日之后，1/4（如果是4年付清）的期权会发到员工名下，接下来的每一个月1/48的期权会发到员工名下，直到第4年末，所有期权付清。期权一旦到了员工名下，员工可以选择在任何时候行权，直到离职后的3个月。第二种股权的发放由于和业绩评估挂钩，接下来会讲讲考核激励体系。像很多公司一样，Facebook有一套完善的业绩评价体系，也有相应的计算公式，你能获得的奖励或股份究竟能达到多少，某种程度上是由你自己的表现决定的。
在Facebook，定期的业绩评价每年进行两次，年中和年底各一次（这种情况在硅谷的公司中很常见），评价结果都会跟升职、工资、奖金挂钩，而年底评价还跟股份奖励有关。业绩评价由三个部分组成：自我评价、同事评价和老板评价。自我评价是自己给自己打分，这段时间内完成了哪些目标、错失了哪些目标，哪些方面做得好，哪些方面还有待进步。同事评价当然不是为了让员工之间相互责难的，而是希望员工成为相互的镜子，对自己、对他人有更全面的认识。老板评价则是综合考虑各种因素，给予最后的考核等级。
至于同事评价的部分，员工个人可以提出一些人选，让这些同事给自己评价，经理也会指定一些人选，加起来一般都在四五个，最多不超过八个。公司希望这种评价是具有建设性的，也就是说，要在肯定员工工作成绩的同时，一定要指出还有哪些地方可以改进、提高。因为业绩评价虽然跟薪酬奖励挂钩，但薪酬奖励毕竟不是目的，而是能够反映员工贡献的手段，激励员工更好地为公司做贡献。所以，指出员工哪些地方可以做得更好，才能真正帮助员工成长，最终为公司带来好处。评价并不能简单地写个结论完事，评价者要进行相关阐述，用具体事例予以支持，比如你要说某某同事沟通能力需要加强，那就最好举出例子来，否则仅仅只有笼统的评价容易让被评价者一头雾水。
老板在综合各方面的意见后，给出对一个员工的综合评价，如果要指出需要改进之处，最好不要超过四条，因为每个评价周期是六个月，员工的精力有限，你列出太多需要改进的点，他很可能也做不好，没有实际意义。不如每次都让他关注在少数几个点上努力改进，对他的帮助会更有效。
除了评价之外，给员工打分评级也很重要，这就跟每个人的薪酬奖励直接相关了。一般表现的员工都在“Meets Expectation（满足了期望）”这一级，往上更好的有“Exceeds Expectation（超越了期望）”、“Greatly Exceeds Expectation（大幅超越了期望）”、最优秀的是“Redefine Expectation（重新定义了期望）”，往下较差的有“Meets Most Expectation（基本满足了期望）”“Barely Meets Expectation（部分满足了期望）”“Doesn't Meet（完全没有满足期望）”。在评分的同时，决定要不要推荐升职（Promotion）。通常只有在连续两次或以上得到高于“超越了期望值”的评级才有可能获得升职机会。
对于评级，不同的组之间还要进行校正（Cross Calibration），以防止各组的评价标准不一致。比如，你所在的组里评为“大幅超越了期望”的，可能到了别的组只是“满足了期望”，这种结果就是不公平的，要么是你的组标准过低了，要么是别的组标准过高了。像我所在的组，要跟两类组进行评级校正：一类是纵向的，就是我老板的老板管理的大组——平台组，下面一共有八个经理，大家坐在一起讨论各自的评价标准，尤其是两头的极端评级要重点分析；一类是横向的，跟其他相关的组，比如我们组要跟反垃圾信息组、工具组在一起进行校正，因为我们做的事情相关度较大，人员交流很多。在讨论会之前，所有参与组的经理把相关人员的信息放到一个共享文档中。文档中记录了员工的此次评级，上两次的评级，什么时候加入Facebook，这次是否有升职推荐，这六个月中最大的贡献是什么，最需要提高的地方是什么，等等。在讨论中，大家会用40％的时间将每个员工都讨论一遍，剩下60％的时间则放在表现特别好或者特别不好的员工身上，进行重点讨论。为什么这位员工可以获得“重新定义了期望”的评级，原先对他的期望是什么，他究竟完成了什么样的工作来“重新定义了期望”。对这种极端例子的讨论，可以交流各组的期望标准是否一致，什么样的期望才是有难度但又可行的（Aggressive but Reasonable）。通过讨论，大家可以在不同想法中碰撞出火花。公司就希望经过这种校正，使得整个工程师队伍有一套相对一致的评价标准，尽量减少不公平现象。
在业绩评价中，公司对于每种评级所占的比例并没有强制性的要求，但每次的结果出来之后，并不会出乎大家的意料，最多的当然是“满足了期望”、“超越了期望”、“基本满足了期望”这些级，大概占到70％，而两个极端的评级就非常少，不会超过5％。其实，在Facebook进行业绩评价的确不是一件容易的事，从前面对于招聘的介绍中我们知道，员工进入的门槛已经很高了，要在这些高质量的人才里分出若干个等级来，十分费劲。
如何有效传递整理好的意见也很重要。有句话是“你说什么并不重要，关键在于你如何说（It's not about what you say, It's abou thow you say it）”我也觉得如何传递意见非常重要。有两种方式我都试过，不确定哪种更有效。一种是以问为主，逐渐深入促其思考。比如“你感觉自己昨天主持的会议如何”。另外一种是直入主题，“让我们来谈谈你昨天主持的会议吧”，然后开始谈我自己的感觉。不管哪种方式，一定要给对方一个解释自己行为的机会，永远假设并告诉他我相信他的意愿是好的。我首先争取和他们在“我们感知的即是事实（What people perceive is what they believe）”这一点上达成共识，基于这个前提，我们把讨论的重点放在如何做才能改变别人的感受、最后让事情顺利完成，毕竟大多数重要的事都有很多人一同协作完成。当他们真心认识到自己需要改进某个方面的时候，如何改是一个相对容易得多的问题——聪明人一向能够找出改进的办法，我所做的就是配合他们进行头脑风暴。最终谈话的目的是产生下次如何能做得更好的具体行动方案（Actionable Items）。
关于有效传递意见反馈，还有几点要提一下。
1．意见反馈不见得都是负面的。你可以指出你很欣赏的对方的长处，希望他在这方面坚持做、做得更多，这样可能产生很好的激励效果。在员工某件事情做得不错的时候，不要吝啬赞美，直接告诉他：
“关于……你做得很棒，请继续保持！”
2．意见反馈必须摆事实、讲道理。如果你只是告诉别人他很烂，但不说什么时候做得不好以及为什么，除了给他带来负面情绪之外毫无他用。所以，我在相关人员包括自己写意见反馈的时候要求提供实例。
3．意见反馈必须是可操作的，让人无从下手的意见意义不大。如果在提意见的同时提供一个方案以供参考就有意义得多。但要注意，绝不能以命令的方式。如果没有供参考的方案也没关系，这种情况下可以和他一起分析当时的情况，把各种不同的做法都做一些分析，通过对每步选择“多问几个为什么”的方式，来看看如果重回到现场，有没有一种更好的方案。
4．（这一点是个人偏好）在最近的两个评价周期中，我曾给15位同事（一半不汇报给我）写过意见反馈，并且直接通过邮件分享给他们。出于这种想法，我在下笔时就少了很多感性冲动，更多关心的是能否提供产生具体行动方案的建议。正是因为他们会读，所以我无法做到背后捅刀（其实就算他们看不到我也不会这么做，但我直接分享的话，让他们知道我肯定不会）。我需要写得有意义、容易理解，并且加上很多例子，还欢迎他们和我直接讨论。如此一来，他们就会明白我写这些反馈的确是为了帮助他们进步。
