【金三银四跳槽季】Java工程师如何在1个月内做好面试准备？【石杉的架构笔记】

春节长假转眼已过，即将迎来的是一年一度的金三银四跳槽季。

假如你准备在金三银四跳槽的话，那么作为一个Java工程师，应该如何利用1个月的时间，快速的为即将到来的面试进行充分的准备呢？

之前写过两篇文章：

互联网公司的面试官是如何360°无死角考察候选人的？（上篇） 互联网公司面试官是如何360°无死角考察候选人的？（下篇） 这两篇文章，专门站在面试官的角度，给大家分析了平时互联网公司是如何全方位的考察一个候选人的。

总结起来，面试官考察候选人的时候主要是从技术广度、技术深度、基础功底、系统设计、项目经验几个角度来进行的。

那么本文咱们就针对每一块内容，具体的来说一下考察的一些点。更重要的，是针对考察的这些点，如何来快速的进行准备。

技术广度

技术广度，顾名思义，你作为一个合格的工程师在开发一个系统，完成一些具体的技术任务的时候，必然是要使用到很多的技术的，而且针对这些技术还需要掌握一些非常常见，各种不同的系统可能都会涉及到的一些技术架构/技术方案。

举个例子，一个互联网公司的比较重要的系统，首先肯定会用到分布式服务框架，比如dubbo/spring cloud，这样可以将系统拆分为分布式的架构，或者说现在很流行的说法是微服务架构，这样每个人负责一个服务或者是一个子系统。

接着这个系统很可能为了支撑一些特殊的技术场景会用到其他各种技术。

常见的比如说为了应对高并发的读会用到Redis缓存技术，为了做系统异步调用会用到RocketMQ技术，为了支撑大数据量的高性能检索会用到Elasticsearch技术，等等。

那么假如这个互联网公司在招聘Java工程师的时候，他的招聘要求是什么？

是不是必须得要求候选人起码在dubbo、Redis、RocketMQ、Elasticsearch等多个技术领域，都有实际的生产项目使用经验，而且还对这些技术的各种特性以及落地项目的时候常见的技术架构/方案都比较熟悉，这样招聘这个人进来之后才能上手立马干活。

要求一个候选人对各种常见的技术以及相关架构都有实际的项目经验以及对技术本身也足够熟悉，这就是所谓的技术广度，站在招聘候选人的角度来分析一下，想必大家就理解这个“技术广度”考察项了。

实际上技术广度这个东西，都说了是技术广度了，所以肯定不仅仅只是上面提到的那点东西。

实际上，一个合格的适合互联网公司的工程师在技术广度上，还需要掌握其他很多东西。

比如分布式事务、微服务架构、分布式锁、性能优化、Java虚拟机优化、Web Server优化、数据库优化，等等。

越是大型的互联网公司，就越是会针对技术广度这块，考察的可能会越广泛，要求更高一些。

二、技术广度的快速准备

那么既然已经了解了这个技术广度是什么之后，现在针对这个技术广度，在短时间内应该如何来快速的复习和准备呢？

这个问题，我们分成两种情况来说。

假如说你是一个平时就很勤奋很努力，过去几年一直在不停的学习的人，那么恭喜你了，这块东西百分百难不住你，因为你过去几年持续的学习，可能已经自己把技术广度的每个点的一些东西都研究过，而且或多或少都有一些使用的经验。

对于你学习过或者实践过的东西，你肯定都记录了一些笔记。你最好的准备方式，就是快速的回顾自己的笔记，把各种常见技术的核心原理和项目实践都通过笔记回顾的方式快速的回忆起来，在大脑里形成一个知识网络。

如果你是一个不那么勤奋的工程师，或者是一个工作才两三年，涉世未深的小年轻，还那么多的积累，此时怎么办呢？

那也没关系，记住一句老话：临阵磨枪，不快也光。你虽然没啥积累，但是你都要面试了，怎么着也得临阵突击一下吧。

下面就是要教你的方法了：你可以自己把技术广度可能涉及到的各种点都罗列出来，然后上网百度一下各个技术点常见的一些面试问题，或者是基本的一些核心原理。

通过百度各个技术点，然后从各种技术博客中快速了解一个技术的方式，短时间内可以迅速建立起来对技术广度中涉及到的各个点的一些基本认知、核心原理，这样在面试的时候避免一问三不知。

