Google、Facebook等美国IT名企在面试中最看重什么？-CSDN博客

来源：https://www.zhihu.com/question/372648294

编辑：深度学习与计算机视觉

声明：仅做学术分享，侵删

特指美国一线的IT公司software engineer岗，new grad cs专业在美国找工作，身边很多人都是题做出来了，但是还是没收到offer；相反有的题没做出来，反而被录了，说是交流问题等等，但是感觉大家（国人）口语应该差异也不会太大，就不知道除了刷题以外，还能做哪些准备呢？

或者需要注意的地方，看看过来人都是怎么说的。

作者：孙煜征
https://www.zhihu.com/question/39238915/answer/989343041

我工作资历不深，也没面试过多少人，本来不觉得自己有资格回答这个问题。但是刚入职Facebook的时候，我的recruiter专门找到我，说我是他们那半年面试的top performer之一，邀请我与HR部门合作写一篇介绍面试经验的文章。虽然后来一些原因没写，但我还是希望能在公司政策允许的范围内，把自己的经验尽可能分享给大家，于是就写下了这篇答案。

关于沟通的重要和可能存在的不足，

另外再补充两点。第一，是“如何解答开放式问题”，这类问题在程序员面试里相对少一些，但是在数据科学和产品面试中很多，而且随着职位越高，越重要。第二，如何系统性地分析和解答问题。

解答开放式问题

我们来mock interview一下：你是腾讯的数据科学家，你需要回答，最近微信上的文章，百分之多少是谣言？

大家不妨停下来，想一想，自己如果遇到这样的问题，会如何回答。

多数人的思路 — 寻找正确答案

很多人的第一反应是寻找“答案”，其思路是这样的：这道题有一个明显的题眼，是如何定义“谣言”。那是不是一个优秀的数据科学家，就应该最快速地找到一个最“优”的指标来定义“谣言”，并把相关数据找到、指标计算好、用通俗易懂的方式可视化出来，就可以了？如果能做到这些的话，就离满分答案不远了，面试不可能失败。于是，找到一个好的“答案”，即“谣言”的定义，就是关键了。

虽然不排除这种的可行性，但是以我个人经验，在实际工作中面对复杂问题，能一次得到满分答案的机会几乎是不存在的（如果存在早就被做掉了）。而很多时候，自以为的满分答案，反而跟真实需求南辕北辙。比如，在帮朋友的mock interview中，我听到过这些对“谣言”的定义：

1.给文章下面的留言进行文本分析，有特定“谣言”相关关键词的是谣言

2.来自不知名网站/作者的是谣言

3.用户互动（比如点赞、留言）少的是谣言

4.传播速度特别快的是谣言

5.低教育程度人群转发多的是谣言

……不知道大家有没有看到这些定义的问题：这些定义没有一个是完美的，而代表了不同的取舍。强调一遍，为什么会存在开放性问题？因为没有“正确”答案。

没有“正确”答案时的思路

理解这个前提，回去看那个聚焦在寻找“答案”的思路，就明白这个思路的问题了。最合适的答案，取决于这个问题的时间、资源、重要性、precision、recall，是会千差万别的。比如，也许用机器学习来做文本分析的方法在识别个体谣言上能达到不错的精度，但是会有很多漏网之鱼，开发起来很慢，又可能被用户abuse。如果一周内就需要一个大概的总体数字来支持一些重要商业决定，用机器学习做文本分析肯定不是一个能接受的方法。反之，如果目标是找出来确定性最高的几个谣言，时间又不是很紧张，那机器学习可能就是一个好方法。

所以，遇到这种问题，我的第一反应是，这问题的背景，和商业要求是什么？我在答案结尾也会强调，面试是对话，而不是考试。你和面试官的关系，是一起解决一个复杂问题的同事。对问题的关键参数了解越充分，越能给出最优解。主动询问问题，不但是自信的体现，也是面对复杂问题时负责任的态度。当然，问题要问在点子上，问完问题也要保持互动。

比方说，你问了面试官这问题的背景，面试官告诉你，假定这是因为小马哥接到上头的询问，要他给个汇报。那你这时候可以猜测，（1）时间不能商量，（2）资源很可能是很有弹性的，（3）对谣言的定义要尽可能符合“上头”的定义，而不是按照我们自己的想法来定义。接下来，你应该马上把这些猜测和面试官进行沟通和确认。一方面可以框定解决方案的范围与取舍，另一方面，在沟通的过程中，你也体现了很多优秀的职业素质。

系统性地分析和解答问题

MECE心法

