楽天バックエンドエンジニア面接実際の問題まとめ：Java基礎からシステム設計まで

背景紹介

本人は3年のJavaバックエンド開発経験があり、現在は中規模IT企業でフードデリバリー配車システムを担当しています。技術スタックはSpring Boot + Spring Cloud + MySQL + Redis + RocketMQです。楽天に応募したのは今年4月で、採用ページから直接バックエンドエンジニアポジションに応募しました。正直に言うと、楽天の面接の評判は二極化していて、簡単だという人もいれば難しいという人もいます。私の体験では、基礎とプロジェクトの深さが等しく重視される印象でした。ソースコードまで掘り下げる企業とは異なり、楽天は語れるプロジェクト経験を本当に求めています。

準備期間は約2週間で、JVM、並行処理、Spring、MySQL、Redisなどの高頻度トピックに重点を置きました。アルゴリズムはLeetCode Hot 100の中級問題を練習し、リンクリスト、木、動的プログラミングに重点を置きました。応募後6日で1次面接の通知を受け取り、全プロセスで約2週間半かかりました。

第1ラウンド：技術面接1回目（ビデオ面接、約65分）

4月10日午前10時、楽天のビデオ面接。面接官はバックエンドのテックリードで、30代前半の印象で、非常に直接的な話し方でした。自己紹介から始まり、すぐに技術的な質問に入りました。

1. 自己紹介

職務経歴と技術スタックを簡潔に説明し、配車システムのコアビジネスである注文スケジューリングとドライバー割り当てに重点を置きました。約3分。

2. HashMapの基盤実装

JDK 1.8のHashMapを説明：配列+リンクリスト+赤黒木、初期容量16、負荷係数0.75。面接官がリンクリストから赤黒木への変換閾値が8な理由を深掘りし、ポアソン分布に基づいて8回の衝突は極めて稀で、8を超える場合はハッシュ分布の問題や攻撃の可能性を示すと答えました。

3. ConcurrentHashMapの実装原理

JDK 1.7はSegmentベースのセグメントロック、JDK 1.8はCAS + synchronizedでバケットのヘッドノードをロック。面接官がJDK 1.8でReentrantLockを使わない理由を深掘りし、synchronizedはJDK 1.6以降ロックエスカレーションの最適化が行われ、ReentrantLockと同等の性能であり、オブジェクトのオーバーヘッドも削減できると答えました。

4. スレッドプールの動作原理

コアスレッド、タスクキュー、非コアスレッド、拒否ポリシーの流れを説明。面接官がコアスレッドを回収できるかを深掘りし、デフォルトではできないが、allowCoreThreadTimeOutをtrueに設定すると可能だと答えました。スレッドプールのサイズ設定方法も聞かれ、CPU集約型はCPUコア数+1、IO集約型はCPUコア数*2と答えました。

5. Spring Bootの自動設定原理

@SpringBootApplication内の@EnableAutoConfigurationが、SpringFactoriesLoaderを通じてMETA-INF/spring.factoriesから設定クラスを読み込み、@Conditional条件注釈でフィルタリングすると説明。面接官がカスタムスターターの作成方法を深掘りし、設定クラスを書いてspring.factoriesに登録すると答えました。

6. MySQLのトランザクション分離レベル

4つを説明：Read Uncommitted、Read Committed、Repeatable Read、Serializable。MySQLのデフォルトはRepeatable Read。面接官がRRレベルでファントムリードが発生するかを深掘りし、スナップショット読み取りはMVCCで、カレント読み取りはNext-Key Lockで解決すると答えました。

7. Redisが速い理由

いくつかの理由を挙げました：1）純粋なメモリ操作；2）シングルスレッドでコンテキストスイッチとロック競合を回避；3）I/O多重化；4）効率的なデータ構造。面接官がシングルスレッドで時間のかかる操作をどう処理するかを深掘りし、Redis 4.0以降は子スレッドで削除操作を処理し、Redis 6.0はネットワークI/Oにマルチスレッドを使用すると答えました。

8. アルゴリズム：3Sum（LeetCode 15）

ソート + 2ポインタ、15分で完成。面接官が時間計算量の分析を求め、O(n^2)と答えました。以前練習していたので、スムーズに解けました。

