面试一般几轮

很多大企业在招聘时都会采用多轮面试的方式，但如今却被众多中小企业学来，在不理解多轮面试的用意之下，任意运用，闹出了很多笑话，也受了很多吐槽。

现在企业的求职面试，基本上是没有哪家公司只进行一轮面试就决定录用的，至少也需要两轮，正常的有三、四轮面试，多的甚至可能会有七、八轮之多，比如我当初刚跳槽到南京去工作的时候，就被面试了五轮。正常来讲，level越高，面试的次数也就越多。公司越大，面试过程就越长。参加第一轮面试的大公司的面试官通常没有决策权的，只能检查某些特定领域的求职者，还需要更高级别的领导才能检查和决策，面试的次数越多，对候选人的调查就越全面，可以相对减少了浪费的人事管理成本。

那么这时候，我们很多人就会忍不住想问，搞这么多轮面试，真的有必要吗？每一轮面试又是分别考察候选人的什么能力呢？

其实，不管我们面临什么样形式的问题，但是回到本质上，无论面试形式如何变化或者面试问题如何不同，他们实际上都是在寻找候选人和职位的合适性如何，因为多轮面试会有不同的人参与，而不同岗位、不同级别的人，他们会受到职位、个人意见等特征的影响，会出现信息鸿沟，因此，看候选人的观点是不同的，并且将以不同的维度来检查候选人，这就是企业安排多次面试的原因。当然，在实际的 *** 作中，很多企业都会尽量在同一天多安排几轮面试，这样可以使候选人少跑几趟，避免了重复多次的舟车劳顿。

根据某招聘机构的调研，有20%的求职者倒在了第一面，有23%的求职者倒在了第二面，而有25%的求职者倒在了终面，但是有也40%的求职者的面试没有失败过。我们先解读一下这个数据，倒在一面/二面/终面的人数是逐渐递增的，但是也相差不大，40%的用户说面试从来没有失败过，很可能只是面试的太少了。

最正常的一种情况是，公司招聘流程比较复杂，一面由HR完成（也有些企业的HR面是放在最后一轮的），二面由主管完成，三面及以上面试由更高级别的领导完成，而主管和更高级别领导的时间不定，可能当天没有时间，HR面试完之后，如果感觉比较合适，会和候选人再约下次面试的时间。另一种情况则是，你通过前面几轮的面试，已经获得面试官们的初步认可，当这个岗位所有的候选人都通过前几轮面试筛选过后，你将要和剩下的那些候选人进行再一轮的竞争，虽然这时候剩下的人要少一点，但是相对间的能力都是差不多的，因此越往后的面试难度相对也会更大。

从表面上来看，多轮面试需要公司花费更多的时间和精力，并且招聘成本也会有所增加。对于找工作的候选人来说，这样做会更加累人，尤其是对于那些生气而又不知道该把气撒在哪里的最后一批候选人们。那为什么很多企业仍然会喜欢这种方式呢？漫长的面试过程，给候选人的体验极差，那企业的想法是什么呢？我们来分别了解一下。

对于第一轮面试，主要考察一些硬性指标，其中包括你的专业度、团队匹配度，你的能力是否可以触碰到企业的“痛点”。这轮面试一般是由HR来做主要面试筛选，或者是HR和用人部门代表一起面试。这时候需要你着重表现出你的求职态度以及对自我定位的清晰度，只有你对自己的定位有足够的明确，才能在面试的时候去展现你与企业、与岗位的匹配度。比如程序员的面试，第一轮面试会问一些基础知识，比如ArrayList和HashMap的区别是什么？HashMap如何解决hash冲突？有几大类hash冲突的解决方式？再比如，红黑树的特点？TreeSet说一下？应用场景？比如你了解的LaJi回收算法都有哪些？引用计数和可达性分析区别？等等。

