Google L3 ソフトウェアエンジニア オンサイト面接体験談:行動面接・設計面接・コーディング3ラウンド

選考プロセス

1. 行動面接

   ループはチームリーダーシップや、プレッシャーや挫折への対処法をテーマとした行動面接から始まった。

2. システム設計面接

   既存のAndroidチャットアプリケーションを題材とした、領域特化型の設計ディスカッション。候補者はそのアーキテクチャを批評し、改善案を提示するよう求められた。

3. 昼休憩

   設計面接と3回のコーディング面接の間の休憩。候補者はこの時間帯に普段以上の疲労を感じたと述べている。

4. 3回のコーディング面接

   面接官と問題セットがそれぞれ異なる、30分間の技術面接が3回個別に行われた。

5. 結果

   候補者はオファーを受け取ったが、志望していたL4ではなくL3レベルでのオファーだった。

行動面接

チームリーダーシップ、インシデント対応、個人のレジリエンス

• 自分のチームのためにチームビルディングイベントを企画するとしたら、どのように進めますか?
• 製品のリリースを予定していて、出荷直前に全体デモを行った後、出荷のわずか数時間前になってクラッシュを発見した場合、どのように対応しますか?
• ソフトウェアに関連するかどうかを問わず、これまでの人生で直面した最も困難な課題の一つについて説明してください。

システム設計(領域特化)

既存のAndroidチャットアプリケーションのアーキテクチャを批評し、再設計する

• 既存のチャットアプリケーションが与えられたとき、アーキテクチャ上の弱点を特定し、RxJavaやRetrofitのような一般的なサードパーティライブラリに頼らずに改善された設計を提案してください。

候補者はMVVMベースのアプローチを提案し、Google自身が関連するAndroidの課題に対処する際に用いているパターンに似た手法を参照した。面接官はさらに最適化された解決策を求め、単一の最善解にたどり着く前に、議論は他の設計上の論点へと移っていった。

コーディング面接:文字列変換

与えられたルールのもとで、ある文字列を別の文字列に変換できるかを判定する · 30分

• LeetCodeの「String Transforms Into Another String」(プレミアム問題)を解く:文字列Aを文字列Bに変換できるかを判定する。

候補者はこのラウンドを自身の最も出来が悪かったラウンドと述べており、その一因を昼食後の疲労に帰している。最初はワードラダー問題のようにアプローチしたが、面接官の誘導により文字の順序と一意性についての推論へと方向転換した。中核となるロジックは完成させたが、持ち時間内にフォローアップ問題には到達できなかった。

コーディング面接:N分木APIの設計

N分木を操作・照会するためのAPIを設計する · 30分

• 以下をサポートするN分木のAPIを設計してください:ノードbをノードaに接続するadd(a, b);葉ノードに限定したdelete(node);あるノードの左隣を求めるgetLeft(node);あるノードの右隣を求めるgetRight(node)。

候補者は親への参照を持つNodeクラスを用い、getLeft/getRightをレベル順(幅優先)走査で解いたが、より効率的な方法がおそらく存在するだろうと述べている。また、親子関係の重複を防ぐことや、削除前に所有関係を検証することなど、エッジケースについても指摘した。面接官はディスカッションに深く関わり、このラウンドは通常の持ち時間を超えて続けられた。

コーディング面接:グリッド上のマッチング

BFSを用いた2次元グリッド上の最短経路とマッチングの問題 · 30分

• 障害物のない2次元グリッド上に1人の人物と1台の乗り物が与えられたとき、その人物が乗り物に到達する最短の方法を求めてください。
• グリッド上に複数の人物と複数の乗り物が与えられたとき、各人物が乗り物に到達する最短の方法を求め、結果として得られるペアリングを返してください(発想としてはLeetCodeの「Campus Bikes」に近い)。

前半は標準的なBFSで解いた。後半では、どの人物がどの開始点から探索を広げているかを追跡し、到達した時点で乗り物を「確保済み」としてマークするBFSの変形を用いた。候補者は、面接官がよりシンプルな前半の観察に長く時間を使ったため、より難しい後半には10〜15分程度しか残らなかったと述べている。