当然，大家也清楚，技术这东西是没法速成的，你采用第二种方法来突击，跟你第一种情况下有几年的积累厚积薄发，最后落地到面试的时候，表现是截然不同的，也会直接决定不同的人会进入不同层次的公司。

第二种情况的同学可能面试的时候问到一个问题，就只能说个一两分钟，但是第一种情况的同学，功夫都在平时，只要复习到位，面试的时候问到一个问题往往可以举一反三，一下子给你说个十多分钟都可以。这就是区别所在。

不过，就算你只说一两分钟，总比一问三不知，和面试官大眼瞪小眼好，对吧？

最后还是给各位强调一下，成功无捷径，作为一个优秀的技术工程师，最重要的事情是一年365天，每天都不停的学习积累，坚持很多年。

吃得苦中苦，方为人上人，笔者早年进行技术积累的时候，也是这样过来的。每天晚上学习到凌晨一两点，周六周日全天学习，坚持了很多年。

只有通过几年的积累，你才能够厚积薄发，量变产生质变，菜鸟变成大牛。

技术深度

技术深度是指的什么呢？简单来说，假如你有了上面第一条说的技术广度，这不能说明你有多优秀，仅仅只能说满足了面试的最基本的要求，招聘进来过后立马就可以上手干活了，没太大的培养成本。

决定你未来技术的高度有多高，还有你能否成为团队里顶梁柱的，是你的技术深度。

技术深度，顾名思义，就是说你对一个技术掌握的深度，举个最简单的例子。假如你们公司的一个系统里用到了kafka这个技术，好那么现在问题来了，线上生产环境中，每当高峰到来的时候，不知道为啥写kafka总会偶尔抛个异常出来，或者是说写入到kafka中的数据不知道为啥每天统计下来总会少一些。

线上生产环境遇到这种稀奇古怪的问题的时候，往往就是团队里技术大牛出场的时候。技术大牛，一定是对各种技术都有一定深度研究的人，能否在遇到技术问题的时候，直接从本质和底层出发，分析和定位问题，最后带领团队解决问题。

比如上面说的那些问题，那要解决的话，首先需要一个技术大牛对kafka的源码有过一定深度的研究，接着就是在遇到问题的时候根据当时的故障现场以及一些日志，结合源码的运行流程，来一步一步分析和定位出来问题所在，最后可能就是通过一些kafka的参数的调整，就可以解决上述棘手的生产问题。

上述描述的场景和能力，就是技术深度的体现，比如说你对某个技术有过完整的、全方位的、深入底层的源码研究，这就已经是常人不可及的技术深度了。

因为很多人说是看过源码，但是其实都是浅浅的看过一点点，理解不太深入。

同时如果还有一些对某个技术在线上生产环境遇到过一些棘手问题，通过源码分析来解决问题的经验的，那么就是更优秀的技术深度的体现。

技术深度的体现，不一定是说看过源码，这只是其中一种表现形式而已，其他的还有，比如说对某个特别有难度的技术场景，比如说公司双11每秒几十万QPS并发请求下，你负责了其中支付系统，成功应对超高并发量。

在这个过程中，你对系统架构的设计，对系统做的大量的并发优化、性能优化，都可以成为你在某个技术领域的技术深度的体现。

三、技术深度的快速准备

如何为了即将到来的面试快速的做技术深度的准备呢？

其实也很简单，分为两种情况来讨论。

如果你在过去几年，自己就深入阅读过大量开源技术的源码，在阅读源码的过程中，自己还把源码的架构图、流程图，手工画了大量的图出来。

那么此时你完全就可以把过去几年的源码研究笔记翻出来，快速过一下，练习如何在面试现场在白板上纯手工把各种技术的源码架构图和流程图现场画出来。

或者在过去几年，你对某个技术领域，针对很高的技术难度做过什么复杂的系统，在那个技术领域扎下了很深的研究的话，那么此时你也可以针对过去的笔记快速的复习，在面试现场一定要现场画图把你做过的复杂系统以及技术难度都说清楚。

但是如果你过去几年没上述所说的任何积累，那咋办呢？

还是那句话：临阵磨枪，不快也光。

一般面试官在考察技术深度的时候，很可能会问你：你对哪个技术比较熟悉一些？

遇到这个问题的时候，希望大家头脑清醒一些，千万不要脑子发热随便乱说，因为你要做好一个心理准备，一旦你说出某个技术出来，比如你说你平时用dubbo用的比较多，接着面试官可能会开启深入源码级别的10连击模式。

