Java程序员普遍存在的面试问题以及应对之道（新书第一章节摘录）

其实大多数Java开发确实能胜任日常的开发工作，但不少候选人却无法在面试中打动面试官。因为要在短时间的面试中全面展示自己的实力，这很需要技巧，而从当前大多数Java开发的面试现状来看，会面试的候选人不多。所以在展开讲述分布式组件面试技巧前，就先给出大多数候选人普遍会出现的问题，这需要大家引以为戒。

1 不少人只会“增删改查”

对于Java初级开发而言，平时的主要工作确实只是“增删改查”，即需要根据不同的业务需求，用Java和数据库等技术实现各种增删改查功能。而对于Java高级开发乃至架构师而言，日常工作中除了要做“调优”、“组件架构设计”和“问题排查”等高级的技术工作以外，“增删改查”之类的开发工作也会占到一定的比重，但在面试中，你不能让面试官感觉你除了“增删改查”之外，不会其它技能。
    比如作者在做技术面试官面试候选人时，发现不少人确实能很好地结合之前做过的项目需求，展示用Spring和数据库等技术实现各种业务需求的能力，也确实能回答用相关技术实现“增删改查”业务功能的相关问题，但被问及如下其它方面的问题时会一筹莫展，不少候选人甚至连相关术语都没听说过。
    • 数据库性能调优方面的问题，比如，在项目里，你是怎么用索引和执行计划等方式优化SQL语句的性能？
    • Java虚拟机内存调优方面的问题，比如，在项目里，请举例说明你是怎么排查OOM问题？或者你在开发业务功能时，用过哪些措施来提升JVM（Java虚拟机）的内存性能？
    • 高并发方面的问题，比如你们的项目最多能承受多大的并发量？在项目里，你用过哪些分布式组件来应对高并发的需求？
    • 数据库和分布式组件集群方面的问题，比如，你们项目里是如何用（数据库或Dubbo或Redis）集群来确保服务高可用？
    • 分布式组件综合应用方面的问题，比如，你们项目里用到过哪些分布式组件？它们是如何整合到一起来应对高并发的需求？
    由于目前大多数的项目需要工作在高并发的场景里，所以对应地在面试中，有极大的可能会问及上述性能调优、分布式集群乃至其它应对高并发方面的问题。所以如果候选人仅在面试中展示“增删改查”做项目的技能，那么就可能只    能应聘技术含量较低的开发工作，比如外派和外包类工作。
    这类工作除了能积累业务知识点外，恐怕还是没有机会接触到诸如分布式等高级开发技能，而这类业务开发工作的可替代性太强，长此以往个，可能就会遇到各种“年龄危机”了。

2 能背题，但不大会结合项目讲技术

目前在互联网上能搜索到很多Java方面的面试题，比如有算法方面的，有Java核心（Java Core）基础知识方面的，有数据库方面的，有Spring Boot或Spring Cloud等web开发方面的，甚至也有分布式组件和集群架构方面的，不少比较上心的候选人也会在面试前依次做充分的准备。
    面试前确实需要背题，而且有些关于底层代码和原理类型的说辞也能帮到候选人，但如果仅仅复习这些题目的话，可能只能掌握理论层面的知识点，无法在面试中向进一步向面试官展示你在实际项目里用过相关技能，而面试官恰恰是对后者更感兴趣。
    这里来讲一个面试问题的案例，比如面试官提问：“说下Java集合里ArrayList和Vector两种对象的区别？”，如果看过相关的面试题，候选人一般也能说出如下的说辞：“Vector是线程安全而ArrayList是线程不安全，同时在扩容时，Vector会扩容100%，而ArrayList是50%。”说到这个程度，面试官会认为候选人知道这两种对象，
    但如果候选人再进一步给出如下的说辞：“在上个项目里的，如果遇到单线程的工作环境，我会使用ArrayList之类的线程不安全对象，而且出于提升内存性能的考虑，在项目里我是使用ArrayList，因为它的扩容比例较低。”
虽然上述说辞也就寥寥几语，但由于结合到了项目，所以面试官会因此确认候选人真实在项目里用过，但这种“结合项目说技术”的能力，可能是候选人，尤其是初级开发层次的候选人普遍缺乏的。
    或许在Java核心基础技能方面，“结合项目经验说技术”这种做法对候选人帮助并不大，那么在分布式组件方面，“能结合项目说技术”的候选人与“仅会背题”的候选人之间的差别就足以决定面试成败了。来看下相关的面试案例。
