Why Forward Deployed Engineer — not pure SWE or pure Architect

Expected question

"Why Forward Deployed Engineer — not a regular SWE or Principal Architect-only role?"

Variant forms

• "Why customer-facing technical work instead of core platform engineering?"
• "What does FDE mean to you at this company?"
• "Walk me through embedding with a business team and owning the outcome end-to-end."
• "Why not Solutions Architect / Sales Engineer?"
• "Describe your first 30/60/90 days as an FDE."
• "This role is 50–75% travel / customer-site weeks. What's your plan?"
• "How is FDE different from consulting?"
• "Why this company specifically?"
• "Convince me you won't quit back to pure eng in a year."
• "Walk me through a system you took from nothing to production. What broke?"
• "How comfortable are you spending half your week in front of customers?"
• "Tell me about learning an unfamiliar domain fast — how did you validate understanding?"
• "Anthropic/OpenAI: why Applied AI / FDE here — and how do you think about deployment risk?"

Where this actually gets asked

Recruiter and hiring-manager screens at OpenAI FDE, Anthropic Applied AI, Palantir FDSE, Databricks FDE, and Cohere. It is a flight-risk and motivation filter, not small talk. Generic “I like people” answers fail; answers without a shipped embed story fail.

The question, as it might actually be asked

"Why FDE specifically — not SWE or Architect-only? Connect it to something you actually shipped."

The framework

30-second thesis

I'd rather own the mess between a capable model and a real workflow than polish a platform nobody has adopted yet. I've done that as an internal embed at Lucid — Supply Chain / Commerce partners, thin wedges, HITL on irreversible paths — and I want the same job with external customers. I still design control planes. FDE is where that design has to survive SSO, change windows, and a sponsor who cares about the metric, not the ADR.

2-minute answer

FDE, to me, is post-sale ownership. You sit with the people who live in the workflow, find the smallest thing that moves a 90-day number, wire it into their identity and systems of record, put humans in front of anything irreversible, and leave someone who can run it when you walk away.

That's different from core SWE — you're not shipping one product for thousands of tenants. It's different from SE — you don't stop when the deal closes. And it's different from Architect-only — you don't get to stop at the slide.

What I've actually done: at Lucid I embedded with Supply Chain and Commerce (P). We didn't start with "dozens of agents." We picked high-volume exception / ops paths, shipped RAG + specialized agents into the real event plane, and put human confirmation on high-risk writes. Baselines and savings claims only when I can explain the window — otherwise I label them H.

The public stack — AegisAI, VAP, Enterprise RAG, governed publish — is how I build: gateway + HITL, orchestration, access-aware retrieval, eval gates. One brand. Not a claim Lucid runs those repos, and not a different persona for each company I interview with.

I still want Architect depth. FDE is where that depth meets adoption.

Anti-patterns: “I like talking to people,” compensation-only, flight-risk vibe, inventing external logos, or pretending you never want architecture depth.

