本人在互联网公司工作多年，面试更是成为工作中不可或缺的一环。包括：校招面试、社招面试，也会帮助老板进行一些跨专业领域面试，如：面测试总监、运维总监、资深DBA专家等，综合算起来，过往的职业生涯不会少于3000场面试。下面来聊一下，最多场景下，我为了组建研发团队而进行的社招面试。
自我介绍
开场白。凭心而论，作为终面，除非特别重要的面试，否则我一般不会在面试前详细查看候选人的简历，那么，当我抛出第一个问题：“请您做个简单的自我介绍”的同时，我会一边听候选人的自我介绍，一边迅速地把候选人的简历从头到尾地过一遍，这个时间大约是1—2分钟之间。一般来说，这个环节是候选人准备最充分的一个环节，被演变为扣分项的可能性并不会太大。
除非，对，除非。
1、回忆录型。我面试过一个07年毕业的候选人，他在自我介绍的时候，从他刚毕业时，最早期的用JBuilder IDE，SSH（Spring + Struts +Hibernate）的项目开始介绍起，事无巨细，毫无死角地介绍了12个项目，时间已经过去了15分钟，时间轴也只不过从07年到了12年，如果按照这个节奏，让他走完这个流程，至少需要40分钟。。。我只好打断他说：“这样，您还是从技术角度，介绍一个做得比较好的，最近的项目吧”
这样的候选人，在我的内心中，已经把他pass了，原因有二：
① 极大概率，该候选人在入职后的工作中，没有时间统筹概念，不懂得在做一件事情上需要花多少时间，花多少精力，且工作效率也不会敏捷。
② 阴谋论一点儿，因为面试官的一场面试时间是有个区间的，那么过长的自我介绍时间，会极大地挤压后续的问答时间，减少问题不会而被问住的几率，增加通过率。
2、孔雀开屏型。在自我介绍过程中，带着批判的语气，不断地说以前的架构怎么不合理，维护的代码怎么差，技术栈怎么老旧，同事的解决问题能力怎么不堪，领导怎么不作为，如果不是他及时出现，力挽狂澜地解决了问题，那么后果将是一场灾难。但是，有些鸟是不适合关在笼子里的，因为它的羽毛太美丽了，所以他才出来面试看机会。
其实，更多情况下，我只是想招一些技术基本功扎实，有些潜力，态度良好的团队型候选人，要是还有几许好奇心，几多上进心，若干自驱力，那就更好了，我真的没打算招一个孤胆英雄，更不想招一个与站在群众对立面的孤胆英雄。在和平年代，他应该出现在小说或者电影里。
我所欣赏的方式是，先说一下毕业院校，较为久远的工作经历，简单地阐述一下在里面负责什么，带了多少人，近期的两份工作经历，略着重介绍下工作职责，项目经历，晋升经历以及离职动机，整个过程客观务实，不要超过两分钟，给人以一种直接干练的感觉。
项目经历
一般情况下，我的第二个问题是，请您从技术角度，说一个做得最好的项目。这是个对候选人非常友好的问题，这相当于，把面试官放在了候选人的“主场”。只要候选人在这个项目中，真的用心思考了，哪怕是用心包装了，都能把这个问题回答得非常好。当然，接下来我会继续随着他的回答，往下深挖技术点，一直挖到候选人回答不出来，或者我问不出来为止。甚至，有些聪明的候选人，甚至在某些地方留一些“钩子”，故意去吸引面试官问他，不仅可以完美地回答上问题，甚至有些经验尚浅的面试官，可以一直让候选人带着节奏走。
也说一下这个环节我遇到的bad case。
场景一
答：“我在这个项目里面，被安排做了一些打杂的事情，没有机会接触到技术核心点。”
问：“那这个项目你也做了两年了，你也没有好奇心去了解一下里面的技术核心点是怎么实现的吗？”
答：“没有，主要是没有时间。”
场景二
答：“我所做的项目都太简单了，这也是我想换工作的一个原因。”
问：“那你的项目出过故障吗？”
答：“出过，不可能不出故障啊。”
问：“那你想过，以后遇到类似的故障，应该如何规避吗？”
答：“没有。。。”
问：“当前的项目，如果忽然一下子qps爆增了一百倍，你会如何应对？”
答：“不知道。。。”
场景三
答：“我们的X项目是为了实现xxxx，这个项目对于系统可用性的要求极高，所以我们当时结合状态机进⾏⽆损流量的平滑重启，多重保活、流量防御、兜底直连、类Eureka⾃我保护、多级缓存、多维灰度等⽅式来进⾏可⽤性保障，线上可⽤性6个9”
问：“系统可用性6个9，全年故障时间不超过5分钟，能说下你们全年出过几个故障吗？每个故障都是多久恢复的吗？”
答：“只出了一个故障，确实在5分钟内就恢复了”\
问：“能说下，当发生故障的时候，你们多久发现的问题，怎么发现的问题，多久定位的问题，通过什么方式定位的问题？然后又是多久解决的问题吗？如何解决的？你们的SOP预案是怎么制定的？”
答：“时间太久，有点忘了，好像我们当时整个集群挂了，然后重启了一下，就好了”
问：“重启之后，问题再也没有复现吗？到底是什么原因导致的整个集群挂了？”
答：“不知道。。。”
前两种场景，我只想说，你就算出门见个朋友，不是还得洗个澡，换个干净的衣服不是吗？你们出来面试，真的不带一点儿准备的吗？我完全能理解，能接触核心项目的，毕竟是少数，但是，就算是为了面试，你也得去了解一下啊，难道这是完全靠天吃饭吗？实话实说，我并不排斥面试之前充分准备的同学，因为准备的本身也是一种学习。\
第三种场景的话，确实用心准备了，但是，当你的能力不足以cover你的夸张程度的时候，还是应该收敛一些的，不然会给面试官一种华而不实感。这个度还是应该把握的。
技术擅长点
候选人的简历中，总有一个非常醒目的地方，里面是候选人的技术擅长点。
我曾经面试过一个候选人，简历上写着：
- 熟悉常见的设计模式，如Factory，Singleton，Builder、Observer等
- 熟悉 Redis 的五大数据类型，事务控制，持久化 RDB 和 AOF，主从复制，哨兵机制、集群的使用以及哨兵，集群原理，对其底层协议有一定了解。
然后我问了几个问题
问：“能说下简单工厂、抽象工厂和工厂方法模式的区别吗？”
答：“我只知道，它们都是创建对象用的。”
问：“能说下RDB的默认持久化配置吗？从中能体现出什么设计思想？”
答：“不知道，我只知道在redis.conf”里面配置的，我们一般都是用默认的。”
问：“redis RDB内部是如何实现的？在RDB期间，如果有写数据请求进来，redis是如何处理的？”
答：“不知道。”
问到这个时候，我原本在心里已经把候选人pass了，但从后面的面试过程中，我发现候选人对于Java基础，以及JVM、MySQL InnoDB、ES的掌握还是不错的，真的险些因为之前的误判，把候选人错过。
在这里，我需要提醒大家的是，擅长点在精不在多。不熟悉的技术点，千万不要往上写，不熟悉的技术点，千万不要往上写，不熟悉的技术点，千万不要往上写，重要的事情说三遍。
还有一点就是，技术擅长点，不要写过太久的技术。我在筛选简历的时候，经常会把简历中写着精通Struts、Hibernate、EJB、SVN、JSP、JavaBean、JDK1.5及以下等技术点的候选人pass。因为我觉得，这些候选人的新技术敏感度存在非常大的问题，已经落后了一个时代。
这期先写这么多吧，希望能对大家有所帮助。