而对于第二轮面试和终面，多半都是高级别的面试官，他们考核的是软性指标，比如情商、稳定性、人格，以及洽谈敲定一些实质性的内容，在二轮面试时，还会涉及到更多的专业内容，比如程序员的面试，二面基本就是问一些偏框架和中间件的知识，以及对项目的深挖，比如讲一下Spring IoC AOP，AOP的原理？项目哪里用了？MyBatis？Dao 接口的工作原理？谈谈你认知中的Redis？RDB、AOF？在项目里怎么用的Redis，谈到自己实现了一个异步事件处理框架，等等。这些都是对项目在进行深挖的过程。

我们还拿程序员来举例，到了第三轮面试的时候，强度会有明显的提升，主要涉及多线程、JVM和分布式架构等方面，比如说对Java内存模型的理解，以及其在并发中的应用；OOM错误，stackoverflow错误，permgen space错误；g1和cms的区别，吞吐量优先和响应优先的LaJi收集器选择；如何做一个分布式锁；等等。

那么到了第四轮面试，就会根据前面提到的各个项目提出候选人的漏洞，然后让候选人解决，面试官也会自己设定场景，让候选人给出解决方案。

所以说，企业每一轮面试它都有一定的目的和考察点，并不是和候选人瞎聊的。但是我们需要注意的是，这个是要根据企业的规模和真正需求来决定的，并不是说所有的企业都需要用多轮面试的方式进行面试的。小公司因为各层级之间的信息是比较透明的，所需要的轮次会少一点，一般两轮即可，一轮HR面，一轮业务主管面或者企业领导面，而且小公司一般没有很严格的人事管理体系，很少会出现卡人员预算的情况，所以，面试轮次没有必要很多。而公司越大，则面试流程就可能越长，大公司参与第一轮面试的面试官，往往是没有决定权的，只能在某些特定的领域来考察候选人，后面还需要更高层级的领导来把关做决定，面试轮数越多，对候选人的考察会更全面，人事管理成本浪费的情况对企业而言，就会相对减轻，比如上面举的例子，那就是大公司应聘程序员的流程，小公司是不会面试到这个深度的。那对于今天这个话题案例中的企业呢，很显然，这只是一个400来人的小型销售公司，其规模显然并不大，企业层级也不会太多，业务流程和架构设计也不会那么复杂，因此是没有必要像大公司那样搞那么多轮的面试的。

所以，至于到底需要几轮面试，每个公司的情况是不一样的，我们不能一刀切地下结论说好还是不好。当然，在今天这个激烈竞争的时代，对于人才，企业已经不是在招人了，而是在抢人了，因此我们在实际 *** 作时，一定要注意尽量压缩面试的轮次，即使是多轮面试，也要尽量安排在同一天进行，利用好STAR法、剥洋葱法等面试方法来提高面试效率。

相信大家在参加一些企业面试的时候应该发现了，有时候我们会遇到一些不容易回答的问题，下面我们就一起来了解一下在遇到这些情况之下我们应该怎么办。

1、坦诚相对，说明你的擅长点，让面试官给次机会

我遇到过个别候选人，他技术点知道一点，并非什么都不知道，属于可上可下的。比如项目是要SSM框架，但他在这方面只有学习经验，没商用项目经验，但他JDK，数据库可以，他就直说，SSM不行，但亮出他的长处，比如举例说明他学习能力很强，或者很能吃苦，沟通能力可以，然后表达出强烈想入职的愿望，我一般都会给出“技术可以(或技术勉强可以)，能参加后继面试”的评语。

大家在面试的时候，回答问题好坏自己能估计出来，如果太差，属于一问三不知的，即使说这种话也没用，但如果你感觉回答的时候并非一无是处，就可以找机会说出这种话。

2、通过展示你以前的亮点，让面试官相信你的潜力和能力

如果你属于工作经验少于3年的，面试官其实对你不会要求太苛刻，其实更会关心你的学习能力，工作责任心，承受压力的情况，责任心，稳定性，刚才提到的补救措施你一定要有证据说明，你得用事实讲话，毕竟空口无凭。