Travel plan (pass signal): state a sustainable % and cadence — support logistics included — not enthusiasm alone. (CONFIRM what you'll say publicly.)

Safety / Applied AI: irreversible tools get HITL until evals say otherwise; deployment risk is wrong writes and silent wrong answers, not brand damage.

Requirements (what a strong Why-FDE answer must cover)

Functional

• Tie motivation to a real embed story with a business outcome.
• Distinguish FDE from SWE / SE / Architect without insulting those roles.
• Name a 30/60/90 operating plan.

Non-functional

• Honest evidence classes (P vs O).
• Travel/site willingness without overclaiming years of customer residency.
• Safety/eval instinct for Applied AI labs.

Core entities / actors

• Customer / internal customer: the team whose workflow must change.
• Sponsor: named owner of the 90-day metric.
• FDE: temporary critical-path owner who must exit.
• Platform / product: receives reusable patterns after the deploy.

Process flow — 30/60/90

Rendering architecture diagram…

1. 1–30: learn product, shadow calls, ship one integration win.
2. 31–60: own one deployment end-to-end + one reusable connector.
3. 61–90: spot a cross-account pattern; propose tooling/process that raises team throughput.

Deep dive 1: why not stay Architect-only?

Elegant platforms are easy to love. Week-one value under someone else's change window is harder. I'd refuse to stay Architect-only if that meant I never had to ship a walking skeleton into a hostile identity plane. I keep Architect depth for the control plane — gateway, access-aware RAG, evals — and use FDE motion for adoption. Same person, different first sentence depending on the seat.

Deep dive 2: flight-risk answer

I'm not sampling FDE because SWE loops were competitive. The work that keeps me engaged is ambiguous ops under constraints — the same rooms I've already been in at Lucid. Retention signal: I already do this motion and publish how I build (/fde, open stack). Not “I want to try customer work someday.”

Deep dive 3: company-specific close

Name their product and customer type — Claude Enterprise, lakehouse + Mosaic, ontology/AIP, on-prem Cohere — then map the same brand: governed agents, HITL, evals, access-aware RAG. Don't invent a new persona card per logo. Generic “famous AI company” fails.

Quantitative trade-offs

Situation

At Lucid Motors I operate as Sr. Staff across Software Architecture and full-stack delivery while partnering daily with Supply Chain, Commerce, Sales, and Service clusters. The work is not “build a demo in a lab” — it is embedding with business stakeholders who own EDI exceptions, payments-adjacent workflows, and event-driven integrations, under real change-control and risk constraints (P, resume).

Task

Own end-to-end outcomes for production AI wedges in those business areas: clarify the workflow, decide what ships first, integrate into existing systems, govern irreversible actions, and leave measurable adoption — the same muscle FDE interviews hire for, framed honestly as an internal customer embed rather than invented third-party logos.

Action

1. Scoped wedges, not platform theater: high-volume exception / ops paths first — RAG + specialized agents before “agents everywhere.”
2. Hardened irreversible paths: human confirmation before high-risk writes; access-aware retrieval instincts for enterprise data.
3. Integrated into the real plane: Kafka/MSK-style paths and systems of record — not a parallel demo stack.
4. Defended outcomes with baselines: vendor/infra savings and ownership transfer only with windows I can explain (P); otherwise H.
5. Published method proof (O): AegisAI gateway/HITL, VAP, Enterprise RAG, governed publish — how I build. Explicitly not “Lucid runs these repos.”

Result

A story panels can pressure-test: internal-customer embed plus governed-agent platform depth. One brand on the public site (venkat-ai.com/fde) — Architect who ships like an FDE — not two personas. Residual gap: timed voice mocks and a travel % stated on LinkedIn (CONFIRM).

The follow-up question you should expect

"So are you an Architect or an FDE?"
Both. I design the control plane and I stay until the wedge runs under their constraints. For Architect seats I lead with multi-team standards and ADRs. For FDE seats I lead with discovery → wedge → handoff. Same facts. Different first sentence.

What I'd ask them

1. What does “deployed” mean here — demo in their VPC, or a workflow with a named owner after we leave?
2. What's the travel / site cadence for this team in the next two quarters?
3. When a customer wants autonomy on an irreversible tool, who owns the no?

Candidate-owned evidence prompts

1. Which Lucid workflow will you name in the 60s opener (Supply Chain vs Commerce)?
2. What exact baseline window supports any $ savings claim?
3. What travel % will you state publicly?
4. Which O repos will you invite the panel to click before the loop?

Author reference (do not memorize)

Treat STAR sections as templates. Convert to “I” claims only with evidence-ledger provenance.

Staff+/Principal signal rubric

• Mid-level: Says customer-facing without a shipped embed story.
• Senior: One concrete internal/external customer deploy with a metric.
• Staff+: Clarifies FDE vs SWE/SE/Architect; wedge-first method; governance on irreversible actions; handoff ownership.
• Principal: Dual Architect+FDE without confusion; turns customer pain into product feedback; company-specific close on one brand.

Related

• 03-customer-discovery-to-mvp-wedge.md
• 06-enterprise-discovery-call-vp-chatbot.md
• ../behavioral/05-leading-a-0-to-1-ai-product-build.md
• ../docs/FDE_APPLIED_AI_QUESTION_BANK.md