Google L4 ソフトウェアエンジニア 面接体験談:8ラウンドを経てオファーなし

選考プロセス

1. 応募

   Googleの採用ポータルから直接応募し、その後リクルーターから連絡があった。最初のスクリーニングまでに約1か月の準備期間があった。

2. スクリーニングラウンド

   オンサイトに進む前に、それぞれ1問のコーディング問題を中心とした2回のスクリーニング通話が行われた。

3. オンサイトラウンド

   オンサイト面接はスクリーニングの約2週間後に設定され、3回のコーディングラウンドと短いGooglyness(文化)面接で構成されていた。

4. チームマッチング

   オンサイトラウンドの約1週間後、リクルーターからフィードバックが好評だったとの連絡があり、採用マネージャーとのチームマッチング面談が設定された。この面談では高レベルの設計問題とチームの業務内容についての説明が行われた。

5. 資格要件による保留

   チームマッチングの後、リクルーターから当該ポジションの経験年数要件が3年に引き上げられたとの連絡があった。候補者の経験年数は2年10か月でこれを下回っていた。リクルーターは保留期間が最長で約2か月に及ぶ可能性があるとしていたが、実際には約1か月半後にプロセスが再開し、追加の1ラウンドが設定された。

6. 追加ラウンド

   プロセスは、実装よりもアプローチに重点を置いた追加の1ラウンドをもって再開し、その後候補者は結果を約1か月待った。

7. 結果

   リクルーターから追加ラウンドのフィードバックが否定的だったとの報告があり、プロセス開始から約6か月後、オファーなしで応募は終了となった。

スクリーニングラウンド1

リクルーターが設定した最初のコーディング電話面接

• 1問のコーディング問題(具体的な問題内容は候補者が別途まとめており、本記事には詳細を含まない)。面接官は、候補者が最初に示した解法よりもさらに最適化することを期待していた。

さらなる最適化についての期待のずれから、フィードバックは肯定的でも否定的でもない中立的な評価だった。

スクリーニングラウンド2

アプローチの前に確認質問が必要な、オープンエンドな幾何/最適化問題

• 重なり合う可能性のある長方形を表すX-Y平面上の点の集合が与えられたとき、全体の面積を2等分する垂直な線(長方形を通過してもよい)を求める。

制約を確認した上で二分探索によるアプローチで解いた。フィードバックは肯定的で、スクリーニング段階を通過したと伝えられた。

オンサイトラウンド1

計算量に関するフォローアップとテスト演習を伴う部分配列問題

• 数値の配列が与えられたとき、公差が+1または-1の「良い等差数列」(例:{1,2,3}や{3,2,1})を形成するすべての部分配列を求める。
• 得られた解法に対する単体テストケースを書く。

総当たりのアプローチから始め、フォローアップの要求を受けてO(n)に最適化した。フィードバックは肯定的だった。

オンサイトラウンド2

少数の与えられたブロッキングAPIを基にしたスケジューリング設計

• ブロッキングのcountWords() APIとisTaskCompleted() APIを持つクラス、および1台につき1ジョブを処理できるN台のマシンが与えられたとき、ブロッキングAPIの呼び出しを最小限に抑えつつ全体の完了時間を短く保つように、単語数カウントのジョブをマシンに割り振るスケジューリング方法を設計する。

空きマシンのキューと完了チェックによる再利用を組み合わせたラウンドロビン式のスケジューラを提案した。面接官はいくつかのフォローアップで掘り下げてきた。フィードバックは肯定的だった。

オンサイトラウンド3

重複禁止制約下でのランダム選択のためのデータ構造設計

• 常にランダムな曲を返す音楽プレイリストのシャッフラーを設計する。直前に再生した曲は、その後K回の再生では再び返されないようにする。
• 得られた解法に対する単体テストケースを書く。

時間・空間ともにO(n)のキューベースのアプローチから始め、時間O(1)・空間O(K)に最適化した。フィードバックは肯定的だった。

Googlyness

候補者の現在の職務とチームリーダーシップに関するシナリオについての短い行動面接 · 短時間のラウンド

• チームをゼロから作るとしたら、どのように進めますか。
• 成果が振るわないチームのマネージャーに任命されたら、どのように効率改善に取り組みますか。
• チーム内の対立をどのように解決しますか。

チームマッチング

経歴、高レベルの設計問題、チームとの相性についての採用マネージャーとの面談

• 高レベルの設計問題1問。実装の詳細ではなく、全体的なアプローチのみが求められた。

マネージャーはチームの現在の業務内容や職務内容についても説明し、話を進めることに前向きな姿勢を示した。

追加ラウンド

資格要件による保留の後に追加された、アプローチのみを問う設計問題

• 与えられたブール式(例:(a || b) && c)がTRUEと評価され得るかどうかを判定するライブラリを設計する。
• コーディングの知識はないが基礎となる数学には抵抗がない人が、このライブラリをどのように使うか。
• 入力形式はどうあるべきか、また、ライブラリはどのように呼び出されるべきか。
• 空間・時間の制約を踏まえると、実装を支えるデータ構造には何を使うべきか、またその理由は。
• 関連するクラスとAPI宣言(シグネチャのみ)を書く。
• 式がTRUEになり得るかを評価するコアロジックを実装する。
• その評価ロジックの想定される時間・空間計算量は何か。

式の変数に対する2^n通りの真偽値割り当てをすべて列挙するアプローチを提案した。面接官は、完全な実装ではなくアプローチと考え方を重視したいと述べた。その場での議論自体は好感触だったが、記録されたフィードバックは最終的に否定的だった。