下面java课程举出一些我面试过程中听到的别人说出的一些亮点，大家可以举一反三灵活掌握。

1我虽然对您刚才说到的SSM技术了解不深入(事实上他是还是会在项目经理搭建好框架的基础上开发，还能知道一点，如果一点也不知道，说了也没用)，但我对MVC框架了解过，我以前做过的项目是用Jsp+Servlet30+JDBC实现的，也单独用过Spring的框架，所以我很快能上手。(我会适当问他JSP+servlet+JDBC里MVC的流程，如果他能说上来，我就会在评语上写“了解基本的SSM，了解MVC框架，知道MVC的开发方式”，但如果他不额外说明，或许我就会写，“只会在项目经理搭建好的基础上了解SSM，不了解框架细节”，这样即使他通过我的技术面试，后继的项目经理看到评语也不会对他有太多的好感)

计算机网络常见面试点总结

计算机网络常见问题回顾

21 TCP、UDP 协议的区别

22 在浏览器中输入url地址 ->> 显示主页的过程

23 各种协议与>

24 >

25 TCP 三次握手和四次挥手

三 Linux

31-简单介绍一下-linux-文件系统？

32 一些常见的 Linux 命令了解吗？

四 MySQL

41 说说自己对于 MySQL 常见的两种存储引擎：MyISAM与InnoDB的理解

42 数据库索引了解吗？

43 对于大表的常见优化手段说一下

五 Redis

51 redis 简介

52 为什么要用 redis /为什么要用缓存

53 为什么要用 redis 而不用 map/guava 做缓存

54 redis 和 memcached 的区别

55 redis 常见数据结构以及使用场景分析

56 redis 设置过期时间

57 redis 内存淘汰机制

58 redis 持久化机制（怎么保证 redis 挂掉之后再重启数据可以进行恢复）

59 缓存雪崩和缓存穿透问题解决方案

510 如何解决 Redis 的并发竞争 Key 问题

511 如何保证缓存与数据库双写时的数据一致性？

六 Java

61 Java 基础知识

62 Java 集合框架

63 Java多线程

64 Java虚拟机

65 设计模式

七 数据结构

八 算法

81 举个栗子（手写快排）

九 Spring

91 Spring Bean 的作用域

92 Spring 事务中的隔离级别

93 Spring 事务中的事务传播行为

94 AOP

95 IOC

不需要写代码就能衡量候选人的方法可能有一万种。我常用的三个主要方法可以覆盖许多不同的技能。在面试过程中，我们会谈论候选人的经验，要求他们做一些代码审查，并与别人合作设计一个系统。

下面我会详细解释这个过程。

我试图通过这些方法找到真正能够胜任技术工作的候选人，并且他们必须能在单纯的编程技能之外给团队带来价值。通常在一次面试中我能在大约一个小时内覆盖所有三个部分。我有信心这些信息能让我找到好的候选人。

1、深入挖掘他们的经验

许多团队已经这样做了。他们会在面试一开始花几分钟，询问候选人之前的工作，他们对工作的态度，等等。大多时候这就像随意谈话一样。

但这是不对的。

记住这是面试。你需要尽可能地理解他们构建系统时使用的技术。

为了做好这一点，你需要在面试开始之前仔细阅读他们的简历。这不是开玩笑，在面试开始之前至少花上10分钟仔细阅读（不是略读）简历，如果花30分钟时间则最好。要从简历中尽可能多了解些他们之前的项目，Google一下看看能否找到他们项目的公开信息。面试时挖掘背景信息所花的时间越少，就越能获得好的效果。

在面试中，要求候选人谈谈他最近最感兴趣的项目。要练习主动的倾听，要学会参与。假装你是他团队中的一员，或者假装你们是在做架构审查。你要努力了解他们构建的东西以及构建的方法。这样做的好处和坏处是什么？要让候选人知道，不知道答案无所谓，但重要的是能勾起你的好奇心。