1次面接終了後3日で2次面接の通知を受け取りました。

第2ラウンド：技術面接2回目（ビデオ面接、約80分）

4月14日午後3時、このラウンドの面接官は部門のテックリードで、質問はシステム設計とプロジェクトの深さに重点を置いていました。

1. フードデリバリー注文配車システムを設計せよ

複数レイヤーから説明：1）ドライバー状態管理：オンライン/オフライン/配達中；2）注文スケジューリング戦略：近接性+負荷分散+方向一貫性；3）例外処理：タイムアウト時の自動再割り当て、ドライバーキャンセル時の再配車；4）データストレージ：ドライバーのリアルタイム位置はRedis GEO、注文状態はMySQL。面接官がスケジューリングアルゴリズムの最適化方法を深掘りし、遺伝的アルゴリズムや強化学習によるインテリジェントスケジューリングが可能だが、初期段階ではルールエンジンで十分だと答えました。

2. 分散トランザクションの処理方法

TCCとメッセージベースの結果整合性の2つのアプローチを説明。プロジェクトで使用しているRocketMQトランザクションメッセージに重点を置きました：まずハーフメッセージを送信し、ローカルトランザクションを実行し、結果に基づいてコミットまたはロールバック。面接官がコンシューマーが失敗した場合どうなるかを深掘りし、リトライメカニズム + デッドレターキュー + 手動補正と答えました。

3. MySQLのインデックス最適化

いくつかの原則を説明：1）カーディナリティの高い列にインデックスを作成；2）複合インデックスは最左前方一致に従う；3）インデックスが効かない場面を回避（関数、暗黙の型変換、LIKEの%始まり）；4）カバリングインデックスでテーブル参照を削減。面接官がインデックスが使用されているかどうかを確認する方法を深掘りし、EXPLAINで実行プランのtypeとExtraフィールドを確認すると答えました。

4. Redisのキャッシュブレイクスルー、ペネトレーション、アバランシェ

ブレイクスルー：ホットキーの期限切れ瞬間に大量リクエストがデータベースに到達 — ミューテックスロックまたは期限なしで対応；ペネトレーション：存在しないデータのクエリ — ブルームフィルターまたは空値キャッシュで対応；アバランシェ：大量のキーが同時に期限切れ — ランダムな有効期限で対応。面接官がブルームフィルターの原理を深掘りし、ビット配列 + 複数のハッシュ関数で、偽陽性率はあるが偽陰性はないと答えました。

5. プロジェクト深掘り：ピークQPSとトラフィック急増への対応

ランチピーク時のQPSは約5000、極端な天候時は8000に達する可能性があると答えました。対策：1）Redisでドライバー状態と注文情報をキャッシュ；2）RocketMQでピークカット；3）K8s弾力スケーリング；4）デグレード戦略 — 非コア機能の無効化。面接官がデグレード戦略の具体的な実装方法を深掘りし、Sentinelでデグレードルールを設定し、QPSが閾値を超えると自動的にデグレードすると答えました。

6. プロジェクトで最も技術的に印象的な最適化

注文スケジューリングアルゴリズムの最適化について説明しました。元々は単純な最近接マッチングを使用していましたが、ピーク時のドライバー利用率が低かったです。方向一貫性ファクターを導入し、注文の目的地と同じ方向に向かっているドライバーを優先的に割り当てることで、ドライバーの単位時間あたり完了注文数が12%向上しました。面接官が方向一貫性の計算方法を深掘りし、出発地から目的地へのベクトルとドライバーの現在地から目的地へのベクトルのコサイン類似度を使用すると答えました。

7. アルゴリズム：最長増加部分列（LeetCode 300）

DP + 二分探索のO(nlogn)解法を使用、20分で完成。面接官が二分探索のロジックを説明するよう求め、tails配列を維持し、tails[i]は長さi+1の増加部分列の最小末尾要素を表すと説明しました。面接官は理解に問題ないと確認しました。

8. 逆質問コーナー

チームの技術スタックとビジネス方向について質問しました。面接官は主に楽天のデリバリー配車システムで、技術スタックはJava + Spring Cloud + Redis + RocketMQと回答しました。

第3ラウンド：HR面接（ビデオ面接、約25分）