框定问题的参数后，数据科学家就可以开始提供解决方案。这时，有效率的沟通和好的方案一样重要。很多优秀的面试者太急于提供方案，而疏于沟通，也没有展示自己思考的过程。如何沟通和展示呢？这里，我借用一个咨询公司Case Interview的思路：Mutually Exclusivie, Collectively Exhaustive (MECE)。MECE的意思是，在分解一个问题时，要相互独立，完全穷尽。MECE本身，既是分解问题的原则，也代表了一个分析问题的思路。

说句题外话，我在准备Facebook面试的时候，product sense和applied data两个环节几乎没花时间准备，而全靠现场发挥，但根据recruiter反馈，这两个环节也面得很好。事后总结，除了我平时就喜欢研究产品，喜欢从产品的角度进行思考以外，之前在管理咨询的经历功不可没。那段经历培养了我系统性地分析问题、提出针对性的解决方案的习惯，更培养了我有效沟通这些分析和方案的能力。其实上面的这种提问形式，就是case interivew。区别是管理咨询的面试里没有太多技术考量，而主要就是考察思路和沟通。所以想提高思路和沟通，去参考管理咨询的面试经验，是一条非常适合的道路。

其实，咨询公司面试最普遍准备的不是MECE，而是issue tree，也有叫framework。刚刚说了MECE是分解问题的原则，而issue tree是分解不同类型问题的套路。不过，在我看来，MECE是心法；issue tree是招数。练习时应当先掌握心法，招数是学不尽的，学会招数也只是能见招拆招而已。话题拉回到数据科学的面试，有的同学上网找很多面经，希望学到更多的招数。拿到面经的第一反应也是先找出来一个正确答案。在我看来，这本末倒置了，分析问题的思路才是更重要的。找答案，不如先领悟心法，再了解几个有代表性的招数，吃透理解了，可以举一反三，才是更有价值的。

简单理解，MECE代表了一种分析方法，我个人将其总结为，“面面俱到，重点分析”。再详细阐述一下：一个复杂问题，可以有不同侧面，每个侧面又可以被进一步分解，而对应不同的解决方案，甚至每个小问题都可以对应多种解决方案。好的咨询顾问/数据科学家/产品经理/程序员，第一步就是要能清楚地分解问题。分解之后，通过自己的经验和知识，根据二八法则，抓住其中重点的一部分去深入分析。这样，才能保证用性价比最高的方式来解决问题。

举个简单例子：比如在咨询面试里，问，这公司盈利为什么不行？那盈利可以分解为销售、成本；如果认为问题主要出于成本，又可以进一步分解为固定成本，和变动成本；这时候也可以通过跟同行对比等方法，进一步了解成本出现在哪里，从而优先解决最主要的问题。是不是有点主席矛盾论的意思？

举例

用我们之前“谣言”的例子：通过跟面试官的沟通，我们知道，短期需求是，我们需要知道谣言的百分比，用于汇报。长期需求是，我们需要降低微信上谣言的比例。这时，我们可以把问题需求分解成“总体”vs.“个体”。前者意味着只需要知道整个微信层面的平均比例就行了，而后者要对每一篇个体文章做一个判断，究竟是不是谣言。前者可以用于汇报，后者可以用于反谣言。前者，用抽样+人工标记的方法就可以得到一个大概的估计，不需要再分解下去，小马哥也可以拿着这个估计去汇报了。

后者，想判断每篇文章是不是谣言，我们可以把“谣言”的定义进一步分解，区分为“内容”和“来源”两类。解决方案也可以归类，比如人工vs.自动化；自动化可以分解为专家系统或机器学习。先把大框架列出来，再跟面试官沟通，给出自己对于不同方案复杂度、成功率、资源要求，的估计和相应的建议，和面试官选择一个方案展开进行重点探讨。到这一步，就可以穿插自己对数据和技术的理解了。比如，我们选择先解决“来源”类的定义：

根据我过往的经验，我猜想，“谣言”的“来源”很有可能遵循power law，也就是少部分网站/作者贡献了大部分的谣言。我第一步想通过现有网站数据和人工标记的“谣言“标签来验证这个猜想。如果猜想成立，那我们通过重点监督/禁止这些网站，就可以有效减少谣言的数量。

如果面试官对这个答案满意，我们就可以去解决下一个问题。如果面试官有进一步的问题，比如，“你的第一步我还是不太明白，可不可以详细阐述一下你具体的检验方法？”我们也把问题限定在了一个有限的范围，并且完全理解背景和目的，使这个问题更接近一个纯粹的技术问题，更容易回答。

当然，这个例子只是管中窥豹。想提高自己系统分析问题的能力，是需要很多练习的。在我看来，准备面试时，比较有效的方法是多做mock interview，有空还可以读读"Case Interview Secret"这本书。

积极工作是最好的面试准备

