Uberバックエンドエンジニア面接体験記：3次技術面接の実際の問題を完全レビュー

背景紹介

まずは自己紹介から。私は3年間のJavaバックエンド開発経験があり、現在は中規模のEC企業でバックエンド開発に携わっています。技術スタックは主にSpring Cloud + MySQL + Redis + Kafkaで、日常的に注文や決済関連の業務を担当しています。正直なところ、3年間EC企業で働いてビジネスには精通していましたが、技術的に壁にぶつかった感じがし、より大きなプラットフォームで挑戦したいと思っていました。

今年の3月、求人プラットフォームでLINEがバックエンドエンジニアを募集しているのを見て、履歴書を提出しました。驚いたことに、翌日にはHRから面接日程の連絡がありました。LINEの面接プロセスは3回の技術面接+1回のHR面接で、全体で約2週間かかりました。以下に各ラウンドの実際の問題と私の回答を詳しく共有します。

面接プロセスの完全レビュー

1次面接（約1時間、基礎+アルゴリズム）

1次面接の面接官は比較的若く、チームの主力開発者のようでした。面接のペースは速く、質問が次々と出され、雑談はほとんどありませんでした。

Spring関連：

最初の質問はSpring IOCの原理についてでした。Beanのライフサイクル — インスタンス化、プロパティ設定、初期化から破棄までの完全な流れを説明し、循環依存を解決する3段階キャッシュについても言及しました。面接官はAOPの実装原理について深掘りし、JDK動的プロキシとCGLIBプロキシの違い、Springのデフォルト選択戦略（インターフェースがあればJDK、なければCGLIB）について説明しました。

MySQL関連：

インデックス原理に重点が置かれました。B+ツリーがインデックスに適している理由（Bツリーやハッシュインデックスとの比較）、クラスタインデックスと非クラスタインデックスの違い — クラスタインデックスのリーフノードは完全な行データを格納し、非クラスタインデックスは主キー値を格納するため、非インデックス列のクエリにはテーブルアクセスが必要であることを説明しました。面接官はカバリングインデックスの概念と、インデックスが効かなくなるケース（関数操作、暗黙の型変換、最左前方一致の不満足など）について深掘りしました。

Redis関連：

Redisのデータ構造とその基礎実装について聞かれました。SDS、ziplist、skiplist、hashtableについて説明しました。面接官はZSetの基礎実装に焦点を当て — ziplistとskiplist+hashtableの2つのエンコーディング方式と、ziplistからskiplistに変換されるタイミング（要素数が128を超えるか、単一要素が64バイトを超える場合）について説明しました。その後、キャッシュペネトレーション、キャッシュブレイクダウン、キャッシュアバランシェの違いと解決策について聞かれました。

アルゴリズム問題：

2問出題されました。1問目はリンクリストの反転 — 簡単で5分で完了。2問目はK個のソート済みリンクリストのマージで、最小ヒープを使ってO(NlogK)の時間計算量で解き、約15分で完了しました。面接官は時間と空間の計算量の分析を求め、より良い解法があるかも聞かれ — 分割統治法もO(NlogK)だが空間効率が良いことを述べました。

2次面接（約1時間、アーキテクチャ+システム設計）

2次面接の面接官はテクニカルリーダーで、アーキテクチャとシステム設計に偏った質問が多く、思考プロセスがより重視されました。

マイクロサービスアーキテクチャ設計：

面接官は現在のプロジェクトのマイクロサービスアーキテクチャ図を描くよう求め、各サービス間の呼び出し関係、APIゲートウェイ、サービス登録・発見について多くの詳細を深掘りしました。Spring Cloud GatewayをAPIゲートウェイに、Nacosをサービスレジストリに、OpenFeignをサービス間呼び出しに使用していることを説明しました。面接官は「Nacosがダウンしたらどうするか？」と深掘りしました。ローカルキャッシュとサービスインスタンスのハートビートメカニズムについて説明しましたが、正直なところ答えは十分に深くなかったです。

分散トランザクション：