下面是我认为能获得好的答案的问题：

你在项目中的职责是什么？这个问题本身并不是决定性的。即使在项目中承担的职责很小，他们也可能很适合你们的团队。你的候选人也许正是因为没能获得重要的职责而在寻找新的机会。因此，知道他们过去的职责会很有帮助。

你从他人那里获得了什么帮助？无法感受他人的帮助是个极其危险的信号。即使是个人项目，也一定需要别人的帮忙。你肯定不想要一个以自我为中心的同事。

给我介绍下那个功能的工作原理。解释下数据的来源和去向、存储方式以及这一切能带给最终用户的好处。这个问题的答案足以吸引你的好奇心。

这个项目中最糟糕的技术债务是什么？好的工程师必须理解他们做出决定时需要付出的代价。问完这个问题，可以继续询问他们怎样改正这些问题，或者尚未改正的理由。

有没有出过生产环境下的bug或服务中断？测试下他们是否理解bug的原因，以及团队解决bug的方法。他们是否提前预期到了bug？下次怎样才能避免同样的问题发生？

这一部分面试能让你直接了解候选人的经验。做好这一部分还能让你了解他们如何感谢别人或责备别人。你将会了解到他们如何在两难的工程问题上做出抉择，他们会与你分享最近的教训，他们与别人沟通技术的能力应该也很明显。

如果他们选择了不太适合的项目，可以考虑谈论其他项目。所谓不太适合的意思是项目不够复杂或他们记不清的情况。

注意，这一步要避免询问类似于“告诉我你解决过的最难的bug”之类的问题。要求别人回忆系统的某一部分的具体原理会带来大量的虚假负面判断。人们不可能拥有他们修复的bug相关的一切知识，这种问题会给面试过程带来很大压力。

2、让他们审查你们的代码

这项活动一半是代码审查一半是角色扮演。你可以借此筛选出那些能够提升团队整体代码质量并促进办公室氛围的人。

下面是代码审查过程中需要关注的一些方面：

他们怎样与代码的“作者”交流？交流是否有用？是否高效？是否友善？

他们会着重哪些问题？是否能明确表达出他们的疑问？他们是否会立即指出哪些无关紧要的问题？

他们是否善于阅读自己不熟悉的代码？

这个方法需要提前准备很多东西。你需要找到或编写一段代码供候选人审查。你还需要为你希望候选人找出的问题创建一个优先级列表。不要让面试管当场出题，一定要事先准备好。

在选择需要审查的代码时，不要选择产品代码。你的候选人没有你所拥有的背景知识，这样做实际上是将候选人与你的同事比较，而不是与其他候选人比较。

努力降低代码示例中的复杂度。面试的时候，候选人没有太多时间阅读代码，而且很可能他们并没有想到会做代码审查。热身就要花很长时间。

在代码中加入一两个真实的bug，但不要强调找bug。一般来说，代码审查并不是个好的找bug方法，特别是审查者从来没有见过代码的情况下。能自证的bug（如给需要数组的函数传递字符串）最好。在你的优先级列表中，bug的优先级应该是最低的，bug应该是给极其优秀的人的加分项。

最后，代码应该做一些实际的事情。如果你的公司很出名，那可以选择你的产品简化版本。但如果你需要花大量时间为候选人提供背景信息的话还是算了。

最好的选择要么是虚构的代码（也许可以选择本文竭力避免的代码面试中用到的代码），要么是开源代码中的一个拉取请求。

一旦决定了要审查的代码，你应该期待候选人找出下面这些东西：

过于糟糕的拉取请求的描述或提交信息；

能用但无法自洽的代码；

过于复杂的代码（需要重构的代码）；

混乱的变量或方法名；

过度设计的代码（即实际上永远不会用到的功能）。