面试之前和过程中，无论recruiter还是面试官，都强调这是一个对话，而不是考试。我也是这样觉得的。在面试过程中，我始终把面试官当成我的同事，而立场从来都不是为了得到高分答案。而是带入场景，就像在工作中跟同事一起合作一样，去解决面试官的问题。

其实，积极工作，本身就是最好的面试准备。这些面试题目都是为了模拟一个场景，去了解你的工作能力和工作态度。如果平时你能在工作中积极主动地寻找解决问题的方法，也能顺利地跟你合作伙伴沟通，那把这套方法带到面试里，相信也肯定没问题的！

作者：孙老师RickSun
https://www.zhihu.com/question/39238915/answer/226484516

我曾经在google工作多年，是Google的主力面试官，面试过很多人，也帮助过很多人进FLAG（其中包括LeetCode版主）。对于怎么面试和如何准备面试，特别是顶级科技公司的面试，我想聊一聊我的经验。

面试官真正想要的，是能够独自和与团队一起为公司解决问题的人。写出了code，答对了题，并不代表你coding能力就强，即使coding已经达到了标准，也不完全代表面试官就愿意选择和你共事。

首先，并不是写出了code，做到了基本的bug free，就代表你coding能力很solid。

以下是我自己总结的比较有用的check list：

code本身：

code写的对不对，是不是做到bug free？
是不是能够处理所有可能的情况？
有没有主动walk through几个test cases？
code是不是用标准的格式来写的？
结构是不是让别人能够很清楚的看明白？

沟通code：

在写code之前，有没有主动的跟面试官沟通来明确题目要求，分析各种需要处理的情形？
有没有考虑可能的环境和多种解决方案？
有没有做必要的trade off的分析？
如果你用到了某些数据结构和算法，有没有解释清楚运用这些工具的原因到底是什么？

code优化方面：

有没有冗余的可以优化的代码？
你给的答案是否是效率比较好的？
能否主动继续分析优化方案？

其次，那种Coding能力不错，但是因为其他原因挂了的，也太多太多了，举几个典型的例子：

例子1：

面试官：The Candidate was very quiet. I need to probe him all the time. I’m worried about his communication.

例子2：

面试官：Do you have a bug here?
应试者：（想都没想）”No! No! No! I disagree with you”

例子3：

面试官：Do you have any question for me for the last minute?
应试者：You work in XXX department, right? I think there are quite a number of things that can be improved...（喷了10分钟面试官的工作）

这些不论是太安静，还是太急于证明自己，都最终导致了面试的失败。所以说，Coding能力是很重要，但只是拿Offer的必要不充分条件。

如果说FLAG面试的完整攻略，还是必须要在Hard Skill和Soft Skill两个方面都表现出色。

Hard skill方面，主要考察的就是你的专业能力，包括Coding, Testing, Basic Data Structures & Algorithms和Design。

Coding

能保证至少一门语言，不论是java还是C++还是Python，不会被面试官问倒。
能够很快将复杂的问题转化成逻辑和代码。
想到和处理可能的边界条件。
写出的代码能够符合业界对格式、易读性和结构的要求。

Testing

对于测试的要求大多为单元测试，因此要求工程师能够自己写test来验证自己代码的正确性

Basic Data Structures & Algorithms

能够深度理解各种数据结构和算法，对应选择高效的解决方案，并告诉面试官为什么

Design

Solution Design：能够从工程的角度，考虑不同的需求和环境之下，不同的解决方案的tradeoff。System Design：应该具有完整的知识体系和储备，熟悉计算机系统的基本知识，在复杂的情况下分析和解决对应的设计问题。基本知识概念包括操作系统、数据库、网络、web technology、分布式系统、多线程等等。
（虽然很多人都说New Grad不考Design，但事实上，FLAG这个级别的面试还是多少会有涉及，而且了解Design的知识，对于和面试官分析、解决问题有很大的帮助。）

Soft Skill方面，除了一个必须具备的Attitude，对于面试来说最重要的就是两个方面：Problem Solving和Communication。

Problem Solving

要能够系统地、明确地观察问题，定义问题，分析问题，分解问题，最后找到合适工具来解决问题。
还能够不断总结、优化、调整现有方案，多次迭代来找到更合适方法
（这是一个非常重要，但也很容易被忽视的方面。所有的技术能力都只是用来解决问题的工具，而不是方法。）

Communication

Technical Communication方面就是要有目的、有条理、有主次
Non-Tech Communication方面包括自我介绍、Behavior Questions、向面试者提问，以及其他所有的细节。这方面相对没有那么唯一的要求，但是自信、积极、尊重应该是一个普遍的标准。
（一样的题目，面试官可以选择给你提示也可以选择不给你提示。评分评价主观上，加减10%到20%轻轻松松。2.8和3.2一样吗？一个天上，一个地下。）

