兄弟姐妹们，我终于上岸了，喜获蚂蚁offer，定级p7，万字长文带你走完面试全过程

前言

在今天，我收到了蚂蚁金服A级的实习录用offer。

从开始面试到拿到口头offer（四面技术+一面HR）战线大约拉了半个月，

从拿到口头offer到收到正式录用邮件大概又是半个月。

思前想后，决定还是做一个整理与总结。

一方面是回顾并记录自己的努力过程，

一方面也是希望对后来者起到一些帮助。

前方高能预警，本篇文章万字有余，通读可能要很久。

目录

如何进行知识积累

如何把握实践与理论的天平

我应该如何整理笔记

怎么复习才不会忘

面试前

怎么写出让人眼前一亮的简历

如何突击面试

面试前焦虑该怎么办

面试开始

自我介绍到底要怎么说

面试中

技术面试的时候应该注意些什么

面试尬场怎么办

如何学会埋坑

面试结束

面试官：“你有什么想问我的吗”，该说什么？

我怎样才能知道我是否通过了

我两年半的技术人生

如何进行知识积累

在讲面试技巧之前，显然知识积累是不可或缺的。不然即使面试侥幸通过，在之后的工作中也会体验极差。

如何把握实践与理论的天平

实践是什么？

比如你new Object()初始化了一个对象来使用；

比如你用HashMap结构作为容器存储了一些数据；

比如你拿SpringBoot搭建了一个web网站后台；

比如……

理论是什么？

初始化对象有什么代价？背后的底层实现逻辑是怎么样的？初始化太多对象可能导致什么问题？为什么我经常初始化对象，明明是空间消耗大，反而导致程序在运行时间上变得缓慢？

HashMap适合什么场景？我现在这个场景真的是用HashMap最合适吗？运用的时候有没有什么需要注意的？有时候遇到一些特殊需求，在HashMap基础上可以再优化性能吗？

天天用SpringBoot，IOC、AOP到底是什么概念，背后怎么实现的？它们适用场景如何，我的用法是最佳实践吗？会不会有什么弊端，导致在生产环境出现问题？

……

实践与理论的学习，到底应该侧重实践一些呢，还是侧重理论一些呢？

都说实践与理论要两相结合，缺一不可，在我看来这是一句废话。重点是如何权衡两者，并且在不同的发展阶段，两者的侧重比例是否又要发生变化呢？

在我看来，实践决定方向，理论填补细节。

（1）首先要实践，然后填补理论

程序员首先要实践，才能够收获基本的技术视野和处理问题的能力，这两者都是不可或缺的。

有了基本的视野之后，就可以根据自己学习的方向，去填补你的细节，例如：

• 我学习了Java，会写一些应用程序了，也知道如何利用应用服务层的Java来对数据库层的数据做一些处理，那么接下来： 1. 对数据怎么处理会更快（这里可能就会引出多线程，然后就可能引出线程池，又引出JDK提供的线程池有什么并发问题，怎么解决，然后可能又引入并发包，一下子串出好多） 2. 各种优化（比如初始化太多对象导致频繁GC，全局变量太多导致占存一直很高blabla）

• 我学习了MySQL，会用SQL语句操作数据了，知道建索引可以加快访问速度了，那么接下来： 1. 在SQL语句上是不是也可以做一些优化来提升性能（比如很有名的延迟关联） 2. 索引到底应该怎么建才好（这就涉及到索引的很多知识，比如B+树，比如一些匹配原则例如最左适配原则等等）

这种细节的填补是有逻辑性的，从我上面举的两个例子就可以看得出来。这种逻辑性的存在会使你在学习的过程中不会感到虚浮，会发现这些理论都是切实有用且有价值的。

但这样的理论学习还不够，因为它不系统。充分的发散思维使你能够在实践之外追求到很多理论知识，但那些你发散不到的部分就接触不到了。这个时候你就需要系统性的学习，例如读书。

当你第一次学会实践，就好像在自己的脑海中制作了一个知识星球。它里面几乎是空白的，但是球体本身存在，帮助你去界定、区分知识——借助这个球体的框架，当你在遇到一个新知识的时候，你会它有一个模糊的概念：这个知识到底是有用知识还是无用知识，它又在哪个范畴或层面里？

所以借助了一开始的实践，然后你再去逻辑地发散、或者系统地读书的时候， 就不会让新知识成为无根之萍，而是切实地进入你的知识星球中，成为你知识架构的一部分。

（2）理论再返回到实践中

知识架构建立起来了，但它没有经历实践的检验，就依然是不可用的。

一方面在于我们学习的理论知识可能是过时的，甚至是谬误的；另一方面我们可能以为自己懂了但其实没懂，这一点相信大家都能理解。

那么如何实践呢？有些理论可能是很难实践出来的，但是至少我们要对能实践的一部分去做一下尝试。就比如简单的JVM排查和调优，通过MySQL EXPLAIN去检查执行计划并实践优化等等。

我应该如何整理笔记

首先要强调笔记是很重要的。至少我认识的那些能够面试进大厂的同学，每个人都会为自己做笔记。

而至于到底应该如何整理笔记，我认为最重要的有两点：一是分门别类，二是控制粒度。

（1）分门别类

我们一定要能够清晰地把我们要整理的知识模块化，比如说JVM基础，我们可以这样分模块：

运行时数据区

垃圾回收

类加载

JMM

JVM调优

然后分别根据每一个小模块，单独整理一篇笔记。

并且在篇末，或者另开一篇笔记，专门记录针对这个模块的比较大而广的问题。

例如运行时数据区，我们就可以记录这样一些问题：

讲讲JVM运行时数据区的各个组成，是什么，有什么用

讲讲对象。它是如何创建的，里面包含一些什么信息，如何定位到对象

记录这种大的问题，有助于我们进行自测。不要问自己太多细小的问题，除非你切实觉得它很重要。

什么叫细小的问题呢？比如：类里静态的基本数据类型存在方法区还是堆里？

这种问题枚举你是枚举不完的，它其实已经包含在了”讲讲JVM运行时数据区的各个组成，是什么，有什么用“这个问题里。

（2）控制粒度

什么叫控制粒度？其实就是控制你笔记记录的详细程度。

如果你笔记中对于知识点的描述非常简洁，带来的好处是阅读起来就会很快，坏处是可能在阅读时导致你忽略掉一些本不该忽略的细节，或者甚至是：”咦，我这记的是啥，我怎么看不懂了。“

那如果记得太详细呢？很显然，就会导致阅读起来非常繁琐，可能达不到一个理想的迅速复习的效果。

那到底应该控制在一个什么程度上呢？