励志人生

人类难以有效的处理10个以上的变量。我们需要更加的可测量化。我们想要使很多机器比人更擅长的事情自动化。从而我们树立了一个远景，将我们主要的规则置换为机器学习模型。这一远景驱使我们增加了一位机器学习领域的博士和另一位在加入facebook以前有类似实操经验的工程师。注巨大，但是未来需要这个。 但你需要对细节灵活，因为条条大路通罗马。你需要给你的团队以足够的余地空间（wiggle room），只要你的团队是朝着正确的方向以合适的速度前进。另一个故事：一度我对决策树的兴趣比回归要大。但是实验算法的工程师告诉我在选择算法的时候他们只有可以忽略的区别。我可以坚持己见（这确实是当时我真实的想法）但我信任他并让他放手去选合适的算法。同设计者合作的过程中也有趣事发生，他们对于字体，颜色，行距及其他都有着吹毛求疵的偏好。我通常让他们由着性子只要对最终结果有益就行。我们想要选择正确的战场开战，这样的战场必须关乎全局，而不是纠缠于局部战斗。

⑴这让你更加愿意托付。救我的经验来看，牛人不会信任不熟悉的人。在接受你的帮助之前，他们需要知道你同他们一样出色甚至比他们自己还强。否则，他们宁愿尽其所能的独立完成。但如果你业已得到证明，他们将会非常信任你并乐于托付给你。一个有着有效托付的牛逼团队几乎无所不能。 ⑵他们相互为榜样，并且籍此提升工作表现。这是很好的关注压力。如果使用得当，可以形成团队的良性循环。

⑶牛人们相互挑战。我记得一位工程师主管曾就我们能否在规定时限之前完 成网站翻译所需的代码修改来打，他将把头发染成蓝色。这样的挑战往往是的“枯燥”的工作变成了游戏。成为游戏的一部分将非常有趣。当然往往会有更严肃的挑战，而且牛人喜欢挑战（不管是挑战别人还是接受挑战） ⑷牛人们相互学到很多。如果不是因为这里有这么多可以学习的话我不会在facebook呆4年。对缺乏经验的人来说，这显得越发正确。我们雇佣非常聪明的毕业生，这些人被激发来证明他们的牛逼之处。他们不愿来到一个舒适并且没有挑战性生活的公司。他们想学很多来丰富他们的经验，完成不可完成的任务并提升他们的职业路径。他们想要证明“是的，他们可以”。他们想和牛人一起来实现这些。

你不想要二流货色但如何远离他们？首先，慢点招人。在给offer的时候固执一点。我曾无数次的在招聘决策会议上发现那些有着光辉履历的人无法得到雇佣只是因为某个面试官觉得这人无法给他以深刻印象。在其他例子当中，那些获得一致通过的候选人仍然无法获得雇佣机会因为每个人都只是觉得他将将符合要求而已。在雇佣问题上，绝大多数情形下，你要风险规避。（顺便提一下我们也会雇用那些没有全票通过的候选人，只要有一两票强烈推荐﹣你将乐于在信任你员工的问题上冒险）其次，炒鱿鱼要快。让二流货色存在就像服用慢性。一天一点，逐渐但终究你会为此挂掉。你要紧你所能的把二流货色踢到鱿鱼轨道上（在某些情况下，法律不让你这么做）我见过一些慢吞吞的鱿鱼，那对团队造成的负面作用可不是闹着玩的。

有一点要强调的是﹣你还是要现实。在你只有10%的市场份额的时候却幻想10几倍的收入增长无疑不现实。史蒂夫乔老爷非常善于推动他的团队超越潜能但同时也榨干他们（尽管如此他们是这样为他们所做的而自豪）99。9%的领导不是乔老爷，当然他们也不需要是。但你仍然可以通过驱动一个可持续性的团队来取得成功同认识到他们的极限并无矛盾。

