GoogleソフトウェアエンジニアL4面接の完全振り返り：アルゴリズム+システム設計+行動面接の全記録

背景紹介

まず私の背景から：開発経験5年、現在は中国の大手IT企業でバックエンドエンジニアとして働いています。メインの技術スタックはGoとPythonで、インフラ関連のコードも定期的に書いています。2026年3月、GoogleのMountain Viewオフィスで働いている元同僚からリファラルの誘いがありました——彼のチームがL4 SWEを募集していて、挑戦してみないかと。

正直なところ、丸1週間迷いました。一方で、今の会社は特別不満はないわけではありませんが、収入は安定していてチームも悪くありません。他方で、Googleはずっと私のドリームカンパニーで、こういう機会を逃したら二度と来ないかもしれません。結局3月末に履歴書を提出し、Software Engineer L4、希望勤務地はMountain Viewとしました。

応募からオファー獲得まで、全プロセスで約8週間かかりました。4月中旬にリクルーターからのスクリーニング電話があり、4月末に電話面接を完了、5月中旬にバーチャルオンボード面接（旧onsite）が予定され、5月末に結果が出ました。予想より早いペースでしたが、結果待ちの1週間は本当に長く感じました。

準備期間は約6週間でした。仕事終わりに毎日LeetCode 2〜3問を解き、週末はシステム設計の練習をしました。総問題数は約120問、MediumとHardを中心に、グラフ理論、動的計画法、二分探索を重点的に練習しました。システム設計については、Alex Xuの2冊の本とYouTubeの動画を活用しました。行動面接の準備には1週間かけ、約8つのSTARストーリーを整理しました。

第1ラウンド アルゴリズム面接（約45分）

面接官はGoogle歴6年のSenior SWEで、非常にフレンドリーでした。2分ほど自己紹介をしてから、すぐに問題に入りました。

問題1：コーススケジュールの妥当性チェック（変種）

問題説明：n個のコース、一組の前提条件 [a, b]（コースaはコースbに依存）、および一組の 競合関係 [c, d]（コースcとコースdは同じ学期に履修できない）が与えられる。有効なコーススケジュールが存在するかどうかを判定せよ。

この問題は本質的にトポロジカルソートの変種です。最初は前提条件のトポロジカルソートだけを考え、実装後に面接官から競合関係の処理について追加質問がありました。約3分考え、競合関係を二部グラフの彩色問題としてモデル化する提案をしました——同じ学期のコースは競合できないため、トポロジカルソート後のコースに学期番号を割り当て、競合コースが同じ学期にならないようにします。

BFSトポロジカルソート + 貪欲法による学期割り当てのアプローチを使い、時間計算量はO(V+E+C)（Cは競合関係の数）。面接官はこのアプローチを認めましたが、最小学期数について追加質問がありました。ここで少し詰まりましたが、最終的に学期数について二分探索 + 各チェックでトポロジカルソートを使う解法を提案し、面接官は頷きました。

問題2：区間マージのカウント

問題説明：一組の区間が与えられ、マージ後の区間数を求め、各マージ後の区間の開始位置と終了位置を出力せよ。発展：区間数が非常に大きい（10億レベル）場合、どう最適化するか？

最初の問いは古典的な区間マージ問題で、すぐに実装できました。発展問題については、外部ソート + ストリーミングマージのアプローチを提案しました。面接官から具体的な実装詳細について追加質問があり、有限メモリで大規模データを処理する方法も含まれました。多路マージ + 最小ヒープの方法を図解して説明し、面接官は満足そうでした。

このラウンドの感想：全体的にペースがタイトでした。最初の問題の変種は確かに考える必要がありましたが、トポロジカルソートは基本技能なので助かりました。2問目の発展部分は少し緊張しましたが、外部ソートのアプローチは思いつきました。面接官は終始表情が乏しかったですが、最後に"good job"と言ってくれて、少し安心しました。

第2ラウンド アルゴリズム面接（約45分）

この面接官はL5 SWEで、第1ラウンドとは全く異なるスタイル——非常に静かで、ほとんど話さず、ずっと私がコードを書くのを見ていました。

問題1：文字列デコード

問題説明：エンコードされた文字列が与えられ、k[encoded_string] は括弧内の文字列をk回繰り返すことを意味する（ネスト可能）。デコード後の文字列を返せ。例："3[a2[c]]" → "accaccacc"。

