FDEの面接・選考｜典型的なフローと聞かれること、準備のしかた
FDEの選考でもっとも多い失敗は、通常のソフトウェアエンジニア選考と同じ準備をして臨むことです。コーディングは確かに見られますが、それだけでは通りません。曖昧な問題を構造化する面接や、顧客とのやり取りを想定した面接が入るのがこの職種の特徴です。この記事では、執筆時点(2026-08)で公開情報から確認できる範囲の選考の形と、準備のしかたを整理します。
結論から
- FDEの選考は、技術力・課題分解力・顧客対応力の3方向で見られます。コーディングができても、要件が曖昧な状況での進め方を説明できないと通りません
- 典型的なフローは、書類・カジュアル面談 → 技術スクリーニング → 実装またはシステム設計 → 課題分解やケース形式の面接 → 顧客対応を想定した面接 → 最終面接、という構成です。企業により回数と順序は変わります
- 準備の中心は新しい対策ではなく、過去の案件の棚卸しです。「何が曖昧だったか」「なぜその設計にしたか」「顧客とどう合意したか」を、案件ごとに言語化しておくのが最短です
普通のエンジニア選考と何が違うのか
通常のソフトウェアエンジニア選考は、与えられた問題を正しく速く解けるかを中心に見ます。問題は面接官が定義してくれます。FDEの選考は、この前提が外れます。問題そのものが曖昧なまま渡され、それをどう構造化し、何から手をつけるかまでが評価対象になります。
理由は業務の実態にあります。FDEは、顧客が「AIで何かしたい」としか言えない状態から入り、使えるデータを確かめ、効果が出そうな業務を選び、動くものを短期間で出すことを求められます。選考はその縮小版になるわけです。
もう1つの違いは、コミュニケーションが加点ではなく必須要件として見られることです。通常のエンジニア選考では、実装が正しければ多少説明が拙くても通ることがあります。FDEでは、説明の分かりやすさや、相手の前提を確認しながら進める姿勢そのものが評価項目に入ります。この職種は顧客の前に立つため、社内向けの説明力だけでは足りません。
典型的な選考フロー
企業や年によって構成は変わりますが、執筆時点(2026-08)で候補者向けの解説記事や体験記に共通して現れる要素をまとめると、おおむね次の流れになります。国内企業の場合は回数が少なく、外資AI企業の場合は多くなる傾向があります。
全体の期間は数週間から1か月半程度になることが多いようです。ただし、これは公開されている候補者側の情報を集めた傾向であり、企業が公式に開示しているものではありません。実際の回数と内容は、応募先の採用担当に直接確認してください。
| 段階 | 見られていること | 準備の要点 |
|---|---|---|
| 書類・カジュアル面談 | なぜ普通のエンジニア職ではなくFDEなのか | 顧客と向き合う仕事を選ぶ理由を、自分の経験に紐づけて説明できるようにする |
| 技術スクリーニング | 実装の基礎体力。詰まったときの進め方 | 普段使う言語で、考えながら書く様子を口に出す練習をしておく |
| 実装 / システム設計 | AIプロダクトを業務に載せる設計ができるか | LLMを使った機能の構成、評価のしかた、失敗時の扱いを説明できるようにする |
| 課題分解・ケース形式 | 曖昧な問題を構造化し、優先順位をつけられるか | 前提を確認する質問から始める。いきなり解に飛ばない |
| 顧客対応を想定した面接 | 相手の理解度に合わせて説明できるか。反論への対応 | 非エンジニアに技術的な制約を説明した経験を用意しておく |
| 最終・カルチャー面接 | 裁量の大きい環境で自走できるか | 指示がない状況で自分から動いた具体例を1つ以上持っておく |
コーディング面接で本当に見られていること
FDEのコーディング面接は、アルゴリズムの難問を高速で解く形式とは限りません。むしろ、実務に近い題材が出ることが多いようです。たとえば、汚れたデータを扱う処理を書かせる、APIを呼んで結果を組み立てる、といった内容です。
評価されているのは、正解に到達したかどうかだけではありません。要件が足りないときに質問できるか、自分の書いたコードの弱点を自分で指摘できるか、時間内に「動くところまで」持っていく判断ができるか。FDEの現場では、完璧な設計より、期限までに顧客が触れるものを出せるかが効きます。面接もそこを見ています。
なお、AIコーディング支援ツールの使用可否は企業によって方針が分かれます。禁止としている選考もあるため、事前に確認しておくのが安全です。
課題分解の面接——ここが一番落ちやすい
FDE選考の特徴的な部分がこれです。「ある業界の会社が、こういう困りごとを抱えている。どう進めるか」というような、範囲の広い問いが渡されます。Palantirの選考ではこの形式が代表的な段階として知られており、AI企業の選考でも同種の面接が入ることが多いようです。
落ちる典型は、いきなり解決策を話し始めることです。前提を確認せずに「RAGを組んで」と言い出すと、その時点で評価が下がります。まず、誰が困っているのか、今どう回しているのか、どんなデータが実在するのか、成功をどう測るのかを確認する。そのうえで、扱う範囲を意図的に狭め、最初の2週間で何を出すかまで具体的に示す。この順番が守れているかどうかが見られています。
準備としては、想定問答を暗記するより、自分が実際に担当した案件を同じ形式で説明し直す練習が有効です。当時どこが曖昧で、何を確認し、なぜその範囲から着手したのかを口頭で3分にまとめられるようにしておくと、初見の題材でも同じ骨格で話せます。
顧客対応・ロールプレイ形式への備え
面接官が顧客役になり、要望を伝えたり、こちらの提案に反論したりする形式が入ることがあります。難しい顧客をどう扱うかというより、技術的に無理なことを無理と伝えつつ、相手を敵にしないで進められるかを見られていると考えてよいでしょう。
ここで効くのは、正直さです。できないことをできると言わない、分からないことは分からないと言って持ち帰る、代わりに何ができるかを示す。この3つが自然にできれば、多くの場合十分です。逆に、その場を取り繕う受け答えは減点されます。FDEは顧客の信頼で仕事が回る職種なので、面接官はそこを厳しく見ます。
英語が必要かは応募先によります。外資系の場合、日本の顧客と日本語で話し、社内は英語という体制が一般的なため、面接の一部が英語になることがあります。求人票に英語要件がどう書かれているかは、応募前に必ず確認してください。日本で募集中の求人は FDE board の求人一覧にまとめてあります。
準備のしかた——案件の棚卸しから始める
新しい対策本を買うより、過去の案件を整理するほうが効果があります。担当した案件を3つ選び、それぞれについて次の項目を書き出してください。書き出す作業自体が、面接で使う言葉を作ります。
加えて、逆質問も準備しておきます。「入社後6か月で何ができていれば成功と見なされますか」「顧客先にいる時間と自社で作業する時間の比率は」「顧客先で見つけた課題を製品に反映する経路はありますか」といった質問は、こちらの理解度を示すと同時に、入社後のミスマッチを減らします。特に、出張や常駐の頻度は求人票に書かれていないことが多いため、選考の中で確認しておくことをおすすめします。
- 着手時点で何が決まっていなかったか。誰に何を聞いて埋めたか
- 選択肢がいくつあり、なぜその設計を選んだか。捨てた案とその理由
- 顧客・利用部門とどう合意したか。反対されたときにどう扱ったか
- 本番に出た後、実際に使われたか。使われなかったなら何が原因だったか
- 自分が書いた部分はどこか。チームの成果と自分の担当を区別して言えるか
よくあるご質問
- アルゴリズムの問題対策はどこまでやるべきですか?
- 基礎的なデータ構造とアルゴリズムは押さえておくべきですが、競技プログラミング水準まで詰める必要は多くの場合ありません。それより、実務に近い題材で手が止まらないことと、書いたコードの弱点を自分で説明できることのほうが効きます。
- 顧客対応の経験がありません。選考は通りませんか?
- 社外の顧客でなくても構いません。社内の利用部門と要件を詰めた経験、非エンジニアに技術的な制約を説明して合意を取った経験は、同じ能力の証明になります。そうした場面を思い出して具体例として用意してください。
- 選考でAIツールを使ってもよいですか?
- 企業によって方針が異なり、明確に禁止している選考もあります。事前に採用担当へ確認してください。禁止でない場合も、ツールに任せきりで自分の判断を説明できない状態は評価を下げます。
- 不採用になった場合、再応募はできますか?
- 多くの企業で一定期間を空ければ再応募が可能です。期間は企業ごとに異なるため、不採用の連絡時に確認するのが確実です。次の応募までに、落ちた段階に対応する経験を積んでおくと通過率が変わります。募集中の求人は FDE board の求人一覧で追え、候補者登録をしておくと条件に合う求人が出たときに連絡が届きます。