如果代码中没有足够的问题，就多加一些。

这里有个潜在的问题，我还没有确定的答案。这个问题是：你是否应该提前将代码发给候选人？

如果你这样做，就又给那些有空闲时间的人以巨大的优势。如果不这样做，就要面临增加面试压力的风险。

我倾向于后者。好的面试官可以减轻压力，方法之一就是让面试者提前知道他们将做代码审查，你也可以在审查开始之前介绍你的期望。

技术方面的技巧

第一：ABC（Always Be Coding）。

一力降十惠，说的多不如做的多，所有工作都是这样，程式也不例外。你写过的程式越多，你的能力也就越高。但是，你必须做到有目的的程式，在写程式之前做到心中有数，明白自己的短板并且加强训练，坚持不懈的挑战自己的极限，努力使自己在各方面都很优秀。我强烈建议你把自己做过的每个项目——不管是否完成——都整理成作品集，在这里推荐GitHub，非常专业的程式分享社区，你可以把自己的作品集放到这。

第二：精通至少一种多重范式程式语言。

精通一门诸如C++这样的语言能让你从根本上理解程式，因为这类语言风格多样，如何写程式完全取决於你自己的风格，你能在一种语言里体会到不同风格的程式在执行上的差别，同时要达到这样的水平还需要大量的实战与练习。而且这类语言通常在各个社区中也是最活跃的板块，你可以很容易就找到志同道合的朋友来分享经验。其他也支持多风格程式的语言还有C#、Java、PHP、Python及Ruby。

关於C++ 的题外话：有一个跟著名的面试题，许多面试官都喜欢问，是这样：“如果把C++ 分为十个等级，1 为最低，10 为最高，你认为你自己处在哪一级？”希望上帝保佑那些回答9 或者10 的人，Bjarne Stroustrup 估计也只会给自己打到8 分甚至更低（此人为C++ 之父）。主要原因是这个语言经过这麼多年无数大能的不懈努力，已经超级复杂，被称为主流设计语言中最复杂的一款也不为过。

第三：熟悉各种算法的优劣。

先看看这份关於各种算法的对比图，确定都理解了之後，试著把这些算法都用自己的方式写一遍。这样你就会对各种算法有更深刻的理解。面试的时候这几乎是必考题哦。

第四：熟悉所有常用函数。

你最好把所有的常用函数都用自己使用的语言写一遍，不要依赖於现成的函数库，这样会加深你对各个函数以及语言本身的理解。试著快速写出下列函数：向量（动态数组）、鍊表、堆栈、队列、哈希映射、集合、优先级队列等等。

第五：要更务实。

临时抱佛脚早就没有用了，踏踏实实的打好基本功才是王道，花更多的时间去解决各种程式中遇到的问题，这里推荐多去TopCoder看看，那里有很多不错的资源。里边有各种案例可供学习，试著学习里边的思考方式来解决自己遇到的问题。我当初花了整整两个礼拜在TopCoder上，到最後我都能闭著眼一只手写出迪科斯彻算法，几乎能解决所有的图形问题。所做的不过是不断重复程式。这可能是Google最终要我的原因之一吧。Eric Schmidt说：“重复从不青睐祈祷者。”

第六：程式是最简单的。

这麼多年的工作经验使我明白了一条，写程式是一个工程师所有工作中最简单明确的一部分。我常挂在嘴边的一句话是：“简单的就像写段程式一样。”我相信对於一个工程师来讲，事前准备和事後维护才是更艰难的工作。比如说，你需要在程式前计划好你需要写什麼以及确保写好的程式能顺利运行。尽量让面试官知道，你不是一个只懂写程式的呆子。

需要注意地是，在别人面前写程式可能会略为彆扭，最好提前做些这方面的练习，可以参考下我前任同事Dan写的这篇《Whiteboarding》。

非技术方面的技巧

需要提前说明的是我在这方面并不专业，仅供参考而已。

