tech-presentation-interview

技術プレゼンテーション面接

技術プレゼンテーションのラウンドは逆システム設計です。ホワイトボード上で仮想のシステムを設計するのではなく、自分が実際に構築したシステムを発表します。このラウンドでは、ほかのラウンドでは試せない3つのこと、すなわち本物の深い理解、プレッシャーの中で複雑なアイデアを伝える能力、そして受け継いだ知識ではなく自分自身の取り組みであることを試します。

使用する場面

以下に使用します：

• キャリアの中から発表するプロジェクトを選ぶ
• 物語としての展開を持つ、25～45分の技術プレゼンテーションを構成する
• 深さを調整する――どのコンポーネントを掘り下げ、どれを簡潔に説明するか
• 段階的に情報を開示するホワイトボード／バーチャルボードの図を準備する
• 厳しい追加質問への回答をリハーサルする
• さまざまな聴衆の構成（研究者、エンジニア、マネージャー）に合わせてプレゼンテーションを調整する

以下には使用しません：

• 自分が構築していないシステムを設計する（ml-system-design-interviewを使用）
• 履歴書の作成やキャリアのエピソードの抽出を行う（cv-creatorまたはcareer-biographerを使用）
• 複数の面接ラウンドを横断して調整する（interview-loop-strategistを使用）
• コーディング問題や行動面接のSTARエピソードを練習する
• カンファレンストークの準備（形式も評価基準も異なります）

---

プロジェクトの選定

最もよくある失敗は、誤ったプロジェクトを選ぶことです。この判断ツリーを使ってください：

flowchart TD
    A[List your top 5 projects] --> B{Did YOU make key<br/>technical decisions?}
    B -->|No, I inherited it| SKIP[Skip this project]
    B -->|Yes| C{Can you explain<br/>alternatives you rejected?}
    C -->|No, I just used<br/>what was standard| SKIP
    C -->|Yes, I evaluated<br/>tradeoffs| D{Are there interesting<br/>failure modes or<br/>unexpected challenges?}
    D -->|It went smoothly| WEAK[Weak choice --<br/>no drama = no depth]
    D -->|Yes, things broke<br/>or surprised us| E{Can you fill 30+ min<br/>of technical depth<br/>on 2-3 components?}
    E -->|No, it was<br/>straightforward| WEAK
    E -->|Yes| F{Is it relevant to<br/>the target role?}
    F -->|Not really| BACKUP[Keep as backup --<br/>use if nothing<br/>better qualifies]
    F -->|Yes, strong match| PICK[Strong candidate --<br/>select this project]

選定基準の評価表

候補となる各プロジェクトを1～5で評価してください：

基準	重み	評価する内容
個人としての主体性	5x	チームの合意や引き継いだアーキテクチャではなく、自分自身の判断
技術的な複雑さ	4x	自明でないトレードオフ、スケール上の課題、アルゴリズムの深さ
興味深い失敗	4x	発生した障害、予想外の出来事、方針転換、得られた教訓
職務との関連性	3x	応募先チームが構築するものとの重なり
定量化されたインパクト	2x	引用できる指標（レイテンシ、スループット、収益、精度）
最近のプロジェクトか	1x	最近のものほど望ましいですが、優れた5年前のプロジェクトのほうが、最近の平凡なプロジェクトよりも適しています

基準値：合計スコアが60超なら有力な候補です。40～60なら、より良い候補がない場合は許容範囲です。< 40なら、別のプロジェクトを探してください。

---

物語展開のフレームワーク

優れたプレゼンテーションはすべて、この構成に沿っています。逸脱すると聴衆の関心を失います。

flowchart LR
    CTX["Context<br/&gt;2 min"] --> PROB["Problem<br/&gt;3 min"]
    PROB --> WHY["Approach & Why<br/&gt;5 min"]
    WHY --> ARCH["Architecture Deep Dive<br/&gt;10 min"]
    ARCH --> RES["Results & Impact<br/&gt;3 min"]
    RES --> CHANGE["What I Would Change<br/&gt;2 min"]
    CHANGE --> QA["Q&A<br/&gt;15+ min"]

フェーズの詳細

1. 背景（2 分） -- 状況を説明します。ユーザーは誰でしたか？どのようなビジネスでしたか？なぜ重要だったのでしょうか？

• 会社／チームについて一文で説明します
• ユーザーの課題について一文で説明します
• 規模（リクエスト数／秒、データ量、ユーザー数）について一文で説明します
• 「I built a service that...」で始めてはいけません。課題から始めてください

2. 課題（3 分） -- 何が難しかったのでしょうか？構築したものではなく、なぜ簡単には解決できなかったのかを説明します。

• 葛藤を生んだ制約（レイテンシ対精度、コスト対信頼性）
• 既存のソリューションがうまく機能しなかった理由
• 誤った場合に何が起こるか（結果＝リスク）

3. アプローチと理由（5 分） -- 決定そのものではなく、意思決定のプロセスを説明します。

