The FDE Portfolio in 2025: Projects That Prove You Can Ship in Chaos

Why Generic CRUD Apps Fail the FDE Screen

A standard full-stack portfolio—React frontend, Node backend, PostgreSQL—signals you can build greenfield apps. It does not signal you can parachute into a Fortune 500 bank running COBOL on mainframes, ingest their malformed XML exports, and ship a working AI prototype by Friday. Forward Deployed Engineers are evaluated on their ability to navigate technical chaos, not their ability to follow a tutorial.

In 2025, the FDE hiring bar has shifted. Hiring managers at Palantir, Google Cloud, and AI-native startups are scanning GitHub profiles for specific signals: messy real-world data pipelines, prompt engineering that handles edge cases, and post-mortems that prove you can debug systems you didn't build. If your pinned repos are generic bootcamp projects, you will be filtered out before a recruiter ever reads your resume.

The "forward deployed engineer github" search intent is clear: engineers want concrete project ideas that demonstrate FDE-specific skills. They want to know what to build, how to structure the repo, and what technical decisions signal seniority. This playbook breaks down the four project archetypes that consistently get interviews at top FDE organizations, with real stack recommendations and architecture decisions.

The 4 Project Archetypes That Get Interviews

Based on analysis of FDE hiring rubrics and interviews with hiring managers, four project archetypes consistently outperform generic portfolios. Each maps to a core FDE competency: data integration, prompt engineering, debugging, and demo craftsmanship.

Each archetype should be a standalone GitHub repo with a README that tells the story: what problem existed, what constraints you faced, what you built, and what you learned. The narrative matters as much as the code.

Archetype 1: The Data Integration Bridge

FDEs spend 40-60% of their time on data integration: pulling data from customer systems, transforming it, and loading it into the platform. Your portfolio should demonstrate you can handle the messy reality of enterprise data.

What to build: A pipeline that ingests data from a real public source with inconsistent schema (e.g., SEC EDGAR filings, HL7 healthcare messages, or legacy SOAP APIs), normalizes it, and exposes it via a clean REST or GraphQL endpoint. Bonus points for handling partial failures, schema evolution, and backpressure.

Stack recommendation: Python with Prefect or Dagster for orchestration, DuckDB for in-process analytics, and Pydantic for schema validation. Avoid Airflow for portfolio projects—it signals over-engineering for a single-node pipeline.

Key signals in your repo:

• A schema_evolution.md doc explaining how you handle new fields appearing in source data
• Unit tests that inject malformed data and verify graceful degradation
• A runbook.md with operational procedures for common failure modes
• Logging that would actually help you debug at 2 AM

Example project: "SEC Filing Normalizer"—a pipeline that ingests XBRL filings from the SEC EDGAR API, handles the 40+ form types with different schemas, and exposes a unified financial metrics endpoint. This demonstrates you can work with real government data formats, which are notoriously inconsistent.

Archetype 2: The Prompt-Engineered Workflow

In 2025, every FDE is expected to ship LLM-powered features. But calling openai.ChatCompletion.create() in a Jupyter notebook does not prove competence. You need to demonstrate prompt engineering rigor: structured output parsing, evaluation frameworks, and handling the long tail of edge cases.

What to build: A tool that takes unstructured input, applies a multi-step LLM pipeline, and produces structured, validated output. The key is showing your work: include your prompt iterations, your eval set, and your failure analysis.

Stack recommendation: Instructor or Outlines for structured output, LangFuse or Braintrust for observability, and pytest for eval harnesses. The actual LLM provider matters less than your evaluation methodology.

Key signals in your repo:

• A prompts/ directory showing v1, v2, v3 of each prompt with comments on why you changed them
• An evals/ directory with a held-out test set and metrics (precision, recall, exact match)
• A failure_analysis.md documenting the 5 most common failure modes and your mitigations
• Handling of adversarial inputs: empty strings, 10MB inputs, prompt injection attempts

Internal link: For a concrete example of shipping an LLM-powered tool that handles real-world chaos, see how we built a personal meeting notetaker that transcribes, summarizes, and extracts action items. The project demonstrates structured output extraction from messy transcripts—exactly the skill FDE hiring managers evaluate.

Archetype 3: The Debugging Post-Mortem

FDEs debug systems they didn't build, often with incomplete logs and an impatient customer on the line. A post-mortem repo demonstrates you can systematically diagnose and fix problems under pressure.

What to build: This archetype is a written artifact, not a running system. Reproduce a real bug from an open-source project, document your debugging process, and submit the fix. The repo should read like a detective story: symptoms, hypotheses tested, dead ends, and the eventual root cause.

Structure:

• README.md with the executive summary: what broke, impact, root cause, fix
• timeline.md with a minute-by-minute debugging log
• hypotheses.md with each theory you tested, how you tested it, and why it was wrong or right
• fix/ directory with the actual code change
• prevention.md with recommendations for monitoring, testing, or architectural changes