作者：邵天兰
https://www.zhihu.com/question/39238915/answer/124496043

面大公司没失过手，拿到过G家总部等offer（通通拒掉创业中。。。），这里弄个斧。

”题答出来了”也分很多种情况。思路清晰与否、表达有没有条理、对各种情况是不是考虑周全、有没有工程意识等等，其实都很重要。

此外，面试的时候一定要自信！自信！自信！具体表现出来就是敢于深究、敢于反问、敢于承认不懂让面试官现场再解释一下。给人的感觉一定要是非常active地在解决问题，而不是应付题目。

对于比较难的算法题，不要一上来就纠结于最优解。先迅速给出一个trivial的解，分析其复杂度和优化余地，再慢慢搞，会让人感觉很好。

面试官其实就是在给自己挑同事。想想如果你是团队的leader，你想要什么样的伙伴？当然是有货，有条理，而且态度积极主动，信心满满那种，把活儿交给他/她才能让你踏实。

而且面试官大部分也都刷过题，只会刷题的货几分钟就会被看穿的。面试不是按答对题目多少给分的。

作者：药不停
https://www.zhihu.com/question/39238915/answer/80561703

如果是刚毕业的话，做不做得出题目的确是最重要的因素了。但是题目做出来也没拿到offer的原因就很多了，说几个最近面的例子：

A 国人小哥：题目做得很快也很好，基本上没bug。但是小哥你多说两句话啊，听了问题以后五分钟不出声，然后开始刷刷刷地写，整个房间里鸦雀无声，这是闹哪样嘛……我问点问题想活跃一下气氛，结果还是说了没两句就开始写……最后被拒了，好几洋人面官在feedback里都写了交流困难虽然程序写得很好。面试不是online judge，能说还是多说点，尤其写白板的时候，能边写边说最好，不行的话也要写一会解释一下。

B 国人妹子：估计刷题有点走火入魔了。我问了到网上的原题，但是背景稍微改了一下。结果没几秒就说了一个很巧妙的解法。这还好，但是让她解释思路的时候直接照着原题的背景就开始说了……碰到做过的题是很让人开心，不过您能好歹装一下么，虽然我当作没看见，但是后面还是有一轮还是被人抓住这点了（是的，面试官其实都能懒，一道题连续问半年很正常）…… 如果运气好看到做过或者熟悉的题，先别着急，深呼一口气，再确认一遍题目，然后说一个直观点的想法，接着装着一步一步思考怎么提高

C 三哥（这个其实不算会做）：电面，在google doc里粘了问题，然后他说要在白纸上写一下，然后等了五分钟，pia一下就把答案粘上来了。我惊讶之余自己在google里搜了一下…………您tm能别用搜索结果第一页的答案么，连变量名都不带改的……让他用另外一种格式输出答案，妥妥地不会了

对刚毕业或者快毕业的学生来说，一般很难考察比较靠经验的内容，比如设计或者测试。但是如果只要求做对题的话，完全不用那么麻烦把人弄过来onsite，占用正式员工大半个小时，直接带到小黑屋里写题就好了。和TL聊起来的时候他说其实面试无非就是考察两点：这人能不能工作，你愿不愿意和这人工作

作者：硅谷IT胖子
https://www.zhihu.com/question/39238915/answer/394324910

最看重的是优秀的人。这句话要看怎么解读：

Google不差钱，所以工作是钱多活少离家近，梦寐以求的工作，好多时候招牛人只是养着，防止下一个Google出现就行了，所以Google来说，优秀就是够牛够强就行；

Facebook差一些，生存环境不如Google，所以优秀的人是能干活、聪明的人，反而对牛不牛没那么看重，所以招了很多年轻人；当然，因为相对累，所以FB同级别的工资并不差于Google，甚至略高一些；

面试的随机性很强。让Google、FB里面的人再面一遍，很可能就挂了。所以随机性必须考虑。除此之外，咱们挨个猜原因：

（1）招人季节。明显到招人旺季，会更容易进去；一旦快招满了，或是已经很少招了，就难，面得好也没用。这个只能靠小道消息或是运气碰。

（2）学校牌子。明显CMU等名校的bar是要比普通学校要低的，所以学校牌子不行，面试难度其实就增大了。不要不服，规矩就是这样，只能适应。

（3）公司牌子。假设有工作经验的人面试，当前工作也是被考虑的，比如亚马逊或是startup的，人就喜欢，微软之类的也马马虎虎，像FB、Google互相跳，对方更喜欢；