これはLeetCode 394の原題で、スタックを使った解法を約10分で実装しました。面接官は一目見て、時間・空間計算量の分析を求め（どちらもO(n)と回答）、その後"next question"と言いました。

問題2：予算制約付き最小乗り継ぎフライト

問題説明：フライト情報 (from, to, price) のリストが与えられ、出発地から目的地までの総価格が予算以内の最小乗り継ぎ回数の経路を求めよ。同じ乗り継ぎ回数の経路が複数ある場合、総価格が最も低いものを返せ。n都市、mフライト、n ≤ 100、m ≤ 10,000。

約5分考えました。最初はDijkstraを考えましたが、2つの次元（乗り継ぎ回数と価格）を同時に最適化する必要があり、通常のDijkstraではうまくいかないことに気づきました。その後、BFSでレベルごとに探索する（各レベルが1回の乗り継ぎを表す）アプローチを提案し、各都市への最低価格を維持しながら、総価格が予算を超えたら枝刈りする方法を説明しました。

コーディング中にバグがありました——BFSのvisited判定が間違っていました。city + currentPrice を状態キーとして使うべきところを、cityだけを見ていました。面接官が指摘し、すぐに修正しました。時間計算量はO(m * budget)で、面接官から異論はありませんでした。

このラウンドの感想：2問目は確かに緊張しました。BFSの2次元最適化アプローチがすぐに思いつかず、visitedのバグもあって自分のパフォーマンスが良くないと感じました。面接官は終始無表情で、何を考えているか全く読めませんでした。このラウンドの後、落ちたかもしれないとさえ思いました。

第3ラウンド システム設計（約45分）

このラウンドが最も緊張しました。システム設計はずっと私の弱点だったからです。面接官はStaff Engineerで、非常に経験豊富で、質問が誘導的でした。

問題：Google Driveを設計せよ

面接官は言いました："Design a cloud file storage system like Google Drive that supports file upload/download, sharing, and real-time collaboration."

いつものフレームワークで分解を始めました：

1. 要件確認：積極的にいくつか質問しました——ユーザー規模（面接官は10億+と言いました）、単一ファイルサイズ制限（5TB）、バージョン管理の必要性（必要）、リアルタイム共同編集の必要性（必要、Google Docsのようなもの）。面接官は私の質問に肯定的でした。

2. 容量見積もり：10億ユーザー、1ユーザーあたり平均50GBと仮定すると、総ストレージ量は約50PB。DAU 1億と仮定し、1日平均10ファイルのアップロード/ダウンロードとすると、QPSは約10万、ピークQPSは約50万。

3. 高レベルアーキテクチャ：Client → API Gateway → Metadata Service + File Storage Service + Notification Serviceのアーキテクチャを描きました。Metadata Serviceはリレーショナルデータベース（Spanner）、File Storageはオブジェクトストレージ、NotificationはロングポーリングまたはWebSocketを使用。

4. ファイルアップロード：4MBチャンクによる分割アップロードのアプローチを提案しました。クライアントは複数のチャンクを並行アップロードし、サーバーがマージします。面接官からレジュームアップロードの実装について追加質問があり、アップロード済みチャンクリストを記録する方法を説明しました。

5. ファイル共有：ACLベースの権限モデルを設計しました。各ファイル/フォルダにはownerとACLリストがあります。面接官から共有リンクの実装について追加質問があり——短縮URL + トークン方式を提案し、トークンには有効期限があり、パスワード保護も設定可能としました。

6. リアルタイム共同編集：これが最も難しい部分でした。OT（Operational Transformation）ベースのアプローチを提案しましたが、面接官からOTの原理の詳細な説明を求められました。正直なところ、OTの理解は概念レベルにとどまっており、具体的な実装詳細は曖昧でした。面接官はCRDTとOTの違いについて追加質問し、CRDTが結果整合性でOTが強整合性という大まかな説明はしましたが、詳細は明らかに不十分でした。面接官はそれ以上追及しませんでしたが、表情から満足していないことがわかりました。

7. データ整合性：面接官からクロスリージョンレプリケーションの方法について質問がありました。非同期レプリケーション + read-your-writes整合性のアプローチを提案し、バージョン番号で競合を解決すると説明しました。

