众所周知，湾区的公司在面试时非常注重实际编码能力，要求直接在线或在纸上、白板上写代码，并且要求是可编译的零bug代码，因此有ACM背景的应聘者会非常占优。当然，不同公司在严格程度上也不尽相同，比如Amazon对无伤大雅的手误或API细节记不清等情况相对宽容，Facebook次之，Google最严格。反观国内的互联网公司，虽然面试时也会问算法问题（尤其是对应届生），但一般不太会要求手写达到可编译运行质量的代码（要求写伪码的居多）；同时考量的知识面也会更广、更开放一些。一开始我觉得湾区的这种面试方法并不科学——毕竟实际工作中没人会要求你在不借助调试器等工具的情况下一次性编码成功。而且，竞赛类算法题的代码和工业界的代码完全就是两种套路（在工业界干过几年的前ACM选手们应该非常清楚）。但反过来一想，自己周围能够达到这个水准的，无一不是牛人。而且这个方法高度统一，易于判定，在大规模面试中更利于统一面试官的评判标准，从而达到严格把关面试质量的目的。总而言之，这种面试手段跟高考有点类似——它可能不是最为合理的选拔手段，但对于大公司来说，为了保证更大范围内的公平性和质量，似乎也没有更为合理的手段，因此就现阶段而言它也就是最为合理的手段了。

就我个人而言，在校时顶多也就参加过ACM校赛；无论刷题速度还是数学和算法基础都远逊于专业选手，纯粹是玩儿票水准。工作六年多更是基本告别基础算法，顶多也就是算个时空复杂度，偶尔用一次微积分都会感慨万千原来这玩意儿还真有用得上的时候。再者就是平时写程序的习惯。经过严格训练的ACM选手可以做到解题时从头至尾一气呵成，当年ZJU校队神人们直接在提交框里写码提交一次AC的传说屡见不鲜。我平时自知是个粗心鬼，写程序一定是先搭架子后填肉，边填边调；要是妄图一次成功，那最后多半是错得没边儿。所以，算法基本功以及编码不够快、准、狠，就是我最大的弱项。

为了弥补这些不足，我最早采用的方式是啃Algorithms、The Algorithm Design Manual等大部头。然而实践证明这个方法收效甚微。当然不是书不好，而是心态问题。这些大部头行文严谨，事无巨细悉数记录在案，最适合用作教材或是当作手册日常翻阅。对于目标主要是查漏补缺的我来说，从头到尾看一遍太慢，而且一不小心就陷入细节或是一些事后证明完全没有必要钻的难点；跳着看又不知道到底哪里是自己缺漏之处，无的放矢。

要想搞清楚缺漏之处究竟在哪，最有效的办法还是实际做题。做不出来的自然就是缺漏，重点补习；做得出来的则尽量争取一次到位，追求编程速度。在这条路上先后尝试了CareerCup、ZOJ、TopCoder和LeetCode。四个站点的优缺点对比如下：

• CareerCup

  作为全世界码农应聘者交流面试经验和真题的集散地，其优点自然就是真题丰富。缺点也很明显：很多题目描述不严谨，边界情况模糊；没有OJ，自己的代码正确与否难以得到客观准确的判断；参考答案仅限于用户贴出的代码和思考，而且CareerCup论坛的代码排版效果恶心得令人难以置信，你几乎不可能贴出一份缩进正确的代码！

• ZOJ、TopCoder

  ZOJ实在是太熟悉了，本科时闲来无事就在ZOJ上切题。TopCoder交互比较复杂，但流程基本上差不多。二者都是OJ，因此自己的代码正确与否、效率如何，都可以迅速判定。TopCoder相对于ZOJ的一个优点是可以检索指定难度和类别的题目。缺点则是这二者都是竞技平台，当OJ判定代码错误时不会输出额外的诊断信息，一旦陷入难以想到的边界情况就会花费大量时间。

  此外，就这次的经验来看，ZOJ的题和TopCoder 500分以上的题在平均难度上比实际的面试题要高不少。与其在难题上耗费过多时间，多切一些简单题提高写代码的熟练程度可能更有帮助。

• LeetCode

  LeetCode可以说是结合了CareerCup和ZOJ、TopCoder的优点：既有真题，又有OJ。而且当OJ判定代码错误时，会同时输出对应的测试用例，大大方便了调试。在面试准备的后期，我完全转向了LeetCode，训练效果显著。对了，目前LeetCode后台的C++编译器已升级到g++ 4.7.2，支持大部分C++11特性（尚不支持lambda），写起C++来舒心不少 :-) 就这次的经验来看，实际面试题的难度跟LeetCode的平均难度相差无几。缺点则是题量较少，目前仅有100多题，覆盖面较窄（例如二叉树的题有一大堆，而图论题则几乎没有）。

这里引用Cat在他的Facebook面经中说的一段话：