（4）面试题做出来了，不代表交流好。我的理解是面试不是纯做题，而是对方作为工程师，经过交流，愿不愿意跟你以后一起工作。所以要表达出自己的聪明、谦和、善于解释和沟通等方面，最后宾主皆欢为最好。这个有时候刚毕业的小年轻是很吃亏，还是考试思维那套，在职场混几年就容易理解了；

（5）系统设计也非常关键。系统设计很坑，属于难了不会会了不难的类型，一旦进公司，发现简单得要死；进不去，则很多细节一问就卡住。关键是没有正确答案，所以对求职者的基础、学习能力、应变能力甚至瞎懵的能力要求很高。

其实个人觉得，除了名校出身，或是大牛以外，大部分人毕业就面Google、Facebook通过面试的概率不是很高。也没什么大不了的，积累几年经验再面呗。年年来面，总有转运的时候。

作者：节瓜
https://www.zhihu.com/question/39238915/answer/124576596

做出来题目，但是程度有很多种：一下子就做出来，并且优化好，顺便把follow up解决掉；一开始没想出解法，但是摸到边，面试官提示一下就能做出来；经过面试官无数提示，很辛苦才做了出来，没时间做follow up,etc。以上这三种情况的好坏并不是仅仅凭有没有做出题目来区分的。

另外，和面试官的沟通也很重要，我的策略是这样的：面试官说完题目，先思考一两分钟，和面试官确认题目的具体细节（体现你思考周全）；然后尽量画图跟面试官描述你的算法，得到面试官确认后才开始写代码；写的时候可以边写边跟面试官讲解你的代码；写完之后先自己代入一些数据看看有没有bug。最后还可以说说单元测试之类的东西，讲解一下edge case。

作者：书心
https://www.zhihu.com/question/39238915/answer/388055323

关于海外经历：我有家人在海外因此初中之后基本上所有的暑假都是在美国旅游或者上夏令营。但是初中高中都是在国内上完的。口音是我自己跟着同教会的ABC一点点磨出来的。

关于diversity加分/性别/颜值：
我承认我的女性身份会让我的求职之路容易很多。男票比我智力上厉害太多然而求职路上踩的坑也比我多了太多。我平时跟男生朋友聊天也觉得有时候美国这种反向歧视很厉害。我完全同意如果一个亚裔男的和我同等水平争同一个岗位很有可能我因为性别能取胜。但我也绝不同意我是个中看不中用的diversity mascot. 我也不相信一个tech大厂会草率到因为性别录一个人。水平和实力先说话，然后才能轮到diversity的考量。

我外貌低于平均值，胖矮黑我都占，平时表情身材管理也不是很注意。从小被同学说丑，我觉得他们说的很对。谢谢评论区各位觉得我是个美女，请随意stalk我LinkedIn来刷新你们的认知（知乎id即真名）...

另外我不刷题不代表我不会算法和数据结构...大学所有数据结构和算法相关的课以及线代我都是A或A+...学校教的基础知识很多时候做题完全够用了...

这个题目只是说面试沟通，我不想掺杂太多场外因素，仅想抛砖引玉一番，这只是我应对面试的方式，不代表适用于所有人，也不代表不像我这样就低我一等或是高我一等。求职这东西，三分靠本事，七分靠临场，剩下九十分看面试官心情。

其实这个答案的重点是test-driven development process.我觉得我面试比别人强的就是这一点。给很多人mock interview过，很多我的同侪都是写完code忘记test或者没有提前想好会有什么case。这一点在美帝的tech大厂很重要。很多企业都会强调testing.

===原答FB校面三道题挂了两道
依旧收到onsite并拿到intern offer的来强答。

背景：美本某中部top20大三中国籍无绿卡今年校招季所有没刷我简历给我面试的公司无论厂大厂小都给了offer。leetcode hard题一道未刷 medium和easy题各刷了50道吧...等同没刷... 在大三找实习之前有帮一欧洲NGO做web游戏的经历（做的东西技术含量不高但concept很酷）。

感觉面试最重要的还是沟通！沟通！沟通！我由于从小有海外背景英文比较好基本是纯正的新英格兰口音（感觉是个加分项），和面试官沟通一般比较顺畅。

出题目我一般很诚实碰到自己刷过的题会老老实实告诉面试官这道题曾经见过然后告诉面试官之前是多大程度的接触过这道题（完全做过并且知道答案/做过但不确定是最优解/见过但没做过/etc.）面试官有时候会决定换题有时候就会让我把之前做过的结果跟他讲一遍。

开始做题前我觉得关键是在写答案前问足够的问题去clarify。一般一开始给的题目都会比较模棱两可有很多可以用来问问题的点。2sum这么经典的问题你都可以问问是不是sorted 用不用考虑duplicate的情况是吧...不要想着这题leetcode上有原题就做很多assumption... 我一般采取的策略是列出几个例子来跟面试官go over。例子里面一般包含一些edge cases，比如null该怎么处理之类...提前问清楚。这个问问题的过程可能够一些刷过题的大神直接把最优解写完但我真的对于这个屡试不爽每次面试官都很赞赏我的问题...