これは高頻度のトピックです。面接官はプロジェクトで分散トランザクションをどう処理しているかを聞きました。SeataのATモードと、実際に使用している結果整合性ソリューション — Kafkaメッセージ+ローカルメッセージテーブルに基づく方法について説明しました。面接官はTCCモードとSagaモードの違い、それぞれの適用シーンについて深掘りしました。この部分は準備ができており、うまく答えられました。

Kafka関連：

メッセージの損失と重複消費に重点が置かれました。メッセージ損失について：プロデューサー側でacks=all + リトライ、ブローカー側でmin.insync.replicas、コンシューマー側で手動オフセットコミットを使用すると説明しました。重複消費について：冪等性設計 — ユニークID + データベースの一意制約で保証すると説明しました。面接官はKafkaがなぜ速いのかも聞き — 順次書き込み、ゼロコピー、ページキャッシュ、パーティション並列処理について説明しました。

システム設計：フードデリバリー検索システムの設計

これはオープンエンドの問題で、ゼロから設計するよう求められました。まず要件を確認 — 検索範囲は全国かローカルか？リアルタイム性は必要か？面接官はローカル検索で、厳密なリアルタイム性は不要と答えました。その後、以下の次元で展開しました：

1. ストレージ層：ESを検索エンジンに、MySQLを永続ストレージに、Redisをホットクエリのキャッシュに

2. インデックス設計：都市別にインデックスを分割、レストラン名、カテゴリ、住所に全文インデックス、評価と売上をソートフィールドに

3. 検索フロー：ユーザー入力 → トークン化 → ES検索 → フィルタリング・ソート → 結果返却

4. 高可用性：ESクラスタデプロイ、読み書き分離、キャッシュウォーミング

面接官は設計に概ね満足していましたが、検索レコメンデーションとパーソナライズドランキングを考慮していないと指摘しました — 確かに私の見落としでした。

3次面接（約50分、プロジェクト+ソフトスキル）

3次面接は部門ディレクターで、よりマクロな質問が多く、技術的視野と思考の深さが重視されました。

プロジェクトアーキテクチャの進化：

面接官は最も挑戦的だったプロジェクトについて説明するよう求めました。モノリスからマイクロサービスへの移行経験 — サービス分割の原則（ビジネスドメイン別）、データ移行の方案（デュアルライト+照合）、カナリアリリースのプロセスについて話しました。面接官は「分割過程で最大の問題は何だったか？」と深掘りしました。分散トランザクションとデータ整合性の問題、そしてその解決策について説明しました。

技術選定のトレードオフ：

面接官は興味深い質問をしました：「技術スタックを再選択できるなら、どんな違う決定をするか？」いくつかの反省を共有しました — 例えば、Seataを選んだが実際のパフォーマンスオーバーヘッドが大きく、やり直すならメッセージベースの結果整合性を優先するだろう。また、サービスレジストリにEurekaを使ったが、Nacosの方が機能が豊富で移行コストも低かったので、最初からNacosを選ぶべきだった。

本番障害のトラブルシューティング：

面接官はシナリオ問題を出しました：「本番APIが突然遅くなったら、どう調査するか？」調査アプローチを説明 — まずモニタリングで特定のマシンの問題か確認、次にGCログでFull GCがないか確認、データベースのスロークエリログを確認、最後にネットワーク問題か確認。面接官は「データベースのスロークエリならどう最適化するか？」と深掘りしました。インデックス追加、SQL最適化、データベースシャーディングなどの方案を説明しました。

チームコラボレーション：

最後にソフトスキルの質問 — 技術方針の意見の相違をどう処理するか、クロスチームコラボレーションをどう推進するか、新人をどう育成するか。実際の仕事の例を挙げて説明し、面接官は納得しているようでした。

結果

3次面接終了後5日でHRから連絡があり、最終的にオファーを受け取りました。給与は約30%増でした。決して驚くほどではありませんが、LINEの技術文化と成長機会を考えると、満足しています。

面接の実際の問題まとめ

1次面接の問題：

1. Spring IOCの原理とBeanライフサイクル

2. 循環依存を解決する3段階キャッシュ

3. Spring AOPの実装（JDK動的プロキシ vs CGLIB）

4. MySQL B+ツリーインデックスの原理

5. クラスタインデックスと非クラスタインデックスの違い

6. カバリングインデックスとインデックスが効かないケース

7. Redisデータ構造と基礎実装

8. ZSetの基礎実装（ziplist vs skiplist）

9. キャッシュペネトレーション、ブレイクダウン、アバランシェの違いと解決策

10. アルゴリズム：リンクリストの反転

11. アルゴリズム：K個のソート済みリンクリストのマージ

2次面接の問題：

1. マイクロサービスアーキテクチャ設計（ゲートウェイ、レジストリ、サービス呼び出し）

2. Nacosがダウンした時の対応

3. 分散トランザクションの方案（Seata AT/TCC/Saga/結果整合性）

4. Kafkaメッセージ損失の防止策

5. Kafka重複消費の冪等性設計

6. Kafkaが高性能な理由

7. システム設計：フードデリバリー検索システムの設計

3次面接の問題：

1. プロジェクトアーキテクチャの進化（モノリスからマイクロサービスへの移行）

2. 技術選定の反省とトレードオフ

3. 本番API遅延のトラブルシューティング

4. データベーススロークエリの最適化

5. チームコラボレーションと紛争解決

感想とアドバイス

1. 基礎をしっかり固め、さらに知識を繋げる力を養う。1次面接は基礎知識を問います。各トピック単体では難しくありませんが、面接官は複数の知識ポイントを繋げて質問します。例えば、Redisデータ構造について聞いた直後にキャッシュペネトレーション、ブレイクダウン、アバランシェについて聞かれます。暗記だけでは対応できません。

2. システム設計問題では積極的に要件を確認する。2次面接のシステム設計問題で、私は最初に要件の境界を確認しました — これは重要です。すぐに設計を始めず、面接官が何を求めているかをまず理解しましょう。設計過程でも説明しながら図を描き、思考プロセスを見せましょう。

3. プロジェクト経験には深みが必要。3次面接で重視されるのは「何をしたか」ではなく「なぜそうしたか」「どんな問題に直面したか」「どう解決したか」です。面接前にSTARメソッドでプロジェクトを整理し、各プロジェクトについて3〜5個の深掘りポイントを準備しましょう。

4. アルゴリズムを疎かにしない。社員採用のアルゴリズム問題はそれほど難しくありませんが、リンクリストの反転やK個のソート済みリンクリストのマージなどの定番問題は素早く書ける必要があります。毎日少なくとも1〜2問は解いて感覚を維持しましょう。

5. 「分からない」と言うことを恐れない。面接で分からない問題に遭遇したら、でたらめを言うより「あまり詳しくありませんが、私の理解では...」と正直に言い、推論過程を共有する方が良いです。面接官は正解よりも思考アプローチを重視しています。

よくある質問FAQ

Q：面接は通常何ラウンドありますか？

A：社員採用のバックエンド職は通常3回の技術面接+1回のHR面接です。レベルが高い場合（L8以上）、クロスチーム面接が追加されることがあります。

Q：システム設計問題はどう準備すればよいですか？

A：「System Design Interview」を読み、実際のプロジェクトと結びつけて深く考えることをお勧めします。一般的な設計パターンに重点を：負荷分散、キャッシュ戦略、メッセージキュー、データベースシャーディング、検索エンジンなど。

Q：アルゴリズム問題は難しいですか？

A：社員採用のアルゴリズム問題はLeetCode中級程度で、それほど難しくありません。ただし、素早く正確に書き、計算量を分析できる必要があります。リンクリスト、ツリー、動的計画法、ソートなどの高頻度ジャンルに重点を置きましょう。

Q：結果はどのくらいで出ますか？

A：通常、各ラウンド終了後1〜3日で結果通知があります。3次面接後5日でHRから連絡があり、全体で約2週間でした。

Q：大企業の経験がなくても面接に合格できますか？

A：はい。私は中規模企業からの転職でした。重要なのはプロジェクトへの深い理解と確かな基礎力です。面接官は会社の規模で基準を下げることはありませんが、上げることもありません。