让我「大开眼界」的是面试题，原来真正好的面试题并不在于它有多难，而在于它有多简单，简单到熟悉这个领域的人一下子就明白到你在说什么以及想问什么。能够进入 Facebook 的人应该都觉得面试不难，至少跟中国的面试对比起来如此，那是因为 Facebook 把觉得面试有点难的人都过滤掉了，而中国那些很难的面试反而没什么区分度。

就我自己的经历来看，的确如此。从难度上说，至少在电面阶段，Google、Amazon、Facebook的算法类面试题都是入门级的题目。给我的感觉有点像是考研——题不在难，而在区分度，考的是基础是否足够扎实。题目拿到手会做的话立马就能下手，即便不会做也会觉得这道题很眼熟。Facebook onsite面试题的难度基本上也在这个水准。Google和Amazon两家都没有进行到最后阶段，不知道后续的难度是否会有提升。从别的面经上来看，Google的算法题在难度上要更胜一筹，Amazon则会有一些面向对象类的系统设计题。

英语沟通

虽然对自己的英语还算有信心，但此次面试前基本上没有跟老外面对面沟通过，所以第一次英语电话面试的时候紧张得语无伦次，经常听不清面试官在说啥，好在从第二次开始就完全无压力了，窍门很简单：提前打招呼让面试官说慢点……说的时候不需要担心语法错误之类，正如某篇面经所说，人脑的纠错能力还是很强悍的，就算一个词一个词往外蹦，老外一般也能够理解。

跑题说一说口语练习，这方面好像没法短期突击，只能靠平时多磨刀。英语口语，一是口音，二是流利程度。口音的问题，我是中学的时候靠听英语歌并极力模仿歌手的发音解决的。至于流利程度，自然是靠多说。但周围没有说英语的人咋办呢？我的办法比较偏门——自言自语。以前在学校和公司里的时候，出于种种原因经常需要做技术分享，必须确切明白地把事物讲清楚。久而久之逐渐发现判断自己有没有把一个概念搞明白，最直接的办法就是看能不能把这个概念跟新手讲清楚，于是日常学习的时候也经常在脑袋里做模拟。就这样，渐渐染上了自言自语的毛病，即面对假想的听众把自己的思路讲出来，一边讲一边揣摩听众可能的反应并反复调整说辞，直至表述准确易懂为止。再加上近年来看的文献基本上都是英语，很多术语根本找不到合适的中文翻译，脑子里两个locale切来切去太麻烦，渐渐就养成了用英语自言自语的习惯，无意间变相练习了口语。当然了，这种手段只能锻炼到专业技术方面的内容，日常沟通是覆盖不到的。不过对于面试来说，刚好够用。

面试过程

1） Google

Google的面试机会是师兄推荐得到的。事后来看当时完全没有准备好，实在是浪费了一次大好机会，对不住师兄。被推荐后不久，Google北京的HR联系我。电话聊了大概半个多钟头，了解了一些背景情况，然后便着手帮我安排电话面试和onsite面试。

电话面试的面试官是美国的华人工程师，全程说的是中文。由于时差，面试时间是北京时间早上八点（对方的下午四点）。简单问了一些之前的工作背景就开始做题，大致是写一个类，模拟TCP栈的收包逻辑。写完之后又要求改为多线程版本，类似于一个生产者消费者模型。Google电话面试时是在Google Docs上在线写代码的。头一回写，动作比较慢，总体上超时比较多，而且第一次给出的解法虽然没有错但并不高效。多线程版本快写完的时候SSH隧道竟然断了（Google Docs直接访问不稳定，保险起见是FQ访问的）！由于面试已经超过预订时间，面试官就说算了，面试结束后发到他邮箱好了。最后是例行的问答时间，不记得当时自己问的是什么问题了。

虽然面试官让我把最后一个问题的代码用邮件发过去，他却没有给我留邮箱，事后是通过HR转发给面试官的。此外面试结束后发现面试官给出的多线程的条件有误，会导致系统死锁。于是写了封长邮件，解释了会导致死锁的时序，给出了两种可能的解决方案，并附上了详尽的测试用例，顺便优化了一开始效率不够高的数据结构。当然，过程中没有查阅其他资料，完全是独立思考的。

约莫一周之后，HR帮忙敲定了位于五道口的onsite面试。两轮面试各45分钟，都是算法题，要求在纸上写代码，面试后纸张由面试官回收，似乎是要誊写到面试反馈中去。第一轮的题目很经典，简单到现在根本不好意思说自己曾经做不出来……如果是一个月后的我的话，毫无疑问可以秒杀，但当时却严重卡壳。第二轮的题目稍有一些纵深，DFS搜索加字典树加接口设计，也不是很难；面试官持续要求优化，最后一个优化点我在最后一分钟才想出来。面试末尾仍然是例行的问答环节，由于之前做了几年即时通讯，我便问了一下Google在实时互联网应用方面有没有什么规划，但由于面试官不是这一领域，无法给出什么实质性的内容，相互嗟叹了一下Google Wave之后面试结束。