• 検討した代替案を2～3個挙げ、それぞれを却下した理由を説明します
• 選択を導いた重要な洞察や制約
• 何を最適化し、何を承知のうえで犠牲にしたか

4. アーキテクチャの詳細（10 分） -- 2～3個のコンポーネントを掘り下げます。すべての構成要素を順番に説明するのではありません。

• ホワイトボードで3ボックスの概要から始めます（references/whiteboard-diagrams.md を参照）
• 技術的に興味深いコンポーネントを2～3個選んで詳しく説明します
• 詳しく説明する各コンポーネントについて、何をするのか、なぜその設計なのか、変更すると何が壊れるのかを説明します
• 段階的に詳細を示します。関連する場合や質問された場合にのみ詳細を加えます

5. 成果と影響（3 分） -- 数値で示せる成果を説明します。

• 変更前／変更後の指標（レイテンシ、スループット、精度、コスト、開発者の作業時間）
• ビジネスへの影響（収益、ユーザー数、顧客満足度）
• チームへの影響（導入状況、開発者体験、運用負荷）

6. 変えるとしたら（2 分） -- 最も重要な2分間です。

• 振り返って変更したい、具体的な技術的決定を1～2個挙げます
• 当初その決定をした理由を説明します（当時は合理的な判断でした）
• 考え方を変えるきっかけとなった学びを説明します
• このセクションは、これまでの成功をすべて合わせた以上に信頼性を高めます

7. 質疑応答（15 分以上） -- 真の評価が行われる場です。

• 以下の「掘り下げ質問への対応」セクションを参照してください

---

深さの調整

最も避けるべきなのは、すべてを表面的に説明することです。2～3層を選んで深く掘り下げてください。

コンポーネントの種類	概要（1～2文）	中程度（2～3分）	詳細（5分以上）
標準的なインフラ（ロードバランサー、CDN）	ほとんどの場合は概要だけ	独自の設定がある場合のみ	それ自体がプロジェクトの中心でない限り不要
データストレージ層	標準的な SQL／NoSQL の場合	シャーディング、レプリケーション、またはハイブリッド構成の場合	ストレージエンジンを設計した場合
ML モデルのアーキテクチャ	既製品の場合	ファインチューニングまたは変更を加えた場合	独自のアーキテクチャや新しいアプローチの場合
データパイプライン	標準的な ETL の場合	リアルタイム処理や複雑な変換がある場合	難しいデータ品質の問題を解決した場合
API／インターフェース設計	標準的な REST／GraphQL の場合	複雑なバージョン管理や契約がある場合	プロトコル設計が中核的な課題だった場合
モニタリング／オブザーバビリティ	通常は概要だけ	異常検知が中核の場合	それ自体がシステムの場合

経験則：自分が自明でない判断をした部分を深く掘り下げます。業界標準のツールを標準的な方法で使った部分は、概要だけにとどめます。

---

掘り下げ質問への対応

質疑応答では、面接官は実際に構築した人と傍観者を見分けます。次のような質問に備えてください。

「X について、もう少し詳しく教えてください」

• これは誘いであり、罠ではありません。実装をもう一段深く説明します。
• 構成：「X の主な課題は［制約］でした。［理由］から、［アプローチ］で解決しました。難しかったのは［自明でない詳細］です。」
• 詳細を本当に思い出せない場合：「詳細を確認する必要がありますが、設計原則は［原則］で、実装には［パターン］を採用しました。」

「なぜ［代替案］を使わなかったのですか？」

• 代替案を決して否定しないでください。まず、その長所を認めましょう。
• 構成：「［代替案］を検討しました。［ユースケース］には有効です。私たちの状況では、［具体的な制約］により［代替案］はあまり適していなかったため、［私たちのアプローチ］を選びました。具体的には、［可能であれば数値を含む具体的な理由］です。」
• 検討していなかった場合：「当時は検討していませんでしたが、それは良い選択肢ですね。今の知識を踏まえると、重要なトレードオフは［トレードオフ］です。私たちの制約を考えると、［評価］だと思います。」

「少し過剰設計ではありませんか？」

• 防御的にならないでください。複雑さを正当化した制約を改めて説明しましょう。
• 構成：「そう感じるのも理解できます。複雑になったのは、［具体的な要件］があったためです。［複雑な部分］がなければ、［具体的な障害］が発生していたでしょう。一方、［要件］が変われば、［具体的な簡略化］によってシンプルにできます。」

「何を変えればよかったと思いますか？」

• 「何もありません」とは絶対に答えないでください。これは最も重要な質問です。
• 技術的な変更を、理由とともに2～3個具体的に用意しておきましょう。
• 構成：「今の知識を踏まえると、［具体的な決定］を変えます。当時は［それが妥当だった理由］がありました。その後、［変化したこと――新しいツール、学んだ教訓、規模の変化など］がありました。新しいアプローチは［具体的な代替案］です。」

「どのような障害が起きますか？」

• 仮定の話ではなく、実際に起きた障害について説明してください。
• 構成：「主な障害は［X］です。［頻度］で発生しました。発生すると、［影響］があります。［アプローチ］で軽減しています。残るリスクは［まだ保護できていないこと］です。」