又如在Redis方面，假设某候选人只是根据网上的面试题，了解了Redis数据结构和底层代码甚至搭建集群的做法，那么面试官只要用类似“结合项目说下Redis怎么用的”之类的问题就能问倒这位候选人，但如果另外一位候选人能结合使用场景说下配置、缓存数据的细节以及防穿透等项目实践要点，那么就能有效证明自己在项目里用过Redis。其实在面试中有不少候选人只会背题说理论，所以只要让面试官认为你在项目里做过，那么你就可以比那些只会背题的人强。
    本书会在分布式组件方面，一方面结合案例告诉大家在项目里使用分布组件的实践要点，另一方面会结合这些实践要点为大家整理相关面试说辞，并且还会在此基础上给出“Redis防穿透”、“Dubbo防超时”以及“Kafka防重发”等亮点技术的展示方式，从中大家能直观地掌握分布式组件方面准备面试的技巧，并能以此在面试中成功地超越大多数竞争者。

3 linux层面，普遍缺乏基本操作技能

确实大多数的项目是在windows操作系统上开发的，所以有不少候选人没有接触过linux等其它操作系统。根据作者技术面试官的经验，不少候选人会认为，开发好的项目是部署在windows系统上，分布式组件是安装在windows系统上的，日常排查问题，也只需要观察windows系统上的日志。
    但实际情况不是这样，分布式组件乃至集群，大多部署在linux系统上，开发好的Spring Boot等类型的项目也是部署并运行在linux系统上，所以面试官在面试过程中问及linux操作等相关问题，也就绝非是为难候选人了。
大家可以试想一下，如果某位候选人连如何在linux上查找并打开文件，并在文件里查找关键字符串之类的问题也说不上，那么如何证明自己真的在项目里排查过问题？甚至有些面试官会以此认为候选人只会“在windows系统上开发增删改查”这类初级的技能。
    其实哪怕对初级开发而言，要准备linux方面的面试，难度也不大，只需要准备些基本的文件操作命令，外带些基本的script脚本操作技能即可。也就是说，大家只需要稍微花点时间，根据本书后继章节里给出的步骤准备linux方面的说辞，就能在面试中让面试官有耳目一新的感觉，更何况通过linux操作技能，候选人还能有效地展示自己“分析、排查和解决问题”方面的能力。

4 排查和解决问题的能力，很多人不会展示

大家可以试想一下，面试官最希望候选人有相关技术的项目开发经验，所以如果候选人能有效证明自己在之前的项目里，有排查和解决线上问题的经历，那绝对是个加分项。
    但在面试过程中，很多候选人只是被动地回答问题，除此之外不会主动扩展。这样如果遇到不善于挖掘候选人亮点的面试官，那么这些被动回答问题的候选人是没有机会展示这类加分项的。
    在后继讲述Redis、Dubbo和Netty等分布式组件时，作者会给出针对相应组件“排查和解决线上实际问题”的技巧和说辞，这里先给出展示这类加分项经历的通用步骤。
    第一， 先说下对应的线上故障，比如某个系统不可用了，或者系统输出和预期的不同，或者在日志文件里发现错误日志。
    第二， 再说下根据错误日志定位到问题的流程，比如通过Redis哪些日志发现Redis有超时问题。
    第三， 再说下通过日志看到的错误和故障之间的因果关系，比如因为Redis超时，所以返回时间变长，这导致服务不可用。
    第四， 最后说下怎么解决的，比如在配置文件里对应地缩小Redis超时时间。
    这样候选人就能高效地在面试中展示相关技能地项目实践经验。而且请大家注意，这种“排查和解决问题”的相关说辞，在面试中怎么说都不会嫌多，所以在面试前，候选人可以针对“调优”、“高并发分布式应用”和“分布式集群”等诸多值钱技术，尽可能多地准备相关说辞。

5 被动回答问题，缺乏主动引导和抛出亮点的意识

