The FDE Portfolio: What to Build to Get Hired at Top AI and Enterprise Companies

You don't need a portfolio of 15 polished side projects. You need 3 specific artifacts that prove you can do the job before you get the job. The Forward Deployed Engineer interview loop isn't just about passing coding challenges—it's about demonstrating you can navigate a customer's messy reality, stitch together APIs that were never meant to talk to each other, and ship working software in a conference room.

This playbook breaks down exactly what to build, why each project signals a specific FDE competency, and the technical decisions that separate a portfolio that gets skipped from one that gets you on a plane to a client site.

The FDE Portfolio Mindset: Signal Over Volume

A standard SWE portfolio showcases depth: a complex compiler, a distributed database, a game engine. An FDE portfolio showcases breadth under constraint. Hiring managers at Palantir, Scale AI, C3 AI, and the emerging crop of AI-native FDE teams are scanning for three specific signals:

1. Integration survival instinct — Can you ingest data from a legacy on-prem Oracle database, transform it, and pipe it into a modern cloud service without losing your mind?
2. Accelerated time-to-value — Did you identify a manual workflow that takes a customer 4 hours and reduce it to 4 minutes with a script, a UI, or an agent?
3. Technical communication under pressure — Can you explain your architecture to a non-technical VP and a skeptical staff engineer in the same conversation?

Your portfolio must scream these three things within 60 seconds of a reviewer opening your GitHub profile.

The 3-Project Matrix That Covers the FDE Spectrum

Forget the "full-stack CRUD app with auth." Here's the matrix that maps directly to the phases of an FDE engagement:

Each project should live in its own public repo with a README that follows the FDE README template we'll cover later.

Project 1: The Integration Gauntlet (Enterprise Data Flow)

This is the non-negotiable. Every FDE spends 40-60% of their time moving data between systems that were never designed to integrate. Your portfolio must prove you can do this gracefully.

The Spec

Build a pipeline that:

• Extracts data from a "legacy" source (simulate this with a CSV export from a mock SAP system, a SQLite database, or a rate-limited REST API you mock with a 2-second delay and occasional 500 errors).
• Transforms the data through a cleansing and enrichment step. Use real-world messiness: duplicate rows, missing fields, date formats like MM/DD/YYYY mixed with YYYY-MM-DD, and a column that requires a regex extraction.
• Loads the clean data into a modern destination (PostgreSQL, Airtable, or a vector database like Qdrant if you want to stretch).
• Handles failure with retry logic, a dead-letter queue (even if it's just a JSON file), and structured logging.

Technical Stack Recommendations

Don't reach for a heavy orchestration framework. Use Python with httpx for async HTTP, tenacity for retries, and structlog for structured logging. Containerize the whole thing with Docker and provide a docker-compose.yml that spins up the source mock, the pipeline, and the destination.

The Signal

When I review this project, I look for:

• Idempotency: If I run the pipeline twice, does it create duplicate records? Show me you used upsert logic.
• Observability: Does the pipeline emit structured logs I could ship to Datadog or Grafana? Include a log line that says {"event": "row_processed", "row_id": 123, "status": "success", "duration_ms": 45}.
• Configurability: No hardcoded API keys or connection strings. Use environment variables and a .env.example file.

This project alone can carry a portfolio if it's done with production-level attention to detail. For a deeper dive into the enterprise integration patterns that FDEs live and breathe, read our breakdown of How Palantir-Style FDEs Embed with Customers to Unlock Technical Value.

Project 2: The Workflow Accelerator (The "Shadow IT" Killer)

FDEs are hired to make customers faster. The second project in your portfolio should demonstrate you can spot a manual, multi-step business process and collapse it into a single command or button click.

The Spec

Find a real workflow you or someone you know does manually. The best ones are:

• A sales team manually researching prospect companies before a call.
• A support team copying data from Zendesk into a spreadsheet for weekly reporting.
• A developer manually reviewing PRs for obvious issues before assigning human reviewers.

Then automate it end-to-end. Two strong options that map directly to FDE work:

Option A: Lead-Enrichment Agent — Build a tool that takes a company name, uses Playwright to scrape their website and LinkedIn (headless browser, handle consent banners), extracts key information with an LLM, and outputs a structured JSON brief. This is exactly the kind of "quick win" an FDE ships in week 1 of an engagement. We have a full walkthrough on building this exact system: Build a Lead-Enrichment Agent that Researches Companies Using Playwright and Gemini.

Option B: PR Review Bot — Build a GitHub App that triggers on new PRs, sends the diff to an LLM for analysis, and posts an inline review comment flagging potential bugs, security issues, or style violations. This proves you understand event-driven architecture and API integrations. Step-by-step guide here: Build a GitHub PR Review Bot that Comments on Code with Groq's Free API.

The Signal

This project proves you understand the economic value of FDE work. In your README, quantify the time saved: "This automation reduces a 45-minute manual research process to 90 seconds." That sentence alone will get you an interview.

Project 3: The AI-Forward Prototype (Zero-to-Value in a Week)

As of 2025, FDE is the hottest role in AI because companies need people who can turn foundation model capabilities into customer value without waiting for the product team to ship a feature. Your third project proves you can do this.

The Spec

Build something that would have been impossible without LLMs 3 years ago, and make it usable by a non-technical stakeholder. Strong options:

• Local RAG Chatbot: A chatbot that answers questions over a set of PDFs, running entirely locally with Ollama. This proves you understand the privacy and air-gapped deployment constraints that enterprise customers demand. Full build guide: Build a Local RAG Chatbot Over Your PDFs with Ollama, LlamaIndex, and Qdrant Free Tier.
• Screenshot-to-Code Agent: A tool where a user uploads a screenshot of a UI mockup and gets back a working React component. This is the kind of "magic" demo that wins customer trust in a pilot. Tutorial: Build a Screenshot-to-React Agent with Google Gemini Flash and Free Hosting.

The Signal

The key here is not the AI—it's the packaging. This project must have:

• A simple UI (Streamlit, Gradio, or a minimal React frontend).
• Clear setup instructions that work on a fresh machine.
• A demo video (2 minutes max, screen recording with voiceover) linked in the README.

The demo video is the most underrated asset in an FDE portfolio. It proves you can communicate technical work to a non-technical audience, which is literally half the job.

How to Present Your Portfolio: The FDE README

Every repo in your portfolio should follow this template. It's modeled after the internal write-ups FDEs produce for customer handoffs.

# Project Name

**Time to Value**: X minutes/hours saved per [week/month]
**Customer Problem**: [One sentence describing the manual pain this solves]

## Architecture

[reactflow]
{"nodes":[{"id":"1","label":"Legacy Source (CSV/SQLite)"},{"id":"2","label":"Python ETL Pipeline"},{"id":"3","label":"Validation & Enrichment"},{"id":"4","label":"Dead Letter Queue"},{"id":"5","label":"PostgreSQL Destination"},{"id":"6","label":"Structured Logging (JSON)"}],"edges":[{"source":"1","target":"2","label":"Extract"},{"source":"2","target":"3","label":"Transform"},{"source":"3","target":"5","label":"Load (Upsert)"},{"source":"3","target":"4","label":"Failed Records"},{"source":"2","target":"6","label":"Logs"},{"source":"3","target":"6","label":"Logs"},{"source":"5","target":"6","label":"Logs"}],"direction":"LR"}
[/reactflow]

## Quick Start

```bash
docker-compose up -d
python -m pipeline --config .env

Design Decisions

• Why async over multiprocessing? This pipeline is I/O-bound, not CPU-bound. httpx.AsyncClient handles 100 concurrent requests with a single event loop, keeping memory footprint low for deployment on constrained customer VMs.
• Why upsert over truncate-and-load? The destination table may have downstream dependencies (foreign keys, materialized views). Upsert with ON CONFLICT preserves referential integrity.
• Why a JSON file dead-letter queue instead of Kafka? Minimizing infrastructure dependencies. In a real engagement, I'd swap this for a Kafka topic or SQS queue once the customer's infra team provisions it.

Failure Modes Handled

• Source API rate limiting (429 responses) → Exponential backoff with jitter
• Malformed source data → Row-level error isolation, logged with row_id
• Destination connection drops → Connection pooling with automatic reconnect
• Duplicate runs → Idempotency key based on source row hash

This README structure does three things: it shows you think in terms of customer value, it proves you make intentional technical decisions, and it demonstrates you anticipate failure modes—the hallmark of someone who's deployed software in the real world.

## FAQ: FDE Portfolio and Career Questions

### How to get into an FDE role?

There are two primary paths. The first is through a company with a formal FDE program—Palantir is the canonical example, but Scale AI, C3 AI, and a growing number of AI startups now have dedicated FDE tracks. These programs recruit from strong CS and engineering programs and value candidates who show integration skill and customer-facing potential. The second path is internal: many FDEs start as solutions engineers, sales engineers, or technical consultants and gradually shift into a role where they're writing production code on customer engagements. A portfolio that demonstrates the three project types above is the single highest-leverage asset for either path. If you're looking to sharpen the specific skills that FDE interviews test, FDE Coach offers focused preparation on the integration patterns, workflow automation, and AI prototyping that hiring managers want to see.

### How to prepare for an FDE interview?

FDE interviews differ from standard SWE loops in three ways. First, expect a "deployment scenario" where you're given a messy dataset or API and asked to build a working integration in 45-60 minutes—practice this with the Integration Gauntlet project above. Second, you'll face a "customer problem" interview where you're presented with a vague business requirement and must scope a technical solution in real-time, asking clarifying questions and making trade-off calls. Third, there's often a presentation component where you walk through a past project—your portfolio READMEs are your rehearsal for this. For a detailed breakdown of the FDE interview process and what to expect at each stage, FDE Coach provides mock interview scenarios based on real loops from top FDE employers.

### Is FDE a good role?

It's the highest-variance, highest-learning role in software engineering. Compensation is strong—FDE roles at top firms typically range from $130K–$220K base with significant equity, and total comp at Palantir for mid-level FDEs can reach $250K–$350K. The trade-off is travel (often 25-50% pre-2020, now more variable) and context-switching intensity. You'll touch more technologies in 18 months as an FDE than most engineers touch in 5 years. The role is an exceptional launchpad into product management, solutions architecture, or founding a startup—many Palantir alumni have gone on to start successful companies precisely because they learned to identify and solve enterprise problems at close range.

### Is FDE a sales role?

No, but it's a *value-unlocking* role that works adjacent to sales. An FDE writes production code, deploys infrastructure, and builds integrations. The distinction: a sales engineer demonstrates what the product *can* do; an FDE makes it *actually work* in the customer's environment. You're not carrying a quota, but your work directly influences expansion revenue. The best FDEs are technically stronger than most product engineers but also comfortable in a customer meeting explaining why a particular integration will take 3 weeks instead of 3 days. If you want to write code and see it used immediately by real users in high-stakes environments, FDE is the right role. If you want to optimize a single codebase in isolation without external interaction, it's not.

### What if I'm a fresh graduate with no enterprise experience?

Build the three projects anyway. For the Integration Gauntlet, use a public dataset (government open data is great—it's always messy) and document the real-world failure modes you encountered. For the Workflow Accelerator, automate something from a past internship, a student organization, or even a personal workflow. The key is demonstrating the *mindset*, not claiming enterprise experience you don't have. When you present these projects in an interview, focus on the decisions you made and the trade-offs you considered. That's what senior FDEs are listening for—not years of experience, but evidence of judgment under constraint.