2. Phone Interview (1~2 sessions)

3. Onsite Interview (4~5 sessions，1 week to receive feedback)

4. Hiring Committee Review

5. Offer Review

6. Offer Delivery (Yippee!)

我一共经历了 1 轮电话面试，5 轮 onsite，如果算上前面的HR 的预筛选的话，就是 7 轮。

面试刷题

刷题是必须的，不管你在哪个行业，在这个能体现自己实力的方式，就是考试，分数越高越厉害，中国的教育体系就是如此。所以说要想分数高必须，多看书，多搜集资料，多做题目。特别是程序员，这是一个有门槛的行业，对技术这块更看重，技术越高待遇越好。下面这些面试问题就是我凭经验，整理搜集的一些面试官最喜欢问的问题，和核心资料。

需要的朋友**私信我【面试】**我愿意分享给大家，但是务必好好珍惜，一定要利用起来。

直接点击即可领取
Android学习PDF+架构视频+面试文档+源码笔记

如果你有其他需要的话，也可以在 GitHub 上查看，下面的资料也会陆续上传到Github

简历投递

之前校招其实也参加过，无奈门槛太高，竞争压力太大，连面试流程都木有进。当初校招时直接网上刷题，这个网站上其实还能看到往年的一些题目情况: Google Code Jam。基本上分几轮，每轮 top xx 的选手才有机会进入面试。

第一次换工作的时候，其实也有找在 Google 的同学内推，填了不少内推推荐理由呀等等，最后简历都没过。

当然，简历没过肯定也有多种理由啦，这个其实跟各个公司都一样。比如人家需求是招聘 P7，以你的工作年限经验等最多就 P6，肯定不行; 还有比如希望是招聘机器学习等相关经验的等等，岗位信息等不匹配也不行; 当然还有一种，岗位描述等都相关，确实简历没啥亮点，太平庸，也直接被 HR 给筛选掉了。

这次其实刚开始是没有考虑过面 Google 的，机缘巧合在 linkedin 在有 Google 的 HR 联系，说要不要试试 Google 的机会。当然就抱着 “试试就试试” 的想法跟进面试流程啦。既然要尝试，当然还是需要认真对待，修改简历。

防止手生，肯定需要提前准备”刷题”的。发简历给HR 小姐姐后，HR 小姐姐会给你一些准备材料供你参考，这份材料还相对比较丰富，直接会告诉你面试涉及到的知识点，推荐书籍还有一些推荐参考的视频等。需要的小伙伴可以留言，我整理下发给你(跟 HR 求证过，这些资料是可以公开分享的哈)。

其实，时间有限，“刷题”准备不够，当初预感估计面试面不下来。不过真正走完所有面试流程，发现其实面试题目没有想象中的那么难(然而，我仍然没有过，说明实力不足呀)，积极准备，还是有希望的。因为面试题目比较敏感，不能直接分享原题哈，不过我会根据我的理解，找类似知识点和类似难度的题目分享一下。

HR 面试

对，第一轮就是 HR 面试，上面流程中的 “Recruiter Prescreen”，其实就是一些计算机相关基础的填空题和选择题。几分钟的时间，十几道题目。面试过程中，不需要给予明确的解释，知道就是知道，不知道就不知道。题目可能会涉及到比如: 快排的时间复杂度是多少? 选择排序是稳定的排序算法吗? 等等之类的。

这也是我参与的所有面试当中，HR 直接参与的”技术”面试。我理解就通过这一轮面试可以用比较少的成本把一些不合适的候选人直接排除了。当然这种方法可能不一定适用于所有公司。

电话面试

电话面试要求直接用 Google doc 共享写代码，需要要求你有一个稳定的网络环境。这轮面试我理解应该不会太难，从我面试的经验来看也确实如此。

相比 onsite，电话面试不能在一个很好的沟通环境下，不能面对面和面试官进行交流。当初我面试的一道题目和二叉树的遍历相关，当然题目不会是直接写二叉树的先序/中序/后序/层次之类的遍历，会有一个具体的业务场景在里边。

需要你分析这个具体的业务场景，能够抽象出题目本质上就是 二叉树的遍历方法。这道题目算是拿下了。实际 coding 后，面试官可能会根据你写的 code 去提问，一些边界条件以及让你提优化方案。

HR 小姐姐介绍的电话面试是 1-2 轮，其实我理解，这应该是需要看第一轮的面试官的反馈，是否犹豫是否再安排一轮电话面试。毕竟和 onsite 相比，电话面试成本相对更低一些。

在线 code 其实在面试过程中，还是蛮重要的环节。从你 code 的细节，包括 code style，边界条件的判断，哪怕是注释情况，都能看出一些编程习惯。我认为这个环节对于招聘一个写代码的工程师来说，肯定是一个必不可少的环节(google 整个就搞了五六轮)。

现场面试

电话面试通过后，HR 会很快跟你反馈沟通面试结果，是否通过，以及 onsite 的安排。因为现场面试是 4-5 轮，平均1 轮一小时的话，需要 4-5 个小时，其实还是蛮耗费精力的。

一般会沟通可以约 2 个半天或者 1 整天，两个半天的好处是，时间不会那么紧张，前两轮后，中途可以过几天再休整调整下再继续。我当初就选择”快刀斩乱麻/早死早超生” 的方案直接约了 1 天时间搞定。

onsite 也基本上是在电脑上 coding。你和面试官一人一个笔记本，coding时共享屏幕，有时候题目面试官会在白板上写出。onsite 的题目，明显就要比电话面试的题目难度高一些呢。但实际上比我想象中的要简单些。

因为曾经想 Google 这样的公司面试恐怕连理解题目意思都要理解大半天吧。可能也是社招的缘故，社招整体感觉在算法的要求比
校招就要低一些。这只是我的主观感受啦。(确实自己在当面试官的过程中，在算法这块对社招的同学预期也会低一些)

我记得其中有一道题目就跟 leetcode 上的类似(再次声明不是原题，也不 share 原题)，leetcode 上那个题目应该是二维矩阵，最短路径相关的。用 dp 可以解决。只不过，一般题目会分为好几个小问题，难度一般从易到难。

同时也考察到了二叉树，仍然围绕着二叉树的遍历进行。需要熟知二叉树的各种遍历方式，非递归的方法(递归比较容易，一般不会让写这个)。在遇到二叉树相关问题的时候，是否可以联想到二叉树的遍历上来。

另外有一道系统设计的问题，“知识图谱”的概念，围绕着”图”的相关算法，这个要求在白板上写出设计方案和伪代码。同时面试官会不断 push 你让你提出更优的解决方案。有足够多的计算资源，并行去跑，以及具体怎么实现。这道题目我回答的不好(当初也知道不好，后面 HR 反馈也印证了这一点)。

还有一道题目，是解决生活中的场景题目。需要你抽象出这个问题，用代码来解决。一般这种题目，就需要反复跟面试官去沟通和确认其中的场景，怎样把业务抽象成算法。记得之前面试 Amazon 的时候也有类似的题目(只不过当初面 Amazon 考察的是 OO Design，而本题是具体算法实现)。

怎样把业务抽象成算法。记得之前面试 Amazon 的时候也有类似的题目(只不过当初面 Amazon 考察的是 OO Design，而本题是具体算法实现)。