真正开始写码前先问问面试官这个解答可不可以。告诉面试官自己打算怎么做预计的time complexity是多少。如果面试官觉得这解答太渣不配写在白板上人家会告诉你的呀！会问你can you do better的呀！这个时候一般会给点hint，比如说can you solve it in O(logn) time?，这个时候脑子一下子就想到binary search了对不对！

做题中要尽量话唠每写一行code都解释一下自己是怎么写的必要的时候加inline comment。我每次都用java写因为可以提前定义type。注意如果比较复杂的解法最好用多个方程分开！比如有些tree的题需要用height变量那么就单独写一个getHeight的方程！encapsulate your codes！

写完了整个答案之后先别忙着用期待的眼神看着面试官啊喂！自己过几个test case呀！刚刚跟面试官举的那些例子派上用场了啊！把那些例子过一遍在白板上跑几遍你的code呀！然后再问面试官自己做的怎么样。顺带分析一下time和memory complexity呗...然后如果有能优化的办法但不敢写（比如我就完全不会写dp），告诉面试官也许可以这样优化啊！

如果卡住了也不要慌！告诉面试官自己在想什么哪里想不通/出现了conflict，我FB面试的时候就是有一道DP题知道怎么列DP的式子但是就是转不成code（因为base case有点混乱），告诉面试官I’m trying to figure out what would be the initial cases, coz there might be more than one scenarios as xxx（题目里的某个变量） is kind of arbitrary as far as I see.面试官说I got your point, let’s skip this and try something else then. 然后直接换题了啊！换题了啊！而且我两天后就拿到了onsite通知！找面试官要hint不丢人啊！告诉面试官卡在哪自己在想什么自己想怎么解决这个问题但为什么解决不出来就好了啊！还有一次面试我很丢人地把DFS怎么写忘记了于是就直接问面试官我知道大概是要用dfs的但我现在有点卡你介意我们回到例子里重新看一遍那个graph怎么完成recursion的吗。面试官很愉快地帮我再看了一遍并且点了一下我，一下子就做出来了！同时面试官如果对你的code发表意见一定要及时回应！及时改正！

别忘了全程要有礼貌的微笑！保持亲切非常重要！我在微软就是全程傻乐了一天跟谁都笑最后虽然题没答太好但没人挂我...稀里糊涂拿了offer...

我觉得面试就像完成并且deliver一个产品的感觉一样一开始的问题和提出解决方案是设计产品开始写代码解决是根据设计方案制作测试和解释代码就是为产品投标打call 作为一个合格的程序员当然是要对产品从头负责到尾的啦！

总之面试不是考试就是一场愉悦的聊天只有表现出自己是在很快乐的尝试solve a problem，才会让面试官觉得“啊如果能和他工作该多好啊！”

作者：北妖
https://www.zhihu.com/question/39238915/answer/332477641

三个月前跳槽的时候，刚面了一轮各大公司。自己的感觉和外界评论、朋友看法基本一致。有趣的细节很多，但真正重要的是这些公司在面试上分为两类，一种注重过程，一种强调结果。

注重过程的，以Google为代表，还包括Amazon和Microsoft。Google很多题是LeetCode medium难度，但不是原题，有时候会当场对题变形要你分析这个变化对解法的影响。在5-6轮面试当中，有一两道做不出来或者不是最优解也没关系，只要保持开放的思维，清醒的头脑，和面试官多交流。想象你们是同事，在一起解决这个问题，你的表现要让面试官觉得跟你合作能搞定问题并且很愉快。对于较难的算法题，即使最后没做出来，但试了几种合理思路，并和面试官积极讨论，也未必不能拿到strong hire。G是每轮一小时x5轮，一个较难题或者两个简单题。

注重结果的，以Facebook为代表，还包括Snapchat，Uber，Airbnb等等。以LeetCode原题为主，FB一般只到medium难度，小公司要精通hard才行。要求是必须做对，越快越好，并不需要过多的讨论或说明。Design轮也一样，每一个子问题都有一个相对标准的答案，说中了就跳下一问，说不中的时候，和面试官讨论并不加分。所以现场推导太慢或易错的题必须提前准备好，比如实现快排，带负数的最大字段和，最大回文子串，多个二进制串的总海明距离，等等。FB是每轮45分钟x6轮，每轮都有两道题，感觉和当年进高考考场差不多，身心压力都比Google大一些。

作者：斯图亚特
https://www.zhihu.com/question/39238915/answer/984809148

