最近、多くの読者から、中規模から大規模のインターネット企業でJavaエンジニアのポジションに応募する際に多くの混乱に遭遇したというフィードバックを受け取りました。
これらの学生は、インターネット上で慎重な準備をし、Javaインタビューの質問をたくさん集めたと言いましたが、実際にインターネット会社にインタビューに行ったところ、彼らが尋ねたものがあなたが準備したものと同じではないことがわかり、非常に恥ずかしいです... ..
したがって、この記事から始めて、著者は長期の連続記事「Java AdvancedInterviewSeries」を書くことになります。主に、中規模および大規模のインターネット企業向けのJavaインタビューで、一般的で高頻度の技術的な問題について話します。
このシリーズの記事が、ゴールデンシーズンの皆様のお役に立てば幸いです。
中規模および大規模のインターネット企業のインタビュアーはどのように質問しますか？
まず、実際のインタビューのシリアルショットを体験してみましょう。現在、候補者にインタビューする場合、中規模および大規模のインターネット企業のインタビュアーは、一般的にシリアルショット戦略を採用して候補者の技術レベルを深く掘り下げます。
たとえば、レジュメに使い慣れたメッセージミドルウェア（MQテクノロジ）を書き込んだとします。次に、次のような一連の質問があります。
あなたの会社はオンライン実稼働環境でどのようなメッセージミドルウェアを使用していますか？
オンラインシステムの技術的な課題は何ですか。また、なぜメッセージミドルウェアをシステムに導入する必要があるのですか。
メッセージミドルウェアテクノロジーがRabbitMQを選択するのはなぜですか？
RocketMQまたはKafkaを使用してみませんか？技術選択の根拠は何ですか？
メッセージングミドルウェアの高可用性をどのように保証しますか？メッセージミドルウェアに障害が発生した後、システム全体の障害を回避しますか？
メッセージミドルウェアテクノロジーを使用する場合、配信されたメッセージが失われないようにするにはどうすればよいですか？
メッセージが1つだけ配信され、重複データがないことをどのように確認しますか？
繰り返しメッセージが消費された場合にデータの正確性を確保するにはどうすればよいですか？
オンラインビジネスでメッセージミドルウェアを使用する場合、メッセージの順序を確認する必要がありますか？
メッセージの順序を保証する必要がないのなら、なぜですか？メッセージの順序を保証するシーンがある場合、どのように保証する必要がありますか？
ダウンストリームのコンシューマーシステムがダウンし、メッセージミドルウェアに数百万のメッセージのバックログが発生した場合、どうすればよいですか？
オンラインニュースのバックログで制作の失敗に遭遇しましたか？これまでに遭遇したことがない場合、どう対処するか考えますか？
RabbitMQを使用していますか？次に、RabbitMQの基礎となるアーキテクチャの原則、論理アーキテクチャ、物理アーキテクチャ、およびデータ永続化メカニズムについて説明しますか？
RabbitMQの1秒あたりの最高ピークQPSはどれくらいですか？それらはどのようにオンラインで展開され、何台のマシンが展開され、マシンはどのように構成されますか？
Kafkaを使用していますか？次に、Kafkaの基本的なアーキテクチャの原則、データがディスクに保存される方法、および分散アーキテクチャ全体がどのように実装されるかについて説明します。
Kafkaがデータの高い耐障害性をどのように保証するかについて話させてください。ゼロコピーなどの技術はどのように使われていますか？ハイスループットでプロデューサーとコンシューマーのパフォーマンスを最適化する方法は？
Kafkaのソースコードを見たことがありますか？読んだことがあれば、Kafkaのソースコードについて理解していることを教えてください。
RocketMQを使用していますか？RocketMQの優れた機能は、分散トランザクションのサポートです。分散トランザクションでこのメカニズムをサポートする基本的な原則についてお話しいただけますか？
RocketMQのソースコードを読み、RocketMQのソースコードについての理解について話しましたか？
分散メッセージングミドルウェアの実装を求められた場合、アーキテクチャ全体をどのように設計および実装しますか？
上記はMQ関連の技術的な質問の一部にすぎません。実際、より良いインタビュアーの質問は、技術的な側面、技術的なポイント、およびプロジェクトの実践から質問することです。
技術幅調査
まず、候補者の技術的整合性を確認します。作業には特定の技術的ビジョンが必要であるためです。メッセージミドルウェアしか知らないとは言えませんが、分散キャッシュは何も知りません。
以前の大学入学試験と同様に、あなたの中国語はとても良いですが、体格はとても悪いので、適切ではありません。
したがって、エンジニアはまず、自分の技術的な欠点、特にキャリアの最初の初心者段階を完全に通過した3〜5年の経験を持つ学生を回避する必要があります。
したがって、3〜5年間働くときは、テクノロジーに欠点がまったくないことを確認する必要があります。テクノロジースタック全体は多かれ少なかれ既知である必要があり、死角が表示されることはありません。
たとえば、今お聞きしますが、NoSQLを使用できるビジネスシナリオはありますか？現在、国内企業にはどのような種類のNoSQLテクノロジーがありますか？特定のNoSQLで解決できる問題は何ですか？
3つの質問をする場合、これは典型的な技術的な欠点です。少なくとも、各テクノロジーが一般的にどのような状況で使用され、どのように使用され、どのような問題が解決されるかを大まかに知る必要があります。
したがって、前述のメッセージミドルウェア、分散キャッシュ、大量データ、分散検索、NoSQL、分散アーキテクチャ、高同時実行性、高可用性、および高性能テクノロジー。数年働いた学生がソースコードレベルに堪能である必要があるというわけではありません。
これは、数年の作業の後、特定の技術的幅と幅広い技術的視野を持つ必要があることを意味します。
基盤となるテクノロジーの調査
今日では、多くの主要なインターネット企業が基本的なスキル調査を行っています。たとえば、Java仮想マシンのコア原則、メモリモデル、ガベージコレクション、オンラインFullGC遅延パフォーマンスの最適化、オンラインOOMメモリオーバーフローの問題などです。
揮発性、ロックの最適化、Java同時実行のAQSソースコード、Nettyの背後にあるIOおよびネットワーク関連の知識。
実際、この種の基盤となるテクノロジーは、オンラインの高負荷大規模システムのアーキテクチャ設計と開発に必須です。
基盤となるテクノロジーがしっかりしていないため、多くのミドルウェアやその他の高レベルのテクノロジーは、原則を深く理解できません。
そして多くの場合、これらの技術はオンラインシステムの生産障害を解決するために必要です。したがって、基礎となるテクノロジーの習得は、優れたエンジニアが所有しなければならない品質です。
技術的な詳細調査
さらに、候補者がよく知っていて、仕事で一般的に使用されているスキルのいくつかを確実に詳細に調べます。
たとえば、プロジェクトでRedisまたはElasticsearchを使用している場合です。あなたがそれを使用し、それがあなたの特定のプロジェクトのコアテクノロジーである限り、あなたは間違いなく一連の質問を使用して、さまざまな詳細、最下層、および実稼働環境で遭遇する可能性のある技術的課題を深く掘り下げます。
要するに、ストレステストを使用して、この技術レベルをどれだけ深く習得したか、そして実際の経験がどれほど強いかを調べることです。
優れたインタビュアーは確かな技術的バックグラウンドを持っており、上記のニュースミドルウェアなどのテクノロジーについて一連の質問をすることができます。
そして、インタビュアーの技術的な深さが候補者のそれを超えている限り、質問を継続的に深めることで、彼が最も精通している技術分野の候補者の技術的な深さを調べることができます。
たとえば、テクノロジーの習得がソースコードレベルに達しているかどうかを考えてみましょう。
特定のフレームワークまたはミドルウェアの基盤となるソースコードの実装を深く理解し、そのアーキテクチャの原則をソースコードレベルから明確にしていますか？
このテクノロジーのオンラインでの高可用性の展開があり、過度に高い同時トラフィックアクセスを実行しましたか？
このテクノロジーのオンライン生産環境におけるさまざまな複雑な技術的課題を解決しましたか？
是否基于这个技术落地到你的业务系统中，设计出各种复杂的系统架构？
通过这种连环炮，可以非常好的考察出某个候选人对技术深度的掌握。技术深度的考察是中大型互联网公司面试官对一个高级/资深的候选人必须考察的。
因为如果一个人工作五年以上，来应聘高级职位的话，那我们绝对是要求他对至少一个技术领域有着较为深入的研究的。
比如说起码你得深入阅读过某个热门技术的核心源码，有一定的技术功底，可以解决一些复杂的线上故障。
技术广度决定了你可以利用各种技术来做项目，但是技术深度决定了你的技术功底。
你未来学新东西有多快，线上系统出了故障你能否快速定位和解决，你能否基于对技术的深刻理解为公司的项目设计和开发出复杂而且优秀的架构出来，这都取决于技术深度。
小结一下：上面我们用一个面试连环炮，引出了平时中大型互联网公司面试官是如何发问的。
然后从技术广度、底层技术、技术深度几个角度说了一下，我们一般如何考察候选人的技术。
接下来将会从项目经验的考察、系统设计的考察、候选人与岗位的匹配、多轮面试官的协作考察出发告诉大家互联网公司是如何全方位、无死角的考察候选人的。
知己知彼、百战不殆，面试也是如此。你只有真正了解了面试官的选拔标准，考察范围，才能更好的进行针对性的准备，成为行走的“offer 收割机”。
上面咱们用一个面试连环炮引出了平时中大型互联网公司的面试官是如何发问的。
紧接着从技术广度、底层技术、技术深度几个角度说一下，我们一般是如何来考察候选人的技术。
中大型互联网公司如何来考察候选人的技术？
下面我将会从项目经验、系统设计、履历/学历/素质、候选人与岗位的匹配、多轮面试官的协作这些方面，继续告诉大家，互联网公司是如何全方位、无死角来考察候选人的。
项目经验的考察
项目经验，绝对是面试官必须考察的，很可能上来就是让你先画一下项目整体架构图，说一下你们项目用了哪些技术以及核心的业务思路。
然后从项目入手，考察你项目里各个技术掌握的如何，通过连环炮对你掌握最好的技术进行深入考察，对一些高阶技术的考察，直接下探到底层。
举个例子，如果你说你们公司里用了 dubbo 作为服务框架：
那么会问问你 Dubbo 底层的通信框架是什么？Netty？Mina？
然后再问问你底层的 NIO 是啥？网络通信里的长连接和短连接是啥？
你是否看过 Dubbo 的源码？Dubbo 源码中你印象深刻的对并发技术的运用是什么？
一些面试官喜欢从项目展开问各种技术，也有一些面试官上来直接从你简历上的技术开始发问，从技术深入到项目。这就看个人喜好了。
当然无论如何，最后总会聊到项目的一些业务细节，好的面试官会掌握一个原则：死扣细节。
提问时，必须要深入到你把某个业务细节讲清楚，以及结合这个业务细节到底是如何落地和设计技术方案的，如何使用各种技术在业务中的。
比如你说你用了 Redis：
那就会进一步问你，你哪个业务用了 Redis？那个业务的流程请你叙述一下？
在 Redis 里你们具体是选用了哪种数据结构存放什么数据？数据的过期时间是什么？如果缓存过期了，你的数据兜底方案是什么，到哪儿去回查？
你的 key 如何设计的，为什么要这么设计？你的这个业务把数据放在了 Redis 里，是其他哪个业务来查 Redis？为什么要这样子做？如果不用 Redis 会怎么样？
这只是一个例子，实际上各种技术都可以在项目里深扣细节。这就能考察出，你对这个技术的实践到底有多深，经历过多么复杂的线上业务的实践，能 hold 住一个技术解决线上系统中的哪些问题。
总之，从项目里，我们可以看出你是否负责过复杂业务架构下的分布式系统的设计和开发？
你们的系统是否面对线上高并发大流量高负载场景的挑战，你是否经历过这种技术挑战？
你们的系统是否承载过亿级别海量数据的存储以及高性能读写的挑战，你是否解决过这些问题？
此外，从项目考察中，还可以直接看出你的整体能力技术定位。你是仅仅负责过一个模块呢？还是负责过一个子系统？
或者是作为架构师负责过一个完整的项目群，带过几十人的团队，设计过大规模复杂的系统架构？
所以说，你到底把控过什么样的项目，具备什么样的能力，从你负责过的项目里，直接可以看出来。
如果你来面试的是中级的岗位，那么可能我们觉得你技术整体 ok，独立负责过核心模块的开发，同时对各种技术都有一定的实践经验，就 ok 了。
如果你面试的是高级/资深的岗位，那么我们会看看你是否带领一个小团队独立负责过一个有一定复杂度和难度的完整系统的架构设计和开发。
如果你面试的是架构师的岗位，那我们肯定是要求你在一个公司里主导过很多人协作完成的大型而且复杂的项目群。
并且我们要求你对一个大型系统架构有深度的思考和整体的把控，而且这个项目要有足够的技术挑战，大用户量、高并发、海量数据，等等。
因此，项目考察，是重中之重。很多同学平时积累了不少的技术学习，但是有一个很大的问题是，项目经验和实践太少。
这些同学可能确实没经历过复杂系统的架构设计的历练，所以非常容易在项目经验考察这块出现问题，被面试官判定为技术不错，但是经验缺乏。
系统设计的考察
这个也是很多互联网大厂的面试官，在考察一些高级工程师及以上的同学，喜欢发问的。
一般会把自己公司或者团队里的一些业务场景拿出来，或者是普遍性的一些业务场景，然后来问你如何针对这个业务场景设计系统架构？
举几个例子：
如何设计一个电商秒杀系统架构？
如何设计一个消息推送系统架构？
双 11 大促的时候如何设计系统的动态扩容/缩容的机制？
类似诸如此类的一些场景式的系统设计考察。其实这个主要是用一些你可能没接触过的场景，来现场考察一下你的架构设计思维。
尤其是针对上面说的高级/资深、架构类的岗位，我们尤其会注重现场考察你没接触过的业务场景的架构设计。
因为毕竟你来了以后，肯定要让你接触全新的业务，然后立马给出合理而且靠谱的架构设计方案，在新的公司来落地你的经验。
很多同学平时不太注意积累系统设计的能力，导致出去面试的时候，人家一问场景系统设计问题，直接发蒙了。
所以，平时应该对公司里各种业务场景多思考，自己设定一些挑战，比如假设你公司的请求量暴增 100 倍，数据量暴增 100 倍，你的系统架构应该如何设计？
多给自己设立挑战，然后去尝试着思考设计，才能积累出系统设计的思维和能力来。
基本功的考察
很多大厂都会考察候选人的基本功，尤其是数据结构和算法。比如现场手写一些常见的算法题。
很多同学很容易倒在基本功这块，一些基础的数据结构和算法题都不会写，那就是有点问题了。
这里强调一下，这个东西并不是应届生专用的，其实也代表了一个工程师，甚至一个架构师的基本技术素养问题。
因此建议大家平时还是要注重基本功的保持，平时写写算法题，熟悉一下数据结构，能保持自己的技术素养不会掉落。
否则数据结构和算法都不熟悉，对复杂系统的技术细节把控基本也就没法做到，因为很多复杂分布式系统的源码里，到处是自己写的数据结构和复杂算法。
整体背景考察
最后一定会综合看一下一个候选人整体的背景，如履历背景/学历背景/过往经验/综合素质。
例如考察履历背景：
你过去是外包公司出身？还是传统 IT 公司出身？或者是一些小型互联网公司？或者是一二线大互联网公司出身？
另外你的学历如何？是大专？普通本科？211 / 985 本科？普通硕士？211/985 大学的硕士 or 博士？
你过去做的都是一些内部系统，比如 OA 系统，财务系统？或者都是 C 端系统，有上千万用户量的系统？或者你过去做的都是某种偏门的项目，比如爬虫之类的？
你的沟通表达能力如何？性格是否踏实和 nice，不浮躁？你是否有团队协作精神？
这些综合性的东西，其实都会在我们的整体考察范围之内，都会纳入考虑范围内，最后决定要不要发 offer。
候选人与岗位需求的匹配
按照上述流程考察下来以后，会经历多轮面试，基本一次好的面试就可以综合考察出一个候选人的完整情况了。这个候选人的技术面是否完整，是否有几个技术领域有足够的深度？
候选人做过什么样的项目，项目的实践经验如何，把控过多大的团队和多大的项目，对全新业务场景的系统设计能力如何，基本功如何，综合背景和素质如何。这些东西，基本上都可以很好的考察出来了。
此时就会将一个候选人跟岗位的需求进行匹配，比如说你要招聘的是一个资深 Java 的岗位，需要他过来开发的是公司里较为核心的子系统。
然后呢，你公司的技术栈是 Dubbo、ZK、Kafka、Redis，等等。
你们公司每秒有上万的并发访问压力，数据量一亿以上，线上系统偶尔故障，比如高并发下 ZK 突然报错异常，导致系统业务中断，然后需要带 4 个初级和中级的兄弟一起开发。
这时，你考察完一个候选人，就知道他的技术能力是否匹配这个岗位，技术深度能否 cover 住线上系统常见的一些故障。
能否在线上故障的时候，立马有足够的源码功底分析、定位和解决问题。是否有过类似足够的高并发和海量数据的项目经验。
是否带过几个人独立把控过一个核心系统的架构设计和开发，过去的公司背景咋样，学历咋样，综合素质咋样。这个候选人和岗位需求是否匹配，基本上就出来了。
多轮面试官的分工协作
上面列举了大量的技术考察的内容，实际上很难说是一轮面试官直接完成的。
因此，一般我们都是分成多轮面试官协作考察。但是根据不同的公司，不同轮的面试官的职责会稍微有一些不一样。
比如说一面面试官可能主要就是考察一下技术内容，包括技术面以及连环炮发问考察技术深度，以及算法功底，不太涉及项目。
二面面试官可能会着重考察项目经验，系统设计，同时对技术深度也会继续考察。
三者面接官は、あなたが管理しているプロジェクトの規模、チームの規模、チームの管理能力、仕様とプロセスの設計能力、全体的な作業履歴の背景と経験、ソフトな品質（コミュニケーション、チームワーク、価値観など）に基づいている場合があります。あなたを調べに来てください。
上記は単なる分割方法であり、企業内の異なるチームでの分業は異なる場合があります。
また、1つまたは2つの側面として、プロジェクトに関与せずに技術的側面と技術的深さを調べ、3つの側面でプロジェクトの経験を調べ、すべての側面で包括的な品質の一部を調べることも可能です。
あるいは、チーフアーキテクトのポジションなど、あなたが直面しているポジションが非常に高く、CTOまたはテクニカルVPが5回目のラウンドであなたにインタビューするために出てくるかもしれません。
しかし、それがどのように分割されても、全体的な調査の内容は、上記の一連の事柄とプロセスおよびプロセスです。