两轮onsite下来，自我感觉非常不好，事实上这也是我这段面试经历中表现最差的两轮——没有一道题能够在规定时间内给出完整、无错的代码。回想起来，这个结果跟我当时的复习策略有很大关系：当时我还处在看算法大部头，辅以ZOJ/TopCoder做题的阶段，基本上是什么题难做什么题，后果就是每道题都钻很久，解题时间很长，完全没有达到训练编程熟练程度的目的。再加上纸上写代码一涂改就乱七八糟一团，越写越紧张……就面试中写代码的方式来说，我觉得用CollabEdit或Google Docs在线编程最轻松，因为跟平时写程序差不多（当然如果是平时被VS/VA、Eclipse宠坏了那就两说了）；白板上写代码次之，因为写错的、不满意的地方可以随时擦掉，保持整体整洁；纸上写代码最难，一不小心就涂涂改改搞得一团乱麻，既影响自己的情绪也影响面试评价。

虽然Google的面试只进行到第二轮onsite，但可以看出Google的面试要求还是比较高的。面试官在关注代码的正确性的同时，也会关注编程风格甚至接口的注释。此外，Google的HR工作做得很到位，面试前给我发了详尽的准备材料，邮件回复也很及时。最后电话通知面试结果的时候HR先是问了我自己的感觉，然后结合面试官的评价委婉地给出了结论。

2） Amazon

Amazon的面试机会是同学推荐得到的。和HR全程邮件联系，反馈速度极慢，一个来回至少一周。和我联络的HR的工作时间跟Amazon总部差了几个小时，不知道是不是外包。

Amazon的第一轮电面是我第一次跟老外电话沟通，起先觉得没啥，但临到面试时却紧张得一塌糊涂——面试官语速太快，听不明白啊……由于沟通不是很顺畅，之前的工作背景介绍得比较失败（之前有准备过，但是一紧张全忘了）。面试官的态度虽然很nice，但听语气似乎比较失望。之后，面试官对我申请的AWS组做了一个简要介绍，然后便用CollabEdit在线做了两道字符串的题，过程还算顺利。面试完毕之后review自己的代码，发现有两处小错误，再加上一开始沟通不顺，沮丧地想应该是没戏了。

没想到过了大概两周多，在接到Facebook的onsite面试通知之后，Amazon的HR发邮件过来说打算再进行一轮电话面试，向我征询可用时间。回复之后又过了大约一周，才总算敲定了面试时间。

这个时候我已经有了Facebook三轮电话面试的经验，LeetCode也切了不少题，纸上写代码虽然还欠，但在CollabEdit这样的在线编辑器上几分钟切一道简单题对付电话面试已经完全没有问题（早点知道LeetCode就好了）。于是第二轮电面异常顺利。一上来面试官问我选数据结构的题还是算法的题，我选了数据结构题，半小时多一点切完两道。做第二道题时我把一个条件理解错了，面试官指出后像我道歉说是自己描述不够清楚，好在算法整体上差异不大。做第三道时，面试官鼓励说能做到第三题的候选人不多，因为时间所剩无几，就不要求写代码了，给出思路即可。第三题讨论完毕还剩几分钟，愉快地进入问答环节。末了，面试官给了很正面的评价，大致是说不太会有负面反馈，HR后续应该会安排到Seattle的onsite面试，当然他并没有把话说死。

然而，接下来的情节发展就比较坑爹了。

Amazon第二轮电面结束之时，去Menlo Park参加Facebook onsite面试用的B1签证已经搞定，但具体行程还未确定。本想如果Amazon的HR能够及时跟进后续安排的话，就一次搞定两家的onsite。然而Amazon的HR迟迟不见回复。由于是第一次出国，担心忙中出错，便决定Facebook面试完毕后立即回国，大不了Amazon的安排下来之后再跑一趟。于是跟Facebook安排的旅行社沟通，将行程定为面试后第二天回国。又过了大约一周，Amazon的HR来信说对不起，经过比较我们选择了其他的候选人云云，具体原因则完全没有提及。这么莫名其妙地挂掉实在是令人恼火，但当时对Facebook抱的期望还比较大，并没有太在意，心不在焉地回了封thank you了事。现在想来应该进一步追问一下被拒的原因的。总之，Amazon的面试官给我的感觉很好，但HR的跟进速度和质量实在无法让人满意。

3） Facebook

Facebook的面试机会同样是同学推荐获得的，这也是这次求职经历中走得最远的一次。正如Cat在他的面经中所述，Facebook的HR邮件回复非常及时，而且经常在非工作时间回复，整个过程中非常认真负责，不得不赞一下。Facebook的第一轮电话面试是由HR进行的，时间是Amazon第一轮电话面试的第二天早上，而Amazon第二轮电话面试那天，Facebook方面已经进行到委托旅行社替我安排onsite行程的阶段了，其工作效率可见一斑。

HR电话面试