如果一个面试结束的时候，被面试者觉得自己没有做出来，会很尴尬。作为一个面试官，我会觉得我面试的很失败。我想很多面试官都会这么认为。所以一定要避免这种情况发生。

如何避免呢？最好的办法之一就是从一个非常简单的题目开始，如果回答得好就继续扩展。通常合格的面试者至少会被扩展过一两次的。

还有一种方法是预备面试两道题。第一题比较简单，看第一题答的程度决定第二题问什么。如果水平太差就只讨论第一题了。这种情况，如果只答对一道题就基本没戏了。

还有就是是否指出答案中的错误。是否指出或提示面试者找出错误是根据面试情况和时间决定的。如果很可能面试结束时候留了一个悬而未决的问题，那就很尴尬了。

说了这么多，想表达的意思是，有经验的面试者通常不会让你在面试结束时候感觉到你有答不出来的问题的。所以如果你觉得所有问题都答上来了，其实什么也说明不了。

作者：Chelsea
https://www.zhihu.com/question/39238915/answer/274363824

New grad 面试或者找工作的结果可以用中华民族最常用的三个因素来概括：天时地利人和。

天时：

重要的事情说三遍。找工作一定要趁早。一定要趁早。一定要趁早。我不能说这件事比个人实力更重要，但它对最终的结果有很重要的影响。我见过很多忙于学业不专心找工作，或者说不先下手为强的明明有实力的朋友，最后栽到了headcount满了，走都不到面试那一步。

或者我们可以这么理解。cs行业特别是software engineer岗的不可替代性不强，大家刷一刷题以后在面试上的表现都差不太多。学4年的人有着精湛的编程功底，但是这种优势在以算法为基础的面试上发挥不太出来，也就是看起来跟那些学了一年刷了一年题的人区别不是那么大。所以先占坑就显得尤为重要了。

地利：

这个不用我多说了。硅谷附近的学校们的面试机会比村里大学的面试机会明显多，毕竟公司不用承担onsite的往返机票酒店住宿等等的费用。Apple一半员工都是圣何塞州立大学这种说法虽然有夸张成分，但也可以看出地理位置的重要性了。

人和：

这一点是最重要的一点了，即面试的个人发挥。个人曾在转行cs半年多后拿下谷歌的实习，并且在conversion成功，拿到了Google SDE的offer。在面试谷歌实习的时候我只刷过40道leetcode，conversion面试的时候刷过将近200道。这个过程中多少是有一点运气的成分的，但还是来谈谈我的经验。

首先，面试内容以Google为例，new grad的面试主要是算法和数据结构。面试的list里面提到了mathematics和system design，但我迄今没有听说过明确对new grad考察这些的。并且算法的概率明显大于数据结构。所以从面试内容来看，刷题基本可以满足需求。

有一个题外话，很多人好奇为什么“码农”的工作性质跟算法并无太大关联，但面试（特别是大公司）却非常注重算法。原因很简单，公司不仅想招能完成工作的人，更想招“聪明”的人。通过算法来检验一个人的聪明程度，可能是大公司们探索若干年得到的性价比最高的方法。虽然这种方法在如今各种刷题网站的轰击下，已经显得不太可靠了。

尽管Google/Facebook等公司一般都很政治正确，扬言说不在意是否做出来题目了，更在意解题过程和你的思维，但我还是认为在大多数情况下"做出来没聊好"强于“表达好没做出来”，毕竟华人相对来说交流不如local。“做出来”最好是写出了可执行的代码，其次假如时间不足，阐述清楚思路和计划如何解题也可勉强算“做出来”。在面试过程中有如下注意的事项：

1.解题和优化。面试的题目一般不难做出来，大不了写个exponential的做法。但是算法优化显得很重要，也就是不仅要做对，更要控制算法的time complexity和space complexity。一个优雅的算法无疑是“聪明”的体现。另外，对于一些简单的算法问题，不要大意，要注意解题是否快速且正确，corner case是否考虑完整。比如同样一个简单问题，你用了10分钟解答，当天的其他interviewee只用了5分钟，那么高下立判。

2.Coding style。简单表现为变量名的定义，类与函数的使用，注释，逻辑是否简洁无重复等。

3.Communication。有价值的交流很重要，不是说漫天乱聊唠嗑式的交流。个人认为交流的作用有两点。第一，帮助面试官快速了解你的思路，成功表达自己的思想，不要让任何一点自己想法的可贵之处埋没。我曾遇到过一个hard的面试题目，想不出彻底的解法，就把自己能想到的思路和相关的困惑都说了一遍，然后面试官表达这个思路是正确的并且解答了我的困惑，于是我们顺利进行。第二，假如遇到了卡壳，可以尽快从面试官的反馈（语气、神态、建议等）中发现解题的方向。不要把面试官当成上司，就把他当作跟你一起解题的人。