刚才也提到了，不少候选人在面试中只会被动地回答问题，这样就拱手让出面试里的提问权，如果面试官问的问题不巧是候选人不熟悉的，那么面试结果可想而知。
但其实只要在回答好相关问题后，再多说几句话，就有可能把面试官的问题引导到你准备好的各种亮点说辞。其实这种“引导”技能一学就会，而本书在后继讲具体分布式组件的章节里也会较多地给出这种引导说辞，这里先给出些范例，请大家体会下这种引导的做法以及可能会带来的好处。
    比如当你回答好JDBC里Connection组件的相关问题后，再多说一句，“在我们项目里，除了用JDBC连接数据库外，还用到了Redis缓存来提升数据库性能”，这样面试官就很有可能继续问Redis相关问题，这样你就有机会展示面试前准备过的Redis集群和防穿透等亮点说辞。
    又如你回答好Redis防穿透方面的问题后，也可以再多说一句，“在之前的项目里，我们还解决过Redis防穿透方面的线上问题”，当面试官细问时，你可以继续说，“是通过日志发现了Redis穿透问题，原因是没有在Redis里缓存空数据和不存在的数据，后面缓存这类数据就解决了”，也就是说这里成功地把面试官的问题引导到“解决线上实际问题”的方面，并成功地展示了Redis方面的实际项目经验和排查问题的能力。
    其实不少面试官在面试前，还在辛苦地修改bug或者参加各种会议，也就是在面试前草草地浏览了一遍候选人的简历，而且也不大会准备面试问题，很多问题都是在面试中临时想的。所以当候选人在面试中抛出这类“引导”说辞后，面试官很有可能顺着这个话题继续问下去，通过这种方法，候选人就可以在面试中把问题尽量引导到自己准备过的范围内。

6 准备面试的难度，要低于做好项目的难度

怎么才算做好一个项目？要确保项目里没有各类bug，而且还要把项目成功部署上线，并且还要有效修复项目在线上运行时遇到的各种问题。怎么才能通过面试？回答出面试官的关键提问即可。
项目里遇到问题的种类和数量是不可测的，而面试官提的问题大多是有套路的，而且开发项目的周期至少几个月，而技术面试的时间最多也就持续一个小时，所以准备面试的难度，要低于做好项目的难度。
    一般面试分技术面试、项目经理面试和人事面试这三轮，本书更多会地会关注技术面试。技术面试一般二三十分钟，再长一般也不会超过一个小时，具体流程一般如下所述。
    1. 寒暄后会让候选人介绍诸如学历和工作过的公司等基本情况，这些说辞面试前可以准备。
    2. 随后会让候选人介绍最近的（或最拿得出手）项目情况，此时候选人可以用本书将要给出的方法，根据面试前的准备，结合项目实际抛出各种亮点说辞，并可以把后继面试官的提问引导到准备好的范围内，也就是说，介绍项目环节也可以准备。
    3. 在介绍完项目情况后，面试官一般就会自由提问。说是自由提问，但也会围绕着职位介绍上提到的技术点提问，如果是招Java方面的程序员，分布式组件方面也是一个考核点。这时，如果候选人能用到前文提到的引导技术，就能尽可能多地把面试官的问题控制在自己熟悉的范围内。
    4. 面试官可能再会问些数据结构和算法等方面的问题，不过这类问题也可以通过刷题来准备。
    5. 最后面试官会让候选人提问，这个环节也可以准备，候选人还能借机抛出之前没机会展示的亮点说辞。
    从中大家看到，做好项目和准备技术面试是两个不同维度的事情，前者是动手做，后者是开口说。而且如果在面试前准备充分，面试时绝对能结合项目抛出各种亮点说辞，或者可以通过“边写（细节）边画（框图流程图等）边说”的方式展示你对某个技术的理解，甚至还可以通过“回答好问题再多说一句”的方式引导面试官的问题。也就是说，通过准备面试以及在面试中引入各种技巧，候选人不仅能最大程度展示自己的亮点，还能有效地避免面试官过多地问及自己的薄弱点，这样就能有效提升通过技术面试的可能性。

7 准备面试的错误做法和正确做法