Choosing a bug: Pick something non-trivial—race conditions, memory leaks, or distributed consensus bugs are ideal. Avoid one-line typo fixes. The bug should require instrumentation, log analysis, or reading source code you didn't write.

Example: Reproduce and fix a PostgreSQL query planner edge case where a specific JOIN order causes a 1000x performance regression. Document how you used EXPLAIN ANALYZE, identified the bad cardinality estimate, and implemented a fix using extended statistics.

Archetype 4: The High-Stakes Demo

FDEs don't just ship code—they ship conviction. A demo that closes a deal requires UX polish, narrative structure, and the ability to handle live questions without the whole thing falling over. Your portfolio should include a demo that feels product-grade, even if the backend is held together with duct tape.

What to build: A full-stack application that solves a specific, painful problem for a real persona. The key is the demo experience: it should work on the first try, have a clear "aha moment" within 30 seconds, and handle the obvious edge cases gracefully.

Stack recommendation: Next.js for the frontend (fast, SEO-friendly, and what many FDE teams use for demos), FastAPI or Hono for the backend, and SQLite or Turso for the database (zero-config, portable). Deploy on Vercel or Fly.io with a real URL.

Key signals in your repo:

• A DEMO_SCRIPT.md that reads like a sales narrative: persona, pain point, before/after
• Error states that look intentional, not like crashes
• Loading states, empty states, and edge case handling
• A 2-minute screen recording (Loom or similar) embedded in the README

Internal link: The FDE toolkit article covers the exact stack and workflow FDEs use to ship demos that close deals, including data integration patterns and demo-specific UX decisions.

Architecture and Stack Decisions

FDE portfolios are evaluated on technical judgment, not just code volume. Every technology choice should have a rationale. Here are the decisions that signal seniority in 2025.

Python vs. TypeScript: Python remains the lingua franca for data integration and AI. TypeScript is preferred for full-stack demos. If you're building a data pipeline, use Python. If you're building a demo, use TypeScript. If you use both in the same project, explain the boundary.

Databases: SQLite is underrated for FDE portfolios. It's zero-config, portable, and fast enough for demos. PostgreSQL signals you can manage infrastructure, but only if your project actually needs it. DuckDB is an excellent choice for analytical pipelines—it signals you understand the OLAP vs. OLTP distinction.

LLM providers: Don't just use OpenAI. Demonstrate you can evaluate and switch between providers. A project that uses Anthropic for complex reasoning and Groq for latency-sensitive tasks shows you understand the LLM landscape. For local inference, see how to run a 26B model on 2 GB RAM using your Mac's neural engine.

Orchestration: Prefect or Dagster for Python pipelines. Temporal for long-running workflows. Avoid Airflow for portfolio projects—it's heavyweight and signals you cargo-culted a tutorial.

FAQ: FDE Portfolio

Q: How many projects should my FDE portfolio have? Three to four high-quality repos is ideal. One data integration pipeline, one LLM workflow, one debugging post-mortem, and one polished demo. Depth over breadth—a single repo with excellent documentation and testing beats ten half-finished projects.

Q: Should I include projects from my current job? If you can open-source them, yes. If not, write a detailed case study (redacting sensitive details) and link to it from your GitHub profile README. Hiring managers understand that the best work is often proprietary.

Q: Do I need to contribute to open source? It helps but isn't required. A well-documented post-mortem with a fix submitted to a major project is more impressive than 50 documentation typo fixes. Focus on depth.

Q: What about the Google FDE interview specifically? Google's FDE interview includes a debugging round and a demo round. The debugging post-mortem archetype directly prepares you for the debugging round. For the demo round, practice building something in 45 minutes that solves a problem for a specific persona. See the FDE interview loop breakdown for a detailed walkthrough of each round.

Q: How important is the README? It's the most important file in your repo. Hiring managers spend 30-60 seconds scanning a repo before deciding whether to look at the code. A README that tells a clear story—problem, constraints, solution, lessons learned—will get your code read. A bare npx create-react-app README will get you skipped.

Q: Should I deploy my projects? Yes, for demos. A live URL with a working demo is 10x more convincing than screenshots. Use Vercel, Fly.io, or Railway for free tiers. For data pipelines, include sample output and a link to a live dashboard if possible.

Q: What about FDE salary expectations? In 2025, entry-level FDE roles at top firms range from $130K-$180K base, with total compensation (including equity and bonuses) reaching $200K-$300K. Senior FDEs at Palantir and Google Cloud can exceed $400K total compensation. Your portfolio is the primary leverage in negotiating at the top of the band.

Ready to build projects that prove you can ship in chaos? FDE Coach provides the concrete playbooks, code templates, and evaluation rubrics that get engineers hired at top FDE organizations.