作者：神奈川
https://www.zhihu.com/question/39238915/answer/80581108

New Grad, Facebook / Google 都拿到过面试和offer。

我觉得三点最看重：

1. 分析沟通问题的能力。这项我觉得是最重要，也最受英语口语能力影响。Facebook和Google给我的面试问题有难有简，但无论简单与否，面试官都要求我想到什么说什么(think out loud)。基本上每次面试都是从头说到尾（写代码的时候也是边写边说）。我在Google面试中有个问题跟本没想到解法，一半胡扯一半问问题地做完面试，结果面试官最后很开心，说，“虽然没有完成，不过你中途一直说话，很欣赏你如何分析一个不熟悉的问题，并一步一步接近解法”。个人认为美国公司很看重这点。我认识些同学大量刷题也没有过面试，很大一部分原因是上来就写代码，面试官看不到分析问题的过程。（不信你给你朋友面试一个，他要是啥都不说光把题做出来，估计你也看得挺无聊的。。。）多跟朋友们练习面试最有帮助。

2. 编写代码的熟练度。把想法转换成代码的能力。想到解法之后写出来的代码是否整洁，变量名是否合理，是否bug-free，是不是有合适的abstraction，都是写代码熟练度的表现。同样一个最优解法，每个人写出来的都可能会有细微差别，用loop还是recurse，用static还是dynamic memory，哪些逻辑写成helper function，都能给体现出他是否真的能熟练地写代码。这点上刷题很有帮助。

3. 对公司和科技的热情。这是个软能力，但是一个很大的加分项。如果能和面试官聊聊一个公司最新的动态，那是最好不过的。比如我在面Facebook的时候他们刚拆分Messenger不久，就兴致勃勃地跟面试官聊了不少这个决定的原因和影响。多看看科技新闻很有帮助。

作者：匿名用户
https://www.zhihu.com/question/39238915/answer/80675604

我2014年春季快毕业时，作为new grad面过Google，no offer. 面试后，recruiter打电话和我说很遗憾，我很接近，但没到录取线。我当时的准备状况是刷完leetcode，看完cracking the code interview第四版。面试全程五轮中，有一轮很不好，其他几轮都顺利。
毕业后我进了湾区的一家互联网公司。过了一段时间我做了电话面试官。

2015年春季被Google recruiter再次联系，我拖到秋季又面了一次。一共也是五轮，都很简单。就过了。当时的准备状况是刷完了leetcode（多了很多新题），以及很简略的浏览了cracking的第五版（多了一章，换了一些题）。面试的感想是因为我自己有了工作，心态就比较放松；以及我也做了面试官，我对面试官的心理也有体验，面试时比较注重互动：确定他们听懂了我在干什么再move on，否则很可能是在浪费时间。而面试的时间非常宝贵。

最后我想说作为有过失败的面试经历者，要明白FLG这样的公司面试有很高的false negative rate(你是合格的，却面试被拒），所以失败了主要是运气不好。Let's move on. 另外课余时间除了刷题，也要学点儿真正有用的东西（个人认为刷题对实际工作帮助不大）。

作者：deadbeef
https://www.zhihu.com/question/39238915/answer/985602394

交流问题很重要。我记得我面某公司的时候，我的嘴是一直没停的，整个过程的感觉就像是和面试官一同去解决难题一样。我记得第一个电面是一个和服务器有关的算法，具体问题细节不能透露，但是差不多这样的过程：

面试官粘贴问题文档里
我当场懵逼，根本没看懂这个题是要我做什么，花了几分钟问清楚具体要做啥
搞清楚之后，立马想出来了一个用 Heap 的解
- JS 没有 Heap，我问了面试官可不可以假设已经有了 Heap 这个类（面试官说 OK）
- 边写边交流，让面试官清楚我的思路
- 写完之后主动分析复杂度，发觉这个解有一个函数用 Heap 的话很慢
接着提出用 Hash Map + Heap 的解
- 写完之后分析复杂度，好像没啥问题
- 告诉面试官，我觉得这已经是最优解了
- 面试官提醒我：你这个程序运行了一段时间后会死机
- 我发现我忘记 delete 用过的 key 了，赶紧修复
面试官说他也觉得这个解很不错了，测试一下吧
- 手动跑了几个 case，确认没问题
之后问了我 Hash Map 的时间复杂度是什么，为什么会更快？
- 我说复杂度是 O(N)，面试官还懵逼了一段时间 2333
- 赶紧解释平均 O(1)
电面完成，整个过程不到 30 分钟，还有 15 分钟问问题