比如说，面试官立马就会开始问你对你熟悉的某个技术，各种底层的机制和原理，让你说源码的理解，给你出各种技术挑战之下这个技术该如何应对，等等诸如此类的问题。

我见过太多没经验的同学随便说个熟悉的技术，其实他就仅仅只是会用罢了，但是一旦当我深入提问的时候，基本就进入一问十不知的情况了。

如果发生上述情况，会让面试官对你的印象和态度极其不好，大家一定切记切记！

所以，假如你要是确实没有过对什么技术的深入的积累，这里也教你一个临阵磨枪的办法：

你可以从简历中挑选出某个你相对来说用的比较多，熟悉一点点的技术，然后直接用万能的百度，搜索“XX技术源码分析”，“XX技术底层原理”。

通过几天的时间快速的 “ 死记硬背 + 软磨硬泡 ”，力争对某个技术相对有一些稍微底层一些的理解。

这样做，起码在面试的时候被要求问到一些技术深度的时候，能相对给出一些比普通工程师的回答更好一些的分析，起码能在面试的时候，让你拿到好点的offer概率会相对更大一些。

还是那句话，做，总比不做好。你能对底层做了准备，有一些了解，总是要胜过那些浮于表面，只会使用API的工程师吧！

同样笔者这里要说，回归技术的本质，对于技术深度的积累，那更是没有任何捷径可言，更不是几个月可以完成突击的。

因为真要有技术深度的话，你可能需要花费至少2年的时间，从底层开始研究一些基础性的技术。

在打通你的底层技术任督二脉之后，再去对常见的开源技术进行深入的源码研究，比如说：dubbo、zookeeper、spring cloud、redis、rocketmq、elasticsearch，等等。

有了几年的积累过后，最后你在面试的时候，技术深度的体现，其实都是厚积薄发的。

基础功底

这块其实没啥可多说的了，大家估计现在慢慢都感觉到了，社招的有经验的工程师去面试互联网大厂的时候，很多时候可是都要考察数据结构和算法的。

四、基础功底的快速准备

这块如何快速准备呢？

我的建议是，如果真的还有1个月要去面试了，那你最起码用几天的时间，网上搜三五十个最常见、最典型的算法题，反复练习、务必熟练。

熟练到什么程度呢？

你需要反复练习，最后自己能够在白纸上一遍就手写出没有bug的代码。

哪些题目是最常见、最典型的？举个例子，经典排序算法以及其时空复杂度分析，经典查找算法，栈、队列、链表、二叉树等常见数据结构的算法题，这些相关的基础题目都要熟练掌握。

当然最好的对于基础的算法之类的东西的积累，还是在平时，比如你要是坚持每天就在leetcode或者lintcode上花费半小时刷一个算法题，坚持一年，你就刷了至少300道算法题，坚持两年，你就积累了七八百道算法题。

这个时候有了足够的积累，起码面试是不用担心任何基础性手写算法之类的问题了，功夫其实还是在平时的。

至于算法题目的难度选择，只需要LeetCode或者Lintcode上easy难度和medium难度即可。

社招对算法和数据结构的要求是低于校招的，校招是因为学生没有太多项目经验，只能考察你数据结构算法，看你聪不聪明。

这是一张lintcode上对应的数据结构算法题的难度 vs 求职的一个对照图，大家可以参考下。

还是那句话，搞定easy和medium难度的题目即可。曾经网上流传着一句话：如果你能手写所有easy和medium的题目，3遍之内通过，可以搞定硅谷大部分公司的技术面试，包括谷歌、Facebook等顶级公司的面试，这个在国内也差不多的情况。

下篇预告

这篇文章从技术广度、技术深度、基础功底，三大块出发，给大家讲了讲每一块会如何考察，以及大家从长期积累和短期突击两个方面来看分别应该如何准备。

不过，其实我个人一向是秉持着技术是长期积累的事儿，不是短期突击的事儿的态度。

但是如果你真的就是没长期积累，又要去面试，希望大家好好看下这篇文章，对你会被考察的能力有个思想准备。

同时就算是临阵磨枪，怎么磨，这里面也是有不少学问。我作为一个面试官的角度，最反感的就是不好好准备就瞎面试的人，自己美化炮制一份简历，拿到很多面试机会。但是过去直接裸面，最后一问三不知，浪费大家的时间。

