Build a Forward Deployed Engineer Portfolio on GitHub That Gets Interviews

Why Most FDE Portfolios Fail (And How to Fix Yours)

A Forward Deployed Engineer isn't a pure software engineer. You're a hybrid: part hacker, part consultant, part firefighter. Your GitHub portfolio needs to scream that you don't just write clean code in a vacuum—you ship messy, high-impact solutions into chaotic enterprise environments, often standing next to the customer.

Most portfolios fail because they show only software engineering depth. Pristine LeetCode solutions. A cookie-cutter to-do app. A fork of a popular repo with a one-line README change.

The hiring manager at Palantir, Scale AI, or an AI-native startup is asking three questions when they open your GitHub:

1. Can you build something real that actually works? (Not just a script. A system.)
2. Can you explain it to a customer? (Your README is the proxy.)
3. Did you solve a gnarly, unglamorous problem? (The core of FDE work.)

Your portfolio must answer "yes" with evidence. Here's the architecture to do it.

The FDE Portfolio Architecture: 3 Repos That Prove the Trifecta

You don't need 50 repos. You need three targeted ones that demonstrate the FDE skillset: engineering velocity, customer empathy, and technical communication.

Think of these three repos as your case study portfolio. Pin them to your profile.

Let's break down how to build each one.

Repo 1: The "Zero-to-One" Production System

This is your flagship repo. It's not a "sentiment analysis script." It's a functional, deployed AI system that ingests messy data, does something useful, and has a basic interface.

The bar: A senior engineer should be able to clone it, follow your README, and get it running with minimal fuss.

What to build: A Retrieval-Augmented Generation (RAG) system over a complex, real-world document set. Why? Because 80% of enterprise AI deployments in 2025 are RAG-based, and FDEs are the ones integrating them.

Don't build a chatbot over a single PDF. Build a system that ingests a messy, multi-format knowledge base. Think: an internal docs site scraped to Markdown, with tables, broken links, and inconsistent formatting.

Architecture for a winning project:

Key details that impress FDE hiring managers:

• Hybrid Search: Don't just do semantic search. Implement reciprocal rank fusion (RRF) combining vector and keyword (BM25) search. This solves a real enterprise problem where exact product codes matter.
• Evaluation: Add a scripts/eval.py that runs a set of questions against the system and scores them. This shows you think about quality, not just building.
• Observability: A basic docker-compose.yml with a Grafana or LangFuse container for tracing. FDEs debug live systems; show you can see inside the black box.
• A Justfile: Instead of a long list of commands in the README, use a justfile (like a modern Makefile). It shows you care about developer experience.

For a deeper dive into building reliable AI workflows with a clean architecture, you can apply patterns from domain-driven design. See our guide on Domain-Driven Agents: Bounded Contexts for Reliable AI Workflows.

Repo 2: The Customer-Facing Demo or Micro-SaaS

This repo proves you can close the gap between a working API and a human being who gets value from it. It's not about beautiful UI; it's about solving a specific business pain point with a simple interface.

The bar: A non-technical product manager should understand what it does and why it's valuable within 30 seconds of looking at the README and demo link.

What to build: A single-purpose tool that automates a tedious, manual workflow. The best FDE projects turn a 3-hour manual process into a 5-minute automated one.

Three high-signal project ideas:

1. Cold Outreach Personalizer: Upload a CSV of prospects with their company and title. The app uses an LLM to research their company and draft a hyper-personalized email. This directly mirrors an FDE's work building custom sales tools. You can get a detailed walkthrough of this exact build in our guide: Build a Cold Outreach Email Personalizer From a CSV of Prospects Using OpenRouter Free Models.
2. Customer Support Triage Agent: A simple chat UI that ingests product documentation and answers "how-to" questions. The key is connecting it to a real knowledge base, not a dummy one. See our tutorial on building this with a full modern stack: Build a WhatsApp Customer-Support Agent Backed by Your Docs Using n8n, Supabase Vector, and Gemini.
3. AI-Powered Content Drafter: A tool that takes a rough outline and turns it into a polished draft, like a Twitter thread or a blog post. This shows you understand how to structure prompts for a specific output format. We have a full build guide here: Build a Twitter/X Thread Writer That Drafts From a Rough Outline Using Groq's Llama 3.

Crucial elements for this repo:

• A public demo link: Deploy it on Hugging Face Spaces, Railway, or Fly.io. A live demo is worth 10,000 lines of code. If it's down, the hiring manager assumes you can't run production services.
• A video walkthrough (2-3 minutes): Record a Loom video embedded in the README. Talk through the business problem, show the tool solving it, and briefly touch on one interesting technical challenge. This is your mini "customer demo."
• Environment variable management: Use .env.example clearly. An FDE who commits secrets is an instant red flag.

Repo 3: The "War Story" Technical Deep-Dive

This is your most underrated repo. It's a single, exhaustive Markdown file or a well-documented Jupyter notebook that dissects a hard technical problem you solved. It proves you can write the kind of internal post-mortems and integration guides that FDEs produce weekly.

The bar: An engineer facing a similar problem should find your repo via Google and think, "Thank god, someone has actually documented this."

What to write about:

• A performance optimization deep-dive: How you reduced LLM serving costs by 40% using a specific technique. For example, you could explore how automatic prefix caching works in vLLM. We've broken down the mechanics here: vLLM v0.28.0: How Automatic Prefix Caching Reduces LLM Serving Costs.
• A gnarly integration breakdown: How you reverse-engineered a poorly-documented internal API and built a reliable client for it. Show the packet captures, the trial-and-error, the final elegant solution.
• A security threat model: A detailed analysis of the risks of giving an AI agent root access to a system. This shows you think like an engineer responsible for critical systems. We've published a complete threat model you can use as a reference: Your AI Agent Has Root: Threat Modeling LLM-Driven System Administration.

Structure for the deep-dive:

1. The Problem: What was the business or system impact? (e.g., "Our RAG pipeline cost $500/day to run and had a 5-second latency.")
2. The Investigation: What did you measure? What hypotheses did you disprove? Show your work. Include snippets of your profiling code.
3. The Solution: What was the fix? Explain the trade-offs. Why not a different approach?
4. The Impact: Quantify the result. "Reduced cost by 60% and latency by 40%." Numbers are the universal language of credibility.

The FDE README Formula: Problem, Gnar, Impact

Every README for your three repos should follow a strict formula. This is your written communication test.

# Project Name

**One-liner:** [Action] for [User] to [Solve Problem].

## The Problem
A 2-3 sentence story about the manual, broken, or expensive process this fixes. Be specific.

## Demo
[Link to live demo]
[Screenshot or embedded GIF of the tool working]

## The "Gnar"
What was the single hardest technical challenge? How did you solve it?
*This section alone can get you an interview. It proves you're not just following a tutorial.*

## Quickstart
```bash
git clone ...
cp .env.example .env
# Fill in your API keys
docker compose up

Architecture

[A simple diagram or a bulleted list of components and data flow.]

Impact

• Reduced X by Y%
• Automated a Z-hour manual process
• Handles N requests/day

The "Gnar" section is non-negotiable. It's the first thing an FDE hiring manager will read. If it's missing, they assume you've never solved a real problem.

## Project Ideas That Map to the FDE Interview Rubric

FDE interviews at top firms like Cohere and Anthropic test specific muscles: decomposition, coding, and customer scenarios. For a full breakdown of that process, see our guide: [Inside the Cohere and Anthropic FDE Interview Process: Decomposition, Coding, and Customer Scenarios](/blog/cohere-anthropic-fde-interview-process).

Your portfolio projects should map directly to these interview signals.

| Interview Signal | Portfolio Evidence |
| :--- | :--- |
| **Decomposition** | A complex project broken into clear, independent microservices or modules. Your architecture diagram tells this story. |
| **Technical Breadth** | A stack that spans frontend (Streamlit), backend (FastAPI), infra (Docker), and data (PostgreSQL/Supabase). |
| **Customer Empathy** | A demo video that starts with the business problem, not the tech. A README written for a non-technical user. |
| **Grit/"Gnar"** | A deep-dive repo or a "Gnar" section that details a painful bug, a rate-limiting hell, or a messy data-cleaning saga. |

## Deploying Your Portfolio: Live Demos > Static Code

An FDE's code is never just a repo. It's a running service. Your portfolio must be alive.

- **Hugging Face Spaces:** Best for Streamlit/Gradio demos. Free, easy, and shows up in Google.
- **Fly.io / Railway:** Best for FastAPI backends with a PostgreSQL database. Gives you a real URL and logs.
- **GitHub Actions for CI/CD:** Add a badge to your README that shows the build passing. It's a tiny signal of professionalism. Even better, use GitHub Actions to run your evaluation script (`python scripts/eval.py`) on every push and fail the build if accuracy drops below a threshold.

**The ultimate FDE portfolio move:** Write a blog post about your project and link the repo. It shows you can advocate for your work. The best FDEs don't just build; they teach and document. Monitoring customer health during an AI rollout is a classic FDE responsibility, and documenting your approach to it is a powerful signal. Read more on the signals that matter here: [Reading the Tea Leaves: Customer Health Signals an FDE Monitors During an AI Rollout](/blog/fde-customer-health-signals-ai-rollout).

---

## FAQ: FDE GitHub Portfolios

**Q: Do I need to contribute to open source to get an FDE job?**
Not necessarily. High-quality personal projects that demonstrate depth and customer awareness are often more valuable than a single typo-fix PR to a large project. FDE hiring managers are looking for evidence you can own a system end-to-end, not just navigate a large codebase.

**Q: Should I include my FDE interview prep repo?**
Only if it's exceptional. A fork of a common roadmap with a few notes added is noise. If you've created a novel practice tool or a detailed, original case study, it can be a strong signal. Otherwise, keep your profile focused on the three repos above.

**Q: What if my best work is proprietary from a previous job?**
This is the classic FDE problem. You can't share the code. The solution is the "War Story" deep-dive repo. Recreate the technical challenge in an anonymized, open-source way. Build a minimal reproduction of the core problem and your solution. The communication of the problem is the skill being tested.

**Q: How important are green squares on my contribution graph?**
Zero importance for FDE roles. No hiring manager has ever hired an FDE because of a perfect streak of green squares. They hire based on the signal density of your pinned repositories.

**Q: Should I use an AI to write my READMEs?**
Use AI to edit for clarity and grammar. Do not use AI to generate the "Gnar" section or the technical narrative. An experienced FDE can instantly smell an LLM-generated "challenge" that sounds generic. Your specific, painful, ugly details are your competitive advantage.