但你不能忽视数据。没有数据的支撑而一味靠直觉走黑路，很容易走岔道，甚至大错特错。有一段时间我们认为爬行工具（通过分析关联的cookie，信用卡）可能可以找到很多欺诈的同伙。通过实验结果却发现，这种预期是否成立很大程度上取决于当前流行的欺诈行为的特点。比如，当失或贩卖信用卡的案例非常普遍的时候，关联分析是一种有效的方法。但如主要情况是帐户被黑或小宝们冒用妈妈的信用卡去网游消费时，关联分析就作用不大。直觉在现实前面碰了一脸的灰。不过幸运的是我们很快意识到这点且把这个项目叫停了，所以没有浪费太多的资源。

另外，顺带提一下A/B测试。A/B测试并不会告诉你去做什么产品，但它可以帮你确定实现产品时的哪个细微版本更能揪住用户大爷们的心。

那究竟哪些时间不应该被浪费呢？ 很多，但我只举两个我认为最重要的例子。 邮件。不是所有邮件都发而平等。有些邮件纯粹打酱油的。有些邮件是不需要马上处理的。我尝试使用过滤规则来踢掉打酱油的邮件，突出需要马上处理的重要邮件。对此，分享两点。

会议。开会太容易变成一群人互相在扯对方的蛋。浪费时间而且开完后发现没有结论且很蛋疼。但开会对于teamwork很多时候是必要的。如何主持会议是门学问，这里不细谈。不过，你不可能也不需要参加每个邀请你的会议。当你认为你参加某会议于己于人都无太多价值的时候，建议你考虑不去。如果想要有礼貌一点，那就写个email问问主持人你是否可以缺席。通常当你想过这个问题决定发这样的邮件时，答案通常都会是yes。有些时候我也会很可耻的让我的产品经理替我去开会。当然，我会鼓励他也争取不要去。Only make the meetings you really he to。同样，我要求我自己的团队在组织和参加会议的时候要慎重，也经常问他们想想看自己花在会议上的时间是不是多了。一个做法是把可能的会议都整合在一起。有一个例子。早些时候，我们会经常收到来自支持团队的比较随意的会面请求。这让攻城狮的一天被会议分割得支离破碎。写代码的都知道没有3-4个小时的连续时间是不容易高潮的。而且这种会议通常效率很低。于是，我们改变了做法，每周安排固定的答疑时间（office hour）和支持团队嗑想法然后follow up。当然，紧急的问题另当别论应当马上处理。

有一个被经常忽略的原则–有意识地去思考哪些事情不应该做并且马上不做。例如，哪些是无谓的争论可以避免介入（比如韩寒和方舟子的–个人意见），哪些功能可以放弃，哪些关系不应该发展，哪些人应该开掉，等等。我经常问自己一个很简单的问题，我现在正在做的是否对我的目标很重要。如果你清楚自己正在做的和自己想要的，答案会明了。Go for it。

不同的工程师团队也存在着合作竞争关系。反垃圾邮件、安全和反欺诈（我的团队）这几个团队之间存在密切的工作协作关系。这些团队也都尽可能地相互学习，分享经验和技术。但是，有时候各团队独立处理类似但不同的一些问题时，都试图向对方推销自己的解决方案和理念。 如何让合作竞争保持在一种健康有序的状态？我觉得关键是促进人与人之间的亲密感。把人搞近了，事情就容易了。我花大量时间用在建立和其他团队的关系上面。例如两周一次或者一月一次和其他团队老大们的1对1碰头会。越相关的团队，头碰得越频繁。我自己或者我的团队成员会有选择性的经常参加一些其他团队的会议。当为一个共同的大项目工作时，我曾安排不同的部门成员（工程师、支持、数据分析、金融财务）坐到一起进行项目冲刺。这是拉近相互之间距离的非常有效的一个做法，尤其对于减少扯皮的机会。因为互相之间经常会请或被请喝咖啡。我也会经常和一些人约定吃工作午餐，经常聊的是家常，增的是感情。有的时候一次长距离的散步也更能让人畅所欲言。而这样的紧密关系，在我们面对一个极具挑战性的项目的关键时刻，会帮助大家紧紧的抱团闯关。