このラウンドの感想：前半は良くできました。要件確認と容量見積もりはしっかりしており、分割アップロードとACL共有も明確に説明できました。しかし、リアルタイム共同編集の部分は確かに弱点を露呈しました。OT/CRDTの実装詳細の準備が不足していました。やり直せるなら、Google Docsの共同編集の原理を徹底的に研究するでしょう。

第4ラウンド アルゴリズム面接（約45分）

この面接官はL4 SWEで、私より半年遅く入社した方でしたが、技術力は非常に高かったです。スタイルはリラックスしていて、同僚と問題を議論しているような感じでした。

問題1：二分木の最大パス和

問題説明：二分木が与えられ、任意の2つのノード間の最大パス和（ノード値の合計が最大のパス）を見つけよ。これはLeetCode 124、古典的なHard問題です。

この問題は以前に練習していたので、再帰 + グローバル変数の解法をすぐに提示しました。重要なポイントは：各ノードについて、そのノードを「折り返し点」とする最大パス和を計算しつつ、そのノードを始点とする片側の最大貢献値を親ノードに返すこと。時間計算量O(n)、空間計算量O(h)。面接官は2つのテストケースを実行させ、正確性を確認してから次の問題に進みました。

問題2：動的中央値クエリをサポートするデータ構造の設計

問題説明：3つの操作をサポートするデータ構造を実装せよ：addNum(num) 数値を追加、findMedian() 現在の全数値の中央値を返す、removeMedian() 中央値を削除。全操作O(log n)であること。

addNum + findMedianは古典的な双ヒープ問題で、すぐに実装できました。しかしremoveMedianで詰まりました——ヒープの先頭要素を削除した後、2つのヒープのサイズを再バランスする必要があります。最初は遅延削除（lazy deletion）を考えましたが、面接官は「削除操作が頻繁な場合、遅延削除だとヒープがどんどん大きくなる」と指摘しました。少し考えた後、2つのヒープ + 補助的なバランス操作を提案しました：中央値を削除した後、大きい方のヒープから1つの要素を小さい方のヒープに移動する。実装では、HashMapを使って削除された要素を記録し、ヒープの先頭要素が削除マークされた時に初めて実際にポップするようにしました。

面接官はこのアプローチについていくつかのエッジケースを追加質問しました。例えば、連続して中央値を複数回削除したらどうなるか。私はこのアプローチが極端なケースでは劣化する可能性を認めましたが、面接官は「面接としては十分だ」と言いました。

このラウンドの感想：全体的に良くできました。1問目は練習済みの問題で、2問目はremoveMedian部分で少し波がありましたが、最終的に実現可能な解法を提示できました。面接官のフィードバックもポジティブで、最後に彼のプロジェクトについて少し雑談もしました。

第5ラウンド 行動面接/Googleyness（約45分）

Googleの行動面接は他社とは少し異なり、「Googleyness & Leadership」と呼ばれ、Googleの文化的価値観に合致するかを重点的に評価します。面接官はPeople Partner（HRBP）で、技術バックグラウンドを持つ方でした。

質問1：同僚と意見が対立した経験を教えてください。どう解決しましたか？

フロントエンドの同僚とAPI設計フォーマットについての議論を話しました。私はRESTfulを主張し、彼はGraphQLを主張しました。彼のアプローチを否定するのではなく、技術ディスカッションを組織し、双方が5分間のプレゼンテーションを準備して、実際のデータで我々のユースケースにおける両アプローチの優劣を比較しました。最終的にRESTfulを選択しましたが、柔軟なクエリに関する彼の提案を採用し、一部のエンドポイントにフィールドフィルターパラメータを追加しました。

面接官の追加質問：「相手が譲歩を拒否したらどうしますか？」私は、テックリードにエスカレーションして、よりシニアな人に決定を委ねると回答しました。ただし、その前に双方の観点が十分に理解されていることを確認すると付け加えました。

質問2：仕事で犯した失敗を教えてください。どう対応しましたか？

本番障害の経験を話しました——私が担当するサービスがリリース後にメモリリークを起こし、OOM再起動が発生しました。すぐにバージョンをロールバックし、2日間かけて根本原因を調査しました。原因は、私が導入したキャッシュに有効期限が設定されていなかったことでした。修正後、3つのことを行いました：コードレビューにメモリ使用量のチェック項目を追加、チームにメモリプロファイリングのCIチェックを導入するよう推進、ポストモーテムドキュメントを書いて他チームと共有。

