Google L5 ソフトウェアエンジニア面接体験談:電話面接、オンサイト3ラウンド、システム設計、そして遅れて届いた不採用通知

選考プロセス

1. 電話面接

   ほとんど制約のない状態から始まり、入力の妥当性、エッジケース、そしてスケールへと段階的に進化していった、固定・静的なプロンプトではない単一の検索問題。

2. オンサイト、ラウンド1

   再帰を通じて状態を渡す方式からプロパティとして公開する方式へと切り替わった木構造の走査問題で、その後シリアライズ/デシリアライズの発展課題が続いた。

3. オンサイト、ラウンド2

   根底にある木構造を見抜くこと自体が課題の一部になっていた最短経路問題。

4. オンサイト、ラウンド3

   モバイルクライアントがサーバーからデータを取得するという短いシステム設計プロンプトで、実際のプラットフォームAPIを使うコーディング課題で締めくくられた。

5. システム設計ラウンド

   設計の一部について擬似コードではなく実際のコードを要求される、別枠のモバイルシステム設計ラウンド。

6. Googleyness and Leadershipラウンド

   標準的な状況判断系の質問をカバーする、対話形式の行動面接ラウンド。

7. 結果

   約2か月間音沙汰がない後、リクルーターは候補者に、そのポジションが3月付けで正式にクローズされたと伝えた。候補者は、4回の技術ラウンドのうち2回で自己評価が「不合格」だったことを踏まえると、いずれにせよ不採用になっていた可能性が高いと考えている。

電話面接

コーディング——制約が変化していく検索問題

• ある数値の集合が与えられたとき、目標値が存在するかどうかを判定する問題。プロンプトはほとんど情報のない状態から始まり、候補者はまず入力の種類(配列、木、ストリームのいずれか)を確認したうえで、まず線形探索の総当たり案を提示し、続いて二分探索案を提示する必要があった。
• 入力がソート済みかつ有効であるという前提が置かれた後、その前提が取り除かれ、候補者は負の値・オーバーフロー・重複といったエッジケースに対処し、不正な入力をどう扱うべきかを判断しなければならなかった。
• 入力サイズが1台のマシンに収まらない規模まで増えるにつれ、議論は結果を分割・統合する必要のある分散アプローチへと移っていった。
• 面接官は、線形探索ではなく二分探索を選んだ理由を説明するよう求め、また候補者自身のテストリストに欠けているテストケースを指摘するよう求めた。

候補者はこの面接官について、杓子定規な質問・ヒント・再挑戦のパターンというより、日常の設計ディスカッションに近い、いつになく対話的な人物だったと述べている。

オンサイトラウンド1

コーディング——木構造の走査、インターフェース制約、シリアライズ

• 深さ優先探索の問題で、深さ情報を求めるフォローアップがあり、最初は再帰呼び出しにdepth + 1を渡す形で解決された。
• その後、面接官はインターフェースを変更し、深さをパラメータではなくプロパティとして公開しなければならなくなったため、候補者は幅優先探索による解法へと切り替えることになった。
• データのシリアライズとデシリアライズに関するフォローアップで、対象が単なる数値ではなくカスタムモデルであったため複雑さが増し、シリアライズをまたいで同一性を保持する必要があった。
• 候補者はテストの記述も求められたが、電話面接のラウンドほど厳密なものではなかった。

候補者はこのラウンドについて、良いフィードバックが得られるだろうという手応えを持って終えた。

オンサイトラウンド2

コーディング——木構造内の最短経路

• 与えられたノードまでの最短経路を求める、あるいは構造内に存在しないノードまでの距離を求める問題。候補者はその構造が木であることをすぐには見抜けず、線形探索から解き始めた。
• 時間計算量を改善するフォローアップで、候補者は配列ベース、二分探索、グラフベースの各アプローチを試したのち、面接官からのかなりのヒントを得て、ようやく動作する解法にたどり着いた。

候補者は、解答にたどり着くまでにどれだけの助けが必要だったかを踏まえ、このラウンドはおそらく「不合格」だと評価した。

オンサイトラウンド3

軽量なシステム設計とAPIレベルのコーディングの組み合わせ

• 出発点となる前提:モバイルクライアントがサーバーにデータを要求する必要がある。候補者はそのフローを設計しなければならず、面接官は実際に問われている範囲を超えて設計を広げないよう議論を誘導した。
• 締めくくりの課題:テーブルビューを更新するシステムAPIを呼び出すコードを実装する。Appleの行の挿入・削除に関するドキュメントを参照しつつ、面接官は全体の再読み込みではなく、バッチ処理に対応した効率的な差分ベースの更新を期待していた。
• 候補者はラウンド最後の1分で実装上のミスを犯した——メインスレッド外でのUI更新やリテインサイクルの発生に類するもので、参照先のドキュメントではそれが非効率な使用パターンとして指摘されていた。

候補者はこのラウンドについても「不合格」を予想したが、その理由の一端は、そのミスが何年も前に読んで記憶に残っていなかったドキュメントの細部に関わるものだったことにある。

システム設計

実装の詳細を要求されるモバイルシステム設計

• モバイルシステム設計のプロンプトで、候補者は以前の面接ループにあったFacebookのシステム設計ラウンドと形が似ていると感じた。今回は機能があらかじめ定義されており、自由に広げられる余地は少なかった。
• 面接官は設計の一部について擬似コードではなく実際のコードを求め、エラーメッセージの表示方法についてもプレースホルダーのままにせず完全に仕様化するよう候補者に求めた。

候補者のモバイルシステム設計に対する基本的なアプローチ:レイテンシ(キャッシュとスレッド処理)、一貫性(単一の信頼できる情報源)、セキュリティ(ストレージ層におけるプライバシー上の影響)について検討すること。

Googleyness and Leadership

行動面接

• 意見の相違や無理な要求への対処など、状況判断系の標準的な行動面接の質問で、このループ特有のものというよりは、典型的な行動面接カテゴリから出題されたもの。