我发现雅虎所谓的「公司政治」问题比较严重，没有那么很强烈的「所有人做事都是为了雅虎」的理念，他们内部是以BU(业务单元)这种方式运作的，小组与小组之间存在隔膜，都主要考虑自身那一小块的利益，相互之间的配合支持度较差。……后来到了Facebook，感觉完全不一样，绝大多数人都很清楚，「我们并不是为了某个小组工作的，我们的目标是整个Facebook的发展」。

   比如在雅虎要做一个产品，有十项功能的产品，那产品经理会列出一个表来，让工程师看可不可以做，每个功能又需要多少天完成，还要签字确认，就等于你承诺了多久要做完，并变成了工程师的「责任」，感觉很像是被迫签了一份卖身契。其实，每个产品当然要估算一个完成的时间，但是这种做法对工程师的负面影响就在于，更多关注在「时间」上，而不是要把工作「做好」，只是把工程师当作工具。

   在进行「文化适应性面试」时……让他回答「为什么对Facebook感兴趣」的问题。我们最不想听到的就是强调潜在的财务回报，虽然大家都知道这肯定是一个因素。但在如此宝贵的时间里去强调这一点，而不是其他更有意思的方面，会让面试人员产生反感。如果Facebook的财务表现在短期内不符合他们的想象，这些人会很快走掉。

   针对一段时间内面试的情况，公司每周会召开一个招聘决策会议，所有相关的面试人员和人力资源部门的代表都会参会，所有的应聘者都会被讨论，大家一起讨论应聘者的去留，明显不行的最快，明显行的也比较快，比较费时间的是那种所有人都说行、但没有一个人被震惊到，或者有人说不行、有人说很行的情况。这时候，如果有一个人愿意站出来力挺，一般不会被砍掉，可能会通过，也可能被安排一次后续的面试，再见上1～2个人，专门针对他上次面试中暴露出来的弱点提问题，来看他是如何解决的。总之，整体上的思路就是「请拿亮点来说服我」。

   Facebook就是希望通过这样的程序能找到一流的、合适的人才，这样才能做出最好的产品，成就伟大事业。面试中的技术性问题就是解决「是否一流」的问题，文化性问题就是解决「是否合适」的问题。一流人才只愿意和与自己水平相当的人共事，他们聚在一起会变得更好。一流人才无法容忍二流人才。

   只有你真正重视招聘，你才可能从尽可能广的范围内去搜罗、挑选人才，而不仅仅是从你的「应聘名单」上挑选。你要认识到，招聘是竞争的第一步，业内一流人才如果没有进入你的公司，那他们就在竞争对手的公司服务。这意味着，还没在市场上正式过招，你就输在了起跑线上。

   我在Facebook这四年半，一开始几乎每个工程师都互相认识，但随着人员迅速增长，这一点变得不可能。如何有效地让最适合(潜在)合作的人互相认识，有信任感，以保证项目的高效完成，成了Facebook这些年很大的挑战。等到项目开始时，参与的人员才彼此认识，那么磨合期会更长，磨合成本会更高。

   在产品开发的过程中，工程师的主动性体现在要善于处理不确定性，迅速发布满足可以接受的最低标准(但并非低标准)的产品，再根据监测数据的情况不断完善，最终达到极致。

   不断发展、改进公司的内部工具，可以极大地提高每个员工的工作效率，可以减少运营人员的数量。这样既改善了整体协调，又减少了整体开支。

   成为经理后，并不是说你要去「管」那些工程师，主要是榜样(Lead by Example)的作用，你要向他们展现什么才是优秀的做事方法，怎样能将产品做到极致。作为团队的领导者，你需要设定足够高但合理的期望：足够高得使你的团队成员不会感到没有挑战性，但又合理到不至于使他们油尽灯枯。你要给他们创造出一段经历，使得在「旅程」结束，他们回头看时会说：「哇，我都没想到自己居然做到了，这太牛了！」

   在实践中，对于我不是特别了解的被委托人，我是这么做的：项目开始时，我让被委托人给我一个整体计划以及完成时间，一开始经常会面跟进，然后确定后几天的任务，根据每次的完成状况来估计他能不能「按时按质按量」地实现最终目标。对他逐渐建立起信心后，可以减少关于该项目的细节讨论，此时的委托可以放得开一些。

   Facebook非常鼓励员工自己通过研究，通过和专业人士交流，通过思考，自己来做出困难的决定，而不是听经理的话。在会面中，对于各种问题的讨论，我们会特别关注相关的行动项目(Action Items)，为的就是避免谈话变成空谈而非行动。会面之后，下属会要求在当天电邮一个非常简短的会议记录(Meeting Notes)，主要就是聚焦在行动项目上，以作为下次一对一碰面的讨论基础。

   让自己的老板做导师是比较难处理的一件事。因为导师给出的建议，是否采纳，如何采纳，都是自己的事。然而，老板作为导师，他的建议究竟是建议还是任务、采纳的结果如何会直接影响他对你的评价，还有你对他的评价。这种利益上的考量，会让双方在交流中有所顾忌和保留。基于这样的原因，我不建议在和自己有业务上下级关系的人中寻找导师。

   如果你想说服其他人采取你的想法，你需要两样东西。一个是故事，或者叫例子，就是为什么这样做有效，能不能让你的说法有感染力，让你的说法给人留下印象；另外一个是数据，让你的说法有数据的支持，那么可信度会高很多。

   很重要的一点是，设计产品时，你要大概知道第一版本(V1)是什么样子的。你可以在设计时构思产品的最终状态，但公司不会允许你花大量的资源去打造一个所谓的终极版本。何况，终极版本通常只存在于臆想之中，用户的反馈会让你迅速明白，你需要的是一个能反映出你想法的第一版本，迅速推出后根据市场反应进行更新。

   通常，为了把第一版本推出去，我们经常用「试验(Experiment)」的理由，是告诉别人我们需要第一版本在有控制的范围中来验证产品，并会严格监测重要数据。如果产品成功，我们会在后续版本中再认真考虑更多的功能。以试验的方式推出新产品，通常阻力要小很多。

建议继续学习：

1. 哪本书是对程序员最有影响、每个程序员都该阅读的书？    (阅读：13774)
2. Facebook 网站架构    (阅读：9752)
3. 从“架构师书单”讲开去    (阅读：7985)
4. 一路读来 – 那些曾改变我思维轨迹的书    (阅读：6813)
5. facebook 的工程师文化    (阅读：6238)
6. Facebook 的系统架构    (阅读：4982)
7. 互联网产品经理必读书目    (阅读：4741)
8. 谈谈Facebook的聊天系统架构    (阅读：4552)
9. Facebook性能大提升的秘密：HipHop    (阅读：4346)
10. 给学PHP、工作中在用PHP的朋友们推荐几本书    (阅读：4254)