- Authors

- Name
- Youngju Kim
- @fjvbn20031
- FDE面接は何を測っているのか
- 技術ラウンド — システム診断シナリオ
- 顧客シミュレーションラウンド
- ケーススタディラウンド
- 準備法 — RPGのミッションを面接練習に
- 最後の助言 — 「分かりません」を上手に言える人が受かる
- 手を動かして練習する
FDE面接は何を測っているのか
普通のソフトウェアエンジニア面接の中心がコーディングとシステム設計だとすれば、FDE面接の中心は未知の状況での判断です。Palantir、OpenAI、Anthropicの公開求人票が共通して要求するのは二つの束です。本番水準のエンジニアリング能力、そして顧客の前でのコミュニケーション。だから面接も、この二つを同時に突く形式で組まれます。
形式は会社ごとに違います。この記事は特定の会社の面接問題を写したものではなく、公開された職務要件から逆算して三つの代表形式に一般化した準備ガイドです。技術診断シナリオ、顧客シミュレーション、ケーススタディ。どれが出ても、採点されるのは結論の正確さより絞り込む過程の質だという共通点があります。この点はシステム設計面接と全く同じです。
技術ラウンド — システム診断シナリオ
最も特徴的なラウンドです。アルゴリズム問題の代わりに、こんな問題が出ます。構成した例を一つ挙げると — 「顧客先で今朝からAPI応答の一部が断続的に失敗しています。画面共有でこの環境をお渡ししますので、診断してください。」実際の環境を渡す会社もあれば、面接官がシステムの状態を口頭で教えてくれる口述型もあります。
ここで採点されるのは三つです。第一に、順序。第4回のプレイブックで扱った再現、レイヤー切り分け、仮説、検証の構造が体に入っているか。ログをやみくもに漁り始める候補者と、「まず症状が再現できるか確認します」で始める候補者は、最初の一文で分かれます。第二に、質問の質。診断に必要な情報を得る質問を投げられるか。面接官は顧客役を兼ねているので、質問せずに推測で走ること自体が減点です。第三に、声に出して考えること。いま何を見ていて、なぜ見ているのかを言葉にし続けること。沈黙の中で正解に到達するより、話しながら間違った仮説を自分で棄却する方が高く評価されます。
顧客シミュレーションラウンド
面接官が顧客を演じます。構成した例では — 「私はこの導入プロジェクトの現場責任者です。3週間経ちますが、目に見えるものがありません。うちのチームではこのプロジェクトをやめようという声が出ています。説明してください。」試されるのは技術知識ではなく、第5回で扱った筋肉の全部です。
採点ポイントは翻訳と期待値マネジメントです。感情の乗った言葉から事実を分離できるか(「目に見えるものがない、というのは具体的にどの画面の話でしょうか」)、防御の代わりに確認済みの事実と次の報告時刻を提示できるか、専門用語を相手の言葉に変換できるか。そして謝罪と責任のバランス — ひたすら謝る候補者も、ひたすらシステムのせいにする候補者も落ちます。練習方法は一つだけです。同僚に顧客役を頼んで、声に出してやってみること。文章で準備した回答は、圧力がかかった瞬間に蒸発します。
ケーススタディラウンド
課題型または発表型で、仮想顧客の状況を渡されて計画を立てます。構成した例では — 「製造業の顧客が、我々のプラットフォームで設備データ分析をやりたがっています。PoCを設計してください。」白紙から計画を立てる能力、つまり第6回の内容が丸ごと採点されます。
強い答案の骨格は決まっています。成功基準を数字と判定者まで先に定義し、データ境界とセキュリティレビューを第1週の日程に打ち込み、範囲を攻撃的に絞り、失敗条件と次の段階を明示すること。弱い答案の共通点は、技術アーキテクチャだけが詳しくて運営設計がないことです。発表型なら、スライドの枚数を減らして1ページの成功基準文書を中心に置く方が印象に残ります。
準備法 — RPGのミッションを面接練習に
三つのラウンドすべてに効く練習道具として、このブログにはFDEエンジニア育成RPGがあります。31の現場ミッションはすべて「遅いんです」「つながらないんです」のような報告から始まり、限られた時間・信頼度・アクセス権の中で診断を確定する構造なので、技術診断ラウンドの縮図として使えます。使い方を三つ提案します。
- 声に出して解く。ミッションの選択肢を選ぶ前に、なぜその選択なのかを本番の面接のように言葉で説明してから選んでください。声に出して考える訓練がそのままできます。
- ロールを替えながら解く。単独消防士、常駐、プリセールスPoC、引き継ぎの四つのロールは勝利条件が違います。特にプリセールスPoCロールは、ケーススタディラウンドの感覚と重なります。
- ドメインレベルでギャップを探す。ミッションで繰り返し詰まるドメインが、面接前に補強すべきドメインです。FDEカリキュラム ロードマップでそのドメインのチェックリストを埋めてください。
最後の助言 — 「分かりません」を上手に言える人が受かる
FDE面接のすべてのラウンドは、知らないことが出てくるように設計されています。未知の環境こそが職務の本質なのだから当然です。だから最後の採点項目はキャリブレーションです。知っていることと知らないことの境界を正確に引き、知らない区間では原理から推論して確認方法を提示すること。「その部分は運用した経験がありません。原理から推論するとこうなるはずで、実際にはこう確認します」という文の構造を体に入れておいてください。現場で危険な決定をしにくい人だという信号であり、面接官はまさにそれを探しています。
この記事でFDE完全ガイドシリーズは終わりです。定義から面接まで来ましたが、順番どおりに読んでいなければ、下のリストから空白を埋めてください。
手を動かして練習する
- FDEエンジニア育成RPG — 31ミッション、6つの点検シナリオ、4ロール、8ドメイン。このシリーズ全体の実習場です。
- FDEカリキュラム ロードマップ — 10ドメイン65スキルのセルフチェックリスト。
FDE完全ガイドシリーズ全体
- FDE(Forward Deployed Engineer)とは何か — 顧客の現場に配置されるエンジニア
- FDEスキルマップ — 8ドメインの最低ライン、実務ライン、確認質問
- FDEオンボーディング90日 — 把握、単独チケット、主導ミッションの3か月
- FDE障害診断プレイブック — アクセス権から報告書まで6ステップ
- 「遅いんです」をエンジニアリングの問題に翻訳する — FDEの顧客コミュニケーション
- PoCはなぜ本番にたどり着けないのか — 成功基準、セキュリティレビュー、引き継ぎ
- バックエンド・DevOps・データエンジニアからFDEへ — 6か月の転換ロードマップ
- FDE面接準備 — この記事です。