Metaのシステムデザイン面接質問

分散システムの豆知識を丸暗記して備えてきたかもしれませんが、この面接ではそれは評価されません。ここで扱うのは実際に出題される形であり、インフラよりもプロダクトエンジニアリングに近いものです。繰り返し現れるパターンは、あなたがすでに使っている消費者向け機能を、オープンな問題として渡されるというものです。

• ニュースフィードを設計する。ランキング、書き込み時ファンアウトと読み取り時ファンアウトの違い、フォロワーが数百万人いるアカウントで何が起きるか。
• メッセージングまたはチャットシステムを設計する。配信保証、順序保証、プレゼンス、デバイス間のオフライン同期。
• 通知システムを設計する。重複排除、バッチ処理、ユーザーごとのレート制限、プッシュ・メール・アプリ内通知にまたがる配信。
• 近くの友達や位置情報機能を設計する。地理空間インデックス、更新頻度、プライバシーモデル。
• 検索やトレンドコンポーネントを設計する。インデックスの鮮度とクエリのレイテンシのトレードオフ。

一部の面接プロセスでは、これをユーザー向けの挙動に近いプロダクトアーキテクチャの派生形に分けています。準備の仕方が変わるので、どちらのタイプかは採用担当者に確認しましょう。

よくある失敗は、開始2分で箱を描き始めてしまうことです。実践的な配分は、要件とスコープの明確化、APIとデータモデルのスケッチ、大まかなアーキテクチャの図示、そして面接官が指し示す部分を深掘りする、という流れです。

• まず要件から。どのユーザー向けか、どのプラットフォームか、読み込み中心か書き込み中心か、そして明示的に作らないものは何か。
• 次に数字。おおよその日次アクティブユーザー数、リクエストレート、ペイロードサイズなど、後のトレードオフの根拠になるものです。
• 図より先にデータモデル。エンティティの形とクエリ方法が、アーキテクチャを大きく左右します。
• 一つの深掘り。一つのコンポーネントに絞り込まれ、それがどう故障するか聞かれると考えておきましょう。

前提は声に出して伝えましょう。面接官がその前提に同意しなければ訂正してくれるので、それは無料の情報になります。逆に言葉にしない前提は、単なる抜け漏れに見えてしまいます。

平凡な回答は、正しいアーキテクチャを説明するだけです。優れた回答は、自分が受け入れたトレードオフと、許容する故障の形を明言します。「ここでは読み込みが支配的なので書き込み時ファンアウトを選び、著名人アカウントの書き込みが遅くなることは受け入れて、別のプル経路で対処します」と言えれば、完璧な図よりも説得力があります。

シニアポジションの面接を受けているバックエンドエンジニアを考えてみましょう。彼女は通知システムの設計を求められ、最初の六分間を要件確認だけに使います。一つのイベントに対してユーザーが二件の通知を受け取り得るか、順序は重要か、保持期間はどれくらいか。面接官は後に、重複排除についての議論がこの面接の決め手になったと述べ、彼女は一ページ分の図から先に進むことはありませんでした。

この語り方を一人で机の前で練習するのが、一番難しい部分です。/mock-interviewページでAI面接官相手にデザイン課題を試して、考えながら話すことに慣れておけます。

音声によるビデオ面接では、SubcueAIが面接官の質問を文字起こしし、あなたの側に推奨される構成を表示します。macOSとWindowsではデスクトップのオーバーレイとして、Chromiumブラウザ拡張機能ではサイドパネルとして表示されます。通話に参加するミーティングボットは存在せず、ミーティングのページに何かが注入されることもありません。デザイン面接での現実的な価値は、声に出して読み上げる答えではなく、容量見積もりや故障モードなど、プレッシャーの中で忘れがちなチェックリストとして機能することです。

ただし限界ははっきりしています。デザイン面接は通常、画面共有された共有ホワイトボードツール上で行われ、画面上のものはすべて面接官に見えています。生成された答えを読み上げるのも、面接官から「では別のアプローチではだめな理由は？」とすぐに聞かれて崩れてしまいます。他社のデザイン面接については企業別面接トピックにまとまっています。