4月18日午前11時、HR面接は比較的リラックスしていました。

1. なぜ楽天を選んだのか

楽天のビジネスシナリオは非常に多様で、デリバリー、マーケットプレイス、トラベルの各ビジネスが独自の技術的課題を持っており、バックエンドエンジニアの成長に大きく役立つと答えました。また、楽天のテックブログの質が高く、エンジニアリング文化が強いことも理由です。

2. 長所と短所

長所：実行力が強く、コードで実際の問題を解決することが好き。短所：技術的実装に集中しすぎて、ビジネス価値の思考を疎かにすることがある。今はコーディングの前にビジネス目標を明確にするよう学んでいます。

3. 希望給与

希望を述べ、HRは等級決定後に具体的なパッケージを提示すると回答しました。

4. 何か質問はありますか

入社後のチーム配属プロセスについて質問しました。HRはプロジェクトのニーズと個人の希望を総合的に考慮すると回答しました。

面接問題まとめ

1. HashMap基盤実装 — Java基礎 — 中

2. ConcurrentHashMap実装原理 — Java並行 — 中

3. スレッドプール動作原理 — Java並行 — 中

4. Spring Boot自動設定 — Spring — 中

5. MySQLトランザクション分離レベル — データベース — 中

6. Redisが速い理由 — ミドルウェア — 中

7. 3Sum — アルゴリズム — 中

8. デリバリー配車システム設計 — システム設計 — 難

9. 分散トランザクション処理 — アーキテクチャ — 難

10. MySQLインデックス最適化 — データベース — 中

11. Redisキャッシュブレイクスルー/ペネトレーション/アバランシェ — ミドルウェア — 中

12. 最長増加部分列 — アルゴリズム — 中

13. 配車システムピークQPSと対策 — プロジェクト — 難

14. 注文スケジューリングアルゴリズム最適化 — プロジェクト — 難

感想とアドバイス

1. 楽天の面接はプロジェクトの深さを重視：JVMのソースコードまで掘り下げる企業とは異なり、楽天はプロジェクトを深く掘り下げます。注文スケジューリングアルゴリズムの最適化やピークQPSへの対応について、面接官は非常に詳細に質問しました。プロジェクト経験はデータで裏付ける必要があります。「最適化した」ではなく「12%向上した」と言いましょう。

2. システム設計問題は現実に基づかせる：デリバリー配車システムの設計では、いきなり高並行アーキテクチャを語るのではなく、まずビジネスロジックとスケジューリング戦略を明確にし、その後に技術的実装を説明する。面接官はビジネスを理解する能力を高く評価します。

3. Java基礎は確実に、ソースコードの深掘りは不要：HashMap、ConcurrentHashMap、スレッドプールは必須トピックですが、楽天は赤黒木の回転実装の詳細までは聞きません。原理と適用シナリオの理解で十分です。

4. 中級アルゴリズム問題は安定して解く：3Sumや最長増加部分列などの古典問題は必須で、アプローチを明確に説明できる必要があります。2次面接のLIS二分探索最適化では、面接官がロジックの説明を特別に求めました。

最終結果：4月22日にオファーを受け取りました。等級はM4、勤務地は東京。応募からオファー獲得まで合計12日。全体的に良い体験で、面接官は皆実務的でした。

FAQ

Q：楽天のバックエンド面接は通常何ラウンドありますか？
A：通常3ラウンド：技術1次、技術2次、HR面接。一部のポジションはクロス面接がある場合も。

Q：楽天のバックエンド面接の重点は何ですか？
A：Java基礎、並行処理、Spring、MySQL、Redisは必須トピック。システム設計とプロジェクトの深さも重点です。

Q：楽天のアルゴリズム要件は高いですか？
A：平均以上。LeetCodeの中級問題を解ける必要があります。配列、リンクリスト、木、動的プログラミングに重点を。

Q：大企業の経験がなくても楽天に入れますか？
A：はい、但し印象的なプロジェクト経験が必要です。伝統的業界から自作のオープンソースプロジェクトで合格した人を知っています。

Q：楽天のバックエンドエンジニアの給与はどれくらいですか？
A：M4等級で年収約600〜800万円（ボーナス含む）、等級と交渉によって異なります。