接下来会再写一篇文章，来给大家聊一聊系统设计以及项目经验这两块该如何优雅的准备。这同样是Java面试，尤其是进阶岗位的面试里非常重要的部分，敬请期待。

（图源网络，侵权删除）

END

扫描下方二维码，备注：“ 资料 ”，获取更多“ 秘制 ” 精品学习资料

如有收获，请帮忙转发，您的鼓励是作者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授

推荐阅读：

1、 拜托！面试请不要再问我Spring Cloud底层原理

2、 【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？

3、 【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战

4、 微服务架构如何保障双11狂欢下的99.99%高可用

5、 兄弟，用大白话告诉你小白都能听懂的Hadoop架构原理

6、 大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问

7、 【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍

8、 拜托，面试请不要再问我TCC分布式事务的实现原理！

9、 【坑爹呀！】最终一致性分布式事务如何保障实际生产中99.99%高可用？

10、 拜托，面试请不要再问我Redis分布式锁的实现原理！

11、 【眼前一亮！】看Hadoop底层算法如何优雅的将大规模集群性能提升10倍以上？

12、 亿级流量系统架构之如何支撑百亿级数据的存储与计算

13、 亿级流量系统架构之如何设计高容错分布式计算系统

14、 亿级流量系统架构之如何设计承载百亿流量的高性能架构

15、 亿级流量系统架构之如何设计每秒十万查询的高并发架构

16、 亿级流量系统架构之如何设计全链路99.99%高可用架构

17、 七张图彻底讲清楚ZooKeeper分布式锁的实现原理

18、 大白话聊聊Java并发面试问题之volatile到底是什么？

19、 大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？

20、 大白话聊聊Java并发面试问题之谈谈你对AQS的理解？

21、 大白话聊聊Java并发面试问题之公平锁与非公平锁是啥？

22、 大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化

23、 互联网公司的面试官是如何360°无死角考察候选人的？（上篇）

24、 互联网公司面试官是如何360°无死角考察候选人的？（下篇）

25、 Java进阶面试系列之一：哥们，你们的系统架构中为什么要引入消息中间件？

26、 【Java进阶面试系列之二】：哥们，那你说说系统架构引入消息中间件有什么缺点？

27、 【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer的面试经历

28、 【Java进阶面试系列之三】哥们，消息中间件在你们项目里是如何落地的？

29、 【Java进阶面试系列之四】扎心！线上服务宕机时，如何保证数据100%不丢失？

30、 一次JVM FullGC的背后，竟隐藏着惊心动魄的线上生产事故！

31、 【高并发优化实践】10倍请求压力来袭，你的系统会被击垮吗？

32、 【Java进阶面试系列之五】消息中间件集群崩溃，如何保证百万生产数据不丢失？

33、 亿级流量系统架构之如何在上万并发场景下设计可扩展架构（上）？

34、 亿级流量系统架构之如何在上万并发场景下设计可扩展架构（中）？

35、 亿级流量系统架构之如何在上万并发场景下设计可扩展架构（下）？

36、 亿级流量架构第二弹：你的系统真的无懈可击吗？

37、 亿级流量系统架构之如何保证百亿流量下的数据一致性（上）

38、 亿级流量系统架构之如何保证百亿流量下的数据一致性（中）？

39、 亿级流量系统架构之如何保证百亿流量下的数据一致性（下）？

40、 互联网面试必杀：如何保证消息中间件全链路数据100%不丢失（1）

41、 互联网面试必杀：如何保证消息中间件全链路数据100%不丢失（2 ）

42、 面试大杀器：消息中间件如何实现消费吞吐量的百倍优化？

43、 高并发场景下，如何保证生产者投递到消息中间件的消息不丢失？

44、 兄弟，用大白话给你讲小白都能看懂的分布式系统容错架构

45、 从团队自研的百万并发中间件系统的内核设计看Java并发性能优化

46、 【非广告，纯干货】英语差的程序员如何才能无障碍阅读官方文档？

47、 如果20万用户同时访问一个热点缓存，如何优化你的缓存架构？

48、 【非广告，纯干货】中小公司的Java工程师应该如何逆袭冲进BAT？

49、 拜托，面试请不要再问我分布式搜索引擎的架构原理！

作者：石杉的架构笔记 链接： juejin.im/post/5c263a… 来源：掘金 著作权归作者所有，转载请联系作者获得授权！