FDE 面試與工作現實：高薪、出差、模糊需求與職涯出口

FDE 的職缺文案很容易讓人只看到兩件事：高薪與站在 AI 落地第一線。真正影響你能否長期做下去的，往往是後半句沒寫完的工作條件：模糊需求、客戶期限、出差、多案切換，以及「先交付」和「做成可維護產品」之間的拉扯。

FDE = Forward Deployed Engineer，前線部署工程師。面試要驗證的也不只是會不會呼叫 LLM，而是能否從不完整問題一路做出可上線、可採用、可回復的系統。

面試通常在看四種能力

1. Coding：在限制下完成可靠功能

Palantir 官方說明指出，工程職的電話面試會包含 coding，時間通常為 20–45 分鐘；整體流程可能先有一至兩次電話面試，再進入 onsite，而且會依候選人與職務調整。這不等於所有 FDE 都採相同題型。

準備時除了資料結構，也要練 API、資料轉換、錯誤處理、測試與閱讀既有程式。Twilio 的職缺直接列出 API design、architecture、testing/debugging、version control、CI/CD，說明 production 習慣本身就是面試訊號。

2. 問題拆解：把模糊需求變成可驗收範圍

案例可能只給一句：「客服回覆太慢，想用 AI。」先問使用者、決策、資料、權限、錯誤代價與基準流程，再定義第一個可逆試點。直接跳到 RAG 或 Agent 架構，通常代表你在解自己熟悉的題，不一定是客戶的題。

一個好的答案會主動切開假設、已知、未知、風險與成功指標，並說明如果兩週內資料不可用，會如何縮小範圍。

3. 系統設計：AI 只是整條鏈的一環

你可能需要設計多租戶 copilot、文件處理、Agent tool 或模型 gateway。回答至少覆蓋資料流、身份與 RBAC、模型與 prompt 版本、eval、觀測、成本、人工覆核與 rollback。

如果只談向量資料庫與模型選型，沒有說 prompt injection、敏感資料、供應商故障和降級路徑，仍停在 prototype 思維。

4. 客戶溝通：能否在壓力下保留工程判斷

面試官可能扮演急著上線的主管、懷疑系統的使用者或要求特例的客戶。不要只說「可以做」或「技術上不行」；先重述目標，列出代價，提供可逆選項，再確認誰擁有風險決策。

準備三個 STAR 案例：你如何發現需求理解錯誤、如何拒絕不安全的交付、如何把一次性需求改成可重用能力。每個故事都要說清楚自己的決策，而不是只說團隊做了什麼。

用作品集準備，而不是背標準答案

企業客服工單 copilot 作品集可同時支援四類面試。Coding 題談 API 與測試；系統設計談權限、eval、觀測與 rollback；客戶題談需求修正；行為題談你如何在速度與風險間取捨。

另外準備一頁「如果多兩週，我不會加什麼功能」。能說明非目標與剩餘風險，比列出更多框架更像真正的交付者。

高薪怎麼讀才不會誤判

截至 2026 年 8 月，OpenAI 西雅圖 FDE 的官方年薪區間為 USD 162,000–280,000，另有股權；Harvey 紐約 Senior FDE 為 USD 200,000–260,000，另有股權與可能的獎金。這兩筆資料只能代表美國特定公司、城市與職級的公開區間。

比較 offer 時至少拆開：

base、bonus、equity 與 vesting
城市生活成本、稅與醫療
職級、值班、出差與工時邊界
同時服務的客戶數與交付週期
是否有產品團隊接手可重用能力

台灣相關職稱常分散在 AI 技術顧問、Solutions Architect、Implementation 或 Technical Account Manager。少量在架職缺不足以建立平均薪資；應記錄平台、查詢日期、公司與職責，再比較個別 offer。不要把美國資深職缺直接換算成台幣期待。

出差與 context switching 是工作設計，不是小缺點

OpenAI 西雅圖職缺明列最多 50% travel。即使沒有搭飛機，跨時區會議、客戶現場與多案切換也會壓縮深度工作。面試時應問得具體：

過去三個月，團隊實際出差多少天？
一位 FDE 同時擁有幾個 deployment？
緊急需求由誰排序，能否拒絕客製？
上線後誰 on-call，何時交給產品或支援？
客戶現場時間是 discovery、build，還是培訓與救火？

出差不是一定不好。對喜歡快速理解產業、直接看到採用的人，它可能是學習加速器；對需要固定照護安排、長時間專注或不喜歡頻繁社交的人，則是實質限制。

工作最大的結構風險：變成一次性客製工廠

FDE 夾在客戶急迫需求與產品可維護性之間。若公司沒有清楚的產品化機制，每個 deployment 都可能長出特殊分支，工程師逐漸只剩救火與協調。

面試時問：「三個客戶要求相似功能時，誰決定做進核心產品？」「過去半年有什麼客戶成果回到 roadmap？」如果答案永遠是各案自己維護，就要把長期技術債算進職涯成本。

另一個風險是績效只看營收或客戶滿意，卻沒有程式品質與平台責任。這類工作仍可能適合擅長顧問交付的人，但若你的目標是深度工程職涯，要確認能否持續擁有 production code。

職涯出口取決於你留下什麼資產

FDE 可以往產品工程、平台／基礎設施、Solutions Architecture、產品管理、技術顧問或 deployment leadership 發展。關鍵不是職稱，而是每次專案後留下的可轉移證據：

把重複需求抽成平台能力，而不是永久客製
對 production code、測試、可靠性與成本有所有權
能用客戶訊號影響 roadmap，也能拒絕錯誤需求
保存系統設計、事故回顧、採用實驗與跨團隊決策

若兩年後履歷只剩公司名稱與「與客戶密切合作」，出口會變窄；若能說清楚如何把三個 deployment 的共通需求產品化、降低維護面積並改善採用，就能回到產品與工程角色。

在投遞前，先回到 FDE 完整指南確認閱讀缺口；如果還沒有可用案例，依三種背景的 90 天路線先做出一份完整證據。

常見問題

FDE 面試一定會考 LeetCode 嗎？

沒有統一流程。Palantir 官方說工程職電話面試會包含 coding，後續採 competency-based 且流程因人而異；其他公司可能更重視系統設計、案例拆解或實作。

FDE 都需要大量出差嗎？

不一定，但必須逐職缺確認。OpenAI 西雅圖職缺明列最多 50% 出差；其他團隊可能遠端或區域型服務。也要問 on-site、時區與同時服務的客戶數。

做 FDE 之後還能回產品工程嗎？

可以，前提是持續累積可轉移的 production ownership、系統設計與產品化成果。若工作只剩一次性客製與協調，回產品工程時就要額外補強深度與長期維護證據。