典型的なシステムデザインの面接は、40〜50分かかります。一部の企業では、「小さな」システムデザインの面接を行うこともあります。例えば、15分間で回路ブレーカーの高レベルでの動作について話すことがあります。しかし、一般的には、準備の基本は同じです。システムデザインがどのようなものかわからない場合は、以下の例をご覧いただけます。
マインドセットインタビュアーが見たいもの他のヒント準備アクティブラーニングモード：実践時間配分フレームワーク10分: 要件の明確化15分: ハイレベル設計25分: 詳細なコンポーネント、最適化、およびその他の機能システムデザイン解答例
マインドセット
- コーダーのように考えるのではなく、テックリードのように考えましょう。
- 間違った解決策は存在しますが、「正しい」システムを設計する唯一の方法はありません。
- コミュニケーションを重視しましょう。コミュニケーション、コミュニケーション、コミュニケーションです。
インタビュアーが見たいもの
1時間でTwitterを設計することは不可能です。インタビュアーが見たいものは通常次のとおりです。
- 多くのトピックについての幅広い基礎レベルの理解力
- あいまいな問題陳述を明確にする能力
- 選択肢のトレードオフを理解し、データや"感覚"を使って意思決定を行った能力
- ユーザーエクスペリエンスに関する考え
他のヒント
- 面接官が与えたヒント/フィードバックに耳を傾け、それらをデザインに取り入れてください。面接中は、同僚と一緒に仕事をしているかのように行動してください。
- シニアの役割を面接している場合、ほとんどの場合、あなたが議論を主導することが期待されます。
- 行き詰まった場合は、面接官に助けを求めてください。貴重な面接時間を無駄にせず、彼らがあなたを中断するのを待つことはありません。
- 特定の技術を使う代わりに、汎用的な名前を使用してください（詳しく知っている場合を除く）。例えば、Kafkaではなくメッセージキューを使用して、なぜRabbitMQではなくKafkaなのかといった質問を避けましょう。
- 面接中に正しい方向に進んでいるかを確認することは重要ですが、頻繁に確認しすぎる（すべての意思決定で）と「ジュニア」の候補者と見なされる可能性があります。
準備
インターネット上には多くのリソースがありますが、ここではあまり多くのリソースを提供せず、完了しないであろうリソースに過負荷にならずに準備を始めることをお手伝いしたいと思います。
パレートの法則（80/20の法則）によれば、多くの結果において、結果の約80%は原因の約20%によってもたらされるとされます。これはシステムデザインのトピックにも当てはまります。システムデザインのインタビューの約80%は以下の概念に関連しています：
- API
- データベース（SQL vs NoSQL）
- スケーリング
- キャッシング
- インデックス作成
- メッセージキュー
- CAP定理
- ウェブ認証と基本的なセキュリティ
- ロードバランサー
- レプリケーション
- 一貫性ハッシング
- フェイルオーバー
以下はおすすめのリソースです：
- データ駆動型アプリケーション設計 - Martin Kleppman
アクティブラーニングモード：実践
記事を読んだり動画を見たりするのは助けになりますが、それらは受動的な学習です。最終的には、システムデザインを学ぶには積極的な学習者である必要があると考えています。
友達と一緒に練習するか、Prampのようなプラットフォームを利用するか、または私たちを使っても構いません。
より多くのレビューはTrustpilotから確認できます
時間配分フレームワーク
60分の配分に適したフレームワークは以下のようになります:
- 10 + 15 + 25分
- 残りの10分は導入、小さな技術的問題、およびQ&Aのためのバッファですが、通常はスコアに影響しません
10分: 要件の明確化
異なる会社は異なることを求めますので、非常に詳細な指示がない限り、明確化する必要があります。いくつかの一般的な明確化の質問/仮定には以下があります:
- バックエンドに焦点を当てることはできますか？
- 非機能要件はありますか？
- 読み込みよりも書き込みが多いと仮定しても問題ありませんか？
- 支払いゲートウェイにサードパーティのサービスを使用しても問題ありますか？
- 複数の言語をサポートする必要がありますか？
仮定については、面接官と確認してください。すべての会社が数値を求めるわけではないので、求められていない場合は仮定のステップを省略して他のステップのための時間を節約してください。
15分: ハイレベル設計
このステップの目標は、機能要件を満たしていることを示す大枠を提供することです。このステップの終わりまでに、あなたと面接官の両方がリクエストからレスポンスまでのデータフローの一般的なアイデアを持つべきです。話すことができる一般的な内容には以下があります:
- 最もシンプルなアーキテクチャのイラスト (クライアント -> サーバー -> データベースなど)
- システムインターフェース
- API (HTTPメソッド、エンドポイントの機能)
- データベース
- どのようなデータを保存したいか
- どのような種類のデータベースを使用し、なぜそれを選んだのか (関係型、キーバリュー、グラフ、検索など)
- スキーマ
- (見積もりを行う場合) どれくらいのディスク容量が必要かを把握し、それが適切か判断する
- 例えば、TBサイズのデータを単一の関係型データベースインスタンスに保存するのは適切ではありません (参照: Amazon RDSインスタンスタイプ)
時間を節約するために、最適化やスケーリングについては話さないでください。つまり、ロードバランサーやレプリカはこの時点では含めないでください。
25分: 詳細なコンポーネント、最適化、およびその他の機能
このステップは、次の理由からほとんどの時間を費やしたいステップです:
- ハイレベル設計と比較して、異なるタイトル間で類似して見える可能性があるため (TikTok vs YouTubeなどを考えてください)、面接官は現在のタイトルに対してどれだけ深く掘り下げることができるかに最も興味を持っています
- 自身の知識を示す場所です
常に面接官とどのコンポーネントに関心があるか確認してください。このステップでは以下のことをメンションすることが望ましいです:
- 読み込みと書き込みのスケーリング方法
- システムの成長を支援するためのロジックの追加:
- 圧縮
- ファイルをチャンクに分割するなどのアルゴリズム
- システムの成長を支援するための追加のコンポーネント/ロジック。例えば、メッセージキューやCDNなど。