面接官の追加質問：「なぜコードレビューでこの問題が発見されなかったと思いますか？」私は正直に、キャッシュがユーティリティクラスで初期化されており、ビジネスコードのレビュー範囲外だったと説明しました。これはプロセス上の抜け穴でした。

質問3：職務範囲を超えて自発的に引き受けた仕事の経験を教えてください

チーム内で誰もやりたがらなかったオンコール当番システムの開発を話しました。従来の当番は手動のExcelで、ミスが頻発していました。2週間で自動当番ツールを開発すると自ら提案し、各人のタイムゾーン、希望、ローテーションの公平性を考慮しました。リリース後、当番ミスはゼロになり、チームの満足度も向上しました。

面接官の追加質問：「このツールはその後、他の人がメンテナンスしていますか？」詳細なドキュメントとユニットテストを書き、新入社員に引き継いだと答えました。彼は引き継ぎ後にいくつか新機能を追加しました。

質問4：チーム内のパフォーマンスが低いメンバーをどうサポートしますか？

メンター経験を話しました。新卒のメンバーで、コーディング能力は高かったが設計能力が弱い方がいました。毎週1on1のコードレビューを行いました——単に問題を指摘するのではなく、自分で問題に気づくよう導きました。例えば、「このコードは要件が変わった場合、変更しやすいと思いますか？」と聞くのであって、「ストラテジーパターンを使うべきだ」と直接言うのではありません。半年後、彼は独立してモジュールの設計を担当し、素晴らしい成果を出しました。

質問5：なぜGoogleを選んだのですか？

自分のキャリアプランとGoogleの製品への情熱を結びつけて回答しました。3つのポイントを強調しました：Googleの技術の深さと規模——Googleの規模でしか存在しない問題がたくさんあること。Googleのエンジニア文化へのこだわり——20%タイム、社内技術共有など。GoogleのAI分野への投資——数十億人に影響を与える製品に参加したいこと。

このラウンドの感想：行動面接は予想よりリラックスできました。おそらく、8つのSTARストーリーを事前に準備し、対立解決、失敗、自発的行動、他者支援などの一般的なテーマをカバーしていたからでしょう。面接官の追加質問は自然で、意地悪な感じはありませんでした。重要なのはリアルなストーリーを話すことです。捏造してはいけません。追加質問でボロが出るからです。

面接問題まとめ

第1ラウンド アルゴリズム面接

1. コーススケジュール妥当性チェック（トポロジカルソート変種 + 二部グラフ彩色）| 評価ポイント：グラフ理論、トポロジカルソート、二部グラフ | 難易度：Hard

2. 区間マージカウント + 大規模データ最適化 | 評価ポイント：ソート、貪欲法、外部ソート | 難易度：Medium → Hard（発展）

第2ラウンド アルゴリズム面接

3. 文字列デコード（スタック） | 評価ポイント：スタック、文字列処理 | 難易度：Medium

4. 予算制約付き最小乗り継ぎフライト（BFS + 枝刈り） | 評価ポイント：BFS、状態設計、多次元最適化 | 難易度：Hard

第3ラウンド システム設計

5. Google Driveの設計 | 評価ポイント：分散ストレージ、分割アップロード、ACL権限、リアルタイム共同編集 | 難易度：Hard

第4ラウンド アルゴリズム面接

6. 二分木の最大パス和（再帰 + グローバル変数） | 評価ポイント：ツリーDP、再帰 | 難易度：Hard

7. 動的中央値データ構造（双ヒープ + 削除操作） | 評価ポイント：ヒープ、データ構造設計 | 難易度：Hard

第5ラウンド 行動面接/Googleyness

8. 対立解決 | 9. 失敗対応 | 10. 職務範囲を超えた自発性 | 11. 低パフォーマンスメンバーのサポート | 12. なぜGoogleか

振り返りとアドバイス