第一：明白你为什麼选择这个公司这分工作。

不管大公司还是小公司，还是极度饥渴的创业公司，都不会要一个连公司是乾嘛的都不知道的人，哪怕这个人技术牛到一塌糊涂也不行。

第二：一定要满怀激情。

程序猿是一种没有固定工作时间的动物，如果你只是想找一份朝九晚五、有固定工资、只在偶尔加加班的工作，你还是别乾这行的好，你一定要爱程式，不管什麼时间什麼地点，只要有需要，就能随时投入工作。爱一行，乾一行，对於程式设计师来说尤其如此。

第三：不懂就问。

面试的时候如果碰到没有听明白的问题，一定不要不懂装懂，我曾经见过有些面试的人花了老牛鼻子的劲去解决根本没问过的问题，这不只是浪费你的时间，也是浪费我的时间。

第四：保持微笑。

所有面试宝典上都有这条，但是，不要做太过了，适当的微笑能产生很大的效果。我有时候会在面试完一个人後特别受打击，但是下一个面试者简单而真诚的微笑能让我一下子心情好起来。

不管你是职场老手还是菜鸟，掌握Java程序员面试的技巧是很有必要的，今天跟随北京IT培训一起来了解一下。

Java程序员面试时该有的技巧

一份专业简历很重要

在这里小编给你的建议是：如果你想提高自己的入选机会，那最好还是花点心思制作一份专业的简历，相较于你将来可能得到的巨大收获，这一点时间还是可以流失的。

了解你所要面试的企业

我们来举个例子：就拿我们的面试来说，会事先发电子邮件给面试者，并附上动力节点的名字和博客地址。但是让我惊讶的是，当我给他面试的时候，他竟然对我们还是一无所知。

我们在来举例正面例子：我们在面试时也碰到过这类Java开发人员，他能对我们官网以前写的一篇博客或者做的教学视频上面的内容侃侃而谈。(相比而言，你说我会选择哪个要让别人对你感兴趣，最简单的方法就是你先表达出对对方的兴趣。不管这种方法是否有欠公正，但是如果你想面试成功，那么小编建议你事先了解一下你应聘的这家公司)。

当今社会的信息是如此的发达，我们完全可以在Facebook、Twitter、微博、博客上找到任何公司的资料。即使你只是大致浏览一番，也会让你受益良多。

不要在面试官面前撒谎

知之为知之，不知为不知，如果你确实不知道，千万不要自作聪明来编造问题的答案。

相反，你应该诚实的说，你不知道或者你并不是百分百的肯定，但是你愿意尝试一下，然后再讲讲自己的想法，讲完后也可以问面试官正确答案是什么，从而显示你对此非常感兴趣。

一般来讲，面试官问的问题大多都是他们知道的问题如果你滥竽充数抱着侥幸心理，一旦被发现，面试官马上会质疑你的人品

学会解决算法问题

这是每一个开发人员都应该具备的重要技能，而且真要掌握起来也并不是那么难

在很多面试中，都会有这样的问题，要求你在白板或者电脑上解决软件编程问题，但是许多程序员，即使是那些非常优秀的程序员，都会一下子大脑一片空白，完全理不出思路来。如果你能花时间学会如何解决这种类型的面试问题，那么下次再碰到这种场景，就不会这么紧张了。我们会紧张其实和怯场无关，主要是因为我们不熟悉这些问题，也没有自信能解决这种问题。在这方面建立起自信之后，你就再也不会紧张了。

活力洋溢地回答问题

只用一个字或者一句话，照本宣科平平无奇地回答问题，或许在技术上是正确的，但是你忘了应该借此机会好好展示自己的激情——这才是一个开发人员能带给团队的最大正能量。

以上就是关于面试一般几轮全部的内容，包括:面试一般几轮、java课程分享程序员面试应该如何发挥自己的优势、如何面试后端程序员等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！