前文也说到，准备面试的难度要低于做好项目的难度，但事实上有不少候选人由于事先没有准备，或者准备方法不得当，从而无法通过面试，其中可能还不乏一些在项目组里承担重要作用的技术大牛，这也是为什么很多候选人在面试中表现不佳的原因。
    其实原因前文里也提到过：准备面试和做好项目是两个维度的事情。在给出面试的正确准备方法之前，先来对比性地看些错误的准备做法。
    1. 只根据之前项目里用过的技术准备面试。由于程序员日常开发工作大多是“增删改查”，所以接触到的值钱技术非常有限，单凭此无法拉开和其它竞争者的距离，所以这样做哪怕最后面试成功，能力和薪资也有可能被低估。
    2. 过多地刷算法题或编程题或相关面试题。要知道面试官一定会考核候选人相关技术的项目实践能力，如果就这样准备，可能面试初级开发岗位时还有机会过，但可能就很难应聘成高级开发岗。
    3. 仅在理论层面背些（分布式组件等方面的）说辞。对于这些值钱说辞，面试官大概率会问技术实现细节和排查问题的步骤，如果单凭理论说辞，无法有效证明自己在项目里用过这些值钱技能。
    对应地，正确的面试准备方法就呼之欲出了。这里给出的方法不仅涵盖了分布式组件方面，更适合于准备其它Java方面的面试。
    1 . 刷题等必要工作不能拉下，因为面试里也有可能问及相关问题，同时结合项目展示基本技能的说辞也得准备。
    2. 结合你做过的项目，尽可能多地准备值钱技术方面的亮点说辞，比如你能结合之前开发过的风控模块业务，说出Dubbo远程调用流程，这要比你单纯从理论角度讲要好很多。最好是类似的值钱技术，都找个和项目的结合点。
    3. 不仅要结合项目准备亮点说辞，更需要准备抛出这些亮点说辞的预案。比如你在面试前充分准备了Dubbo、Redis和Netty等方面的说辞，但面试官一直不问及，你也不能自说自话地展示。对应地，你需要准备“回答好SQL问题后引导到Redis组件”的话术，或者是“回答好Redis数据结构问题后引导到Redis缓存调优”的话术。总之对于你准备好的亮点说辞，你都要准备一套或多套“引导方案”，这样就能最大程度地展示你的亮点。

本书之后会详细展开描述上述准备方法。当然不乏有一些资深的面试官会很好地把控面试走向，不大会轻易被候选人的话术所引导。但你如果用到了上述准备方法，哪怕是遇到这类面试官，也能最大程度地抛出亮点说辞。况且你遇到的很多面试官可能是技术大牛，但在面试方面未必经验丰富。

8 面试时可以主动抛出的亮点汇总

对于前文提到的亮点说辞，Java程序员可以从哪些方面准备呢？其实有些话题上文已经提到过，这里更多的是总结性归纳。
    第一， 底层源码方面。往浅了讲，可以讲述Java核心对象方面的底层源码，比如ArrayList扩容、HashMap读写操作等底层实现，往深了讲，可以讲述Spring层面的底层源码，比如IOC机制如何注入对象，或者切面编程里如何关联对象和切面代码。再往深了讲，就可以讲分布式组件的底层源码，比如Dubbo的服务暴露或者Netty里的零拷贝。通过底层源码讲述对应的实现机制，能让面试官感觉你在这方面很专业。
    第二， 性能调优方面。这里可以从JVM垃圾回收机制讲到内存调优，也可以在数据库调优方面从索引引申到Redis缓存或MyCAT分库分表组件，甚至可以再讲述数据库和缓存集群，当然最好是要结合项目案例讲。通过展示这种技能，就让面试官感受到你技术的深度。
    第三， 监控、分析、排查和解决问题的能力。候选人可以结合案例从“通过监控或日志发现问题”、“通过日志分析排查问题”和“对应给出解决方案”这三个角度来说明，如果可以，再加上“分布式组件”、“性能调优”、“分析底层源码”和“同其它组合作解决”这些关键要素。在面试实践中，这部分的亮点说辞甚至能很好地抵消掉一些候选人在次要技能方面的不足。
    当然Java面试中可以抛出的亮点绝非只有这些，但在最多持续一个小时的面试过程中，候选人哪怕就充分抛出上述三个方面的亮点，就足以影响到面试结果。
    而且，对于Java初级开发和高级开发而言，分布式组件方面的使用经验都可以算是亮点。小到使用基本语法，中到使用集群，大到排查问题，只要结合项目说好了，也都是加分项。

9 不是总结，仅是开始

本文是我讲分布式组件面试技巧书的第一个章节里的部分内容，在其中仅是介绍大多数候选人的现状，并对应地给出了相关方法。

由于是第一个章节，所以很多方法只是亮相，并没有详细展开，甚至还没涉及到分布式组件这块。在后继章节里，本人将围绕Dubbo，Redis，Kafka，Netty等分布式组件，结合案例向大家讲述面试准备技巧和在面试中结合项目展示分布式技能的方式。对此，本人将在后继的博文里，陆续摘录相关文章，敬请期待。

而且本书尚在编写过程中，预计半年后出版，书出版后，也请大家多多支持。

 版权说明：如要转载本文，请事先征得本人同意。