---

聴衆に合わせた説明

その場にいる人に応じて、説明の深さを調整します。

聴衆	重視する点	詳細を抑える点
研究者／科学者	新しいアプローチ、評価方法、アブレーション研究	インフラの詳細、デプロイ運用
バックエンド／システムエンジニア	スケール、信頼性、パフォーマンスのトレードオフ、障害対応	ML モデルの内部、ビジネスの背景
ML エンジニア	モデルアーキテクチャ、トレーニングパイプライン、データの課題、サービングインフラ	ビジネスへの影響、チームの力学
エンジニアリングマネージャー	意思決定のプロセス、チーム連携、技術的リスク管理	低レベルの実装詳細
混成パネル	広い視点から始め、質疑応答を通じて各パネリストが求める詳細を見極める	一つの聴衆に合わせて事前に最適化しない

---

アンチパターン

デモの連続

初心者：成功ばかりを示し、失敗やトレードオフを語りません。すべての判断が最適で、システムは初日から見事に動作し、指標は右肩上がりです。 熟練者：うまくいかなかったこと、意外だったこと、変えたいことを率先して話します。失敗を恥ずかしいことではなく、真剣に取り組んだ証拠として捉えます。成功だけでなく、問題点についても具体的な指標を共有します。 見分け方：「何を変えればよかったと思いますか？」と尋ねたとき、答えが曖昧（「テストを改善できたかもしれません」）だったり、説得力がなかったりします（「正直、かなり満足しています」）。発表中、自発的に失敗談が出てきません。

チームへの貢献の曖昧さ

初心者：何についても「私たち」と言います。「私たちはアーキテクチャを設計しました」「私たちは Kafka を選びました」「私たちはレイテンシの問題を解決しました」。本人が具体的に何をしたのか、チームが共同で行ったことは何か、チームメイトが全面的に担当したことは何かが不明確です。 熟練者：全体を通じて、担当範囲を明確にします。「私はサービングレイヤーの設計を主導し、データチームとはパイプラインについて協力しました。また、チームメイトの Sarah がモデルのトレーニングインフラを担当しました。私の主な貢献はサービングレイヤーだったので、そこに焦点を当てて説明します。」自分が主導した判断には「私」を使い、実際の共同作業には「私たち」を使い、チームメイトの貢献は名前を挙げて説明します。 見分け方：追加質問を受けると、具体的な技術的判断について詳しく説明できません。「なぜ RabbitMQ ではなく Kafka を選んだのですか？」と聞かれ、「チームの決定でした」と答えたり、実施した具体的な評価ではなく、教科書的な一般論を述べたりします。

アーキテクチャの説明に終始する

初級者：すべてのコンポーネントを表面的に説明します。「それからキャッシュ、キュー、データベース、ロードバランサー、モデルサーバー、フィーチャーストアがありました……」各コンポーネントの説明は1～2文です。興味深い内容にたどり着く前に時間切れになります。ホワイトボードは複雑な地下鉄路線図のようになります。 上級者：3つのボックスで概要を描き、「興味深いエンジニアリング上の工夫があった2つのコンポーネントに焦点を当てます」と明言して、深く掘り下げます。1つのコンポーネントに5分かけて、トレードオフ、検討した代替案、障害モード、学んだことを説明します。面接官はそのコンポーネントを十分に理解して退席します。 見分け方：発表が予定時間を超えます。すべてのコンポーネントの説明が表面的です。ホワイトボードには15個以上のボックスがあり、拡大して説明する領域がありません。特定のコンポーネントを1つ選んで深掘りするよう求められても、候補者はすでに説明した内容以上のことを話せません。

---

リハーサル手順

1. 一人での通し練習（最低3回）：誰もいない部屋で時間を計って発表します。目標は、構成された発表部分を20～25分に収め、質疑応答に15～20分を残すことです。
2. 自分を録画する：録画を見返します。フィラーワード、説明が曖昧な箇所、話の筋を見失う瞬間を記録します。
3. 同僚との模擬練習（最低2回）：技術に詳しい友人に発表します。相手には厳しい質問をする役を頼みます。うまく答えられなかった質問を記録します。
4. 質疑応答のストレステスト：誰かに、厳しい質問リストから10問を矢継ぎ早に質問してもらいます。プレッシャーの中で冷静さを保つ練習をします。
5. 時間の基準：リハーサルで構成された発表が25分を超える場合は、内容を削ります。本番では必ずさらに長くなります。

---

参考ファイル

ファイル	参照する場面
references/project-narrative-template.md	プロジェクトの発表を一から構成するとき、ストーリーの流れを組み立てるとき、質疑応答の回答を準備するとき、ML パイプラインの発表例を確認するとき
references/whiteboard-diagrams.md	発表中に描く内容を計画するとき、段階的に情報を開示する戦略を立てるとき、物理ホワイトボードやバーチャルホワイトボードのヒントを確認するとき、ML システムの一般的な図のパターンを確認するとき