1. アルゴリズムは「筋肉記憶」になるまで練習する。Googleのアルゴリズム面接はペースが速く、45分で2問というスケジュールで、考える時間はほとんどありません。トポロジカルソート、BFS、双ヒープは問題を見たらすぐ書き始められるレベルでなければなりません。第2ラウンドのBFS変種では、状態設計が十分に身についていなかったため時間を無駄にしました。問題数を追うだけでなく、各パターンにつき3〜5問は解いて、真の理解を確実にしてください。

2. システム設計は深く——フレームワークレベルで止まらない。第3ラウンドの教訓は、リアルタイム共同編集について概念だけを話し、OT/CRDTの実装詳細に踏み込まなかったことです。Googleの面接官は答えられなくなるまで深掘りします。すべての設計決定について「なぜ」と「どうやって」を明確に説明できるようにしてください。Googleでよく出題されるシステム設計問題（Google Drive、YouTube、Searchなど）について、それぞれ深く研究することをお勧めします。

3. 行動面接はリアルなストーリーを準備する——テンプレートを暗記しない。Googleynessの面接官は追加質問が非常に上手です。ストーリーが捏造だったり過剰に包装されていたりすると、2〜3層の追加質問でボロが出ます。私のアドバイスは、異なるテーマをカバーする6〜8のリアルなSTARストーリーを準備し、各ストーリーについて追加質問されそうな方向を考えておくことです。

4. コミュニケーションと心構えが完璧な解法より重要。第2ラウンドのBFS変種は実際には最適解ではありませんでしたが、面接官と良いコミュニケーションを保ち、考えながら話すことで、思考プロセスを見せることができました。第3ラウンドのリアルタイム共同編集はうまく答えられませんでしたが、「OTの実装詳細については深くありません」と正直に言い、思いつく限りの回答を提供しました。最終的にオファーを獲得できたということは、Googleが完璧な回答よりも思考アプローチとコミュニケーション能力を重視していることを示しています。

最後に、5月28日にリクルーターから電話があり、HC（Hiring Committee）が承認し、コンペンセーションパッケージが承認待ちとのことでした。6月上旬に正式なオファーを獲得——L4レベルで、総報酬は現在より約40%増でした。プロセス全体で最も辛かったのはHC結果待ちの1週間でしたが、最終的にすべて報われました。皆さんが希望するオファーを獲得できるよう応援しています！

FAQ

Q1：Google L4面接は通常何ラウンドですか？
通常、オンボード面接は4〜5ラウンドで、そのうち3〜4ラウンドがアルゴリズム/コーディング、1ラウンドがシステム設計、1ラウンドがGoogleyness行動面接です。具体的な構成は職位やチームによって異なる場合があります。私の場合は4ラウンドの技術面接 + 1ラウンドの行動面接、合計5ラウンドでした。

Q2：Google面接でPythonは使えますか？
はい。GoogleはPython、Java、C++、Go、JavaScriptなど、複数のプログラミング言語をサポートしています。私はコーディング問題にPythonを選びました。書くのが速く、時間を節約できるからです。ただし、Python特有の落とし穴（再帰深度制限、GILなど）に注意してください。面接官から追加質問される可能性があります。

Q3：Google面接のアルゴリズム問題の難易度はどの程度ですか？
LeetCodeを基準にすると、ほとんどの問題はMediumからHardの間です。Googleが純粋なHard問題を出すことは稀ですが、Medium問題に変種や追加質問を加えて難易度をHardに引き上げることがよくあります。LeetCode Mediumを中心に、グラフ理論、DP、二分探索、ヒープなどの高頻度カテゴリを重点的に練習することをお勧めします。

Q4：システム設計面接で図を描く必要はありますか？
はい。Googleのバーチャルオンボード面接では通常、Google DocsやCodelabを使用し、簡単なアーキテクチャ図を描くことができます。事前にこれらのツールに慣れておくことをお勧めします。図は面接官があなたの設計をより早く理解するのに役立ち、コミュニケーション能力も示せます。

Q5：Googleyness面接は何を評価しているのですか？
Googleynessは主に4つの次元を評価します：Respect（他者を尊重する）、Judgment（判断力）、Inclusion（包摂性）、Leadership（リーダーシップ）。具体的には、チームで効果的に協力できるか、曖昧な状況で良い決断ができるか、異なる視点を尊重できるか、自発的に物事を推進できるかを評価します。準備する際は、これら4つの次元を中心にSTARストーリーを整理してください。