The FDE Portfolio: Shipped Artifacts and Decision Logs to Get Hired

Why FDE Portfolios Are Different

A standard SWE portfolio signals "I can build features in isolation." An FDE portfolio signals "I drop into messy, constrained enterprise environments and ship outcomes that make customers renew." The difference is context, constraint, and communication.

Hiring managers at Palantir, Scale AI, and defense-tech startups aren't looking for another React todo list. They're scanning for evidence you can:

• Ingest a 15-year-old Oracle schema and normalize it against a modern API in 48 hours.
• Write a decision log that saves a customer's compliance team three weeks of review.
• Debug a production auth race condition on-site while the customer's VP of Engineering watches.

Your portfolio must answer the unspoken question: "Would I put this person in a SCIF or a hospital basement with no internet and trust them to unblock the mission?"

Every artifact below maps to a real FDE workflow. Build two or three deeply rather than five shallow ones. Ship them to GitHub with READMEs that read like internal engineering memos, not marketing pages.

Artifact 1: The Integration Spike Repo

What it is: A working end-to-end integration between two systems that were never designed to talk to each other, with a focus on error handling and idempotency.

Why it signals FDE readiness: FDEs live in the gap between legacy enterprise software and modern APIs. Your ability to spike a reliable bridge in a few days is the core skill.

Concrete scenario: Build a connector that pulls purchase orders from a simulated SAP IDoc flat file, transforms them, and pushes them into Stripe invoices. The repo should include:

• A Python or Go CLI that accepts --dry-run and --since flags.
• A retry_queue backed by SQLite for failed Stripe API calls.
• A decision_log.md explaining why you chose eventual consistency over distributed transactions.

What hiring managers look for:

• Idempotency keys: Are you using Idempotency-Key headers on Stripe calls? If not, you've never debugged a double-charge at 2 AM.
• Observability: Structured JSON logging to stdout. Not print(). Not console.log().
• README hygiene: A "Running Against a Real SAP System" section that explains which RFCs you'd call if the flat file were live BAPI output. This shows you understand the enterprise surface area, not just the happy path.

For a deeper dive into building dashboards that sit on top of scraped or integrated data, see our walkthrough on how to Build a Customer Sentiment Dashboard from Scraped Reviews with Gemini and Supabase. The same pattern applies: raw data in, structured insight out, with clear provenance.

Artifact 2: The Public Decision Log (ADR Format)

What it is: A standalone repo or /decisions directory containing 5-8 Architecture Decision Records (ADRs) written in the format Michael Nygard proposed.

Why it signals FDE readiness: FDEs make irreversible technical choices under customer pressure. The artifact isn't the decision — it's the written rationale that lets an Account Executive, a customer's CISO, and a future engineer understand the trade-off six months later.

Structure each ADR with these sections:

# ADR-003: Client-Side Encryption Before S3 Upload

**Status:** Accepted
**Context:** Customer is a regional bank. Data must never appear
unencrypted on our infrastructure, even in memory on API servers.
**Decision:** Perform AES-256-GCM encryption in the browser using
Web Crypto API. Upload ciphertext directly to pre-signed S3 URLs.
**Consequences:**
- Positive: Zero plaintext touch on our servers. Audit trail is clean.
- Negative: Key rotation requires client-side library updates.
No server-side search on document contents.
**Alternatives Considered:**
- Server-side encryption proxy: Rejected. Would require SOC 2
Type II scope expansion for the proxy host.
- Customer-managed KMS: Rejected. Customer's team couldn't
support the key infrastructure within the 2-week deadline.

Where to get real scenarios: You don't need to have worked at Palantir to write these. Use:

• Open-source projects you've contributed to where a contentious design choice was made.
• A hypothetical but rigorously researched scenario: "You're deploying to an air-gapped DoD network. How do you handle model weights for on-prem inference?"

The FDE Interview Loop: Preparing for Signal Over Leetcode Memorization goes deep on how these decision logs map directly to the onsite "design a system under absurd constraints" round. Your portfolio ADRs are the cheat code for that interview.

Artifact 3: The Scoped Customer Dashboard

What it is: A single-page dashboard built on real (even if public) data that answers one specific operational question for a non-technical stakeholder.

Why it signals FDE readiness: FDEs don't build "analytics platforms." They build "the one chart the ops manager stares at during morning standup." Scope discipline is the signal.

Concrete build: A supplier risk dashboard for a fictional manufacturing company using the USGS earthquake API and OpenStreetMap.

• Stack: Next.js, shadcn/ui tables, Recharts for one time-series line.
• Data: USGS real-time earthquake feed filtered to a hardcoded list of supplier factory coordinates.
• The one chart: "Supplier Sites Within 200km of a Magnitude 5+ Event in Last 7 Days."
• The one action: A "Generate Report" button that POSTs to a Next.js API route and returns a plain-text summary suitable for pasting into an email to the procurement team.

What hiring managers look for:

• The README's "User Persona" section: "This dashboard is for Maria, 47, Procurement Manager. She opens it at 7:15 AM on her iPad. She needs to know if she should reroute a purchase order before the 8 AM standup. She will never click a 'drill-down' button." This paragraph alone puts you in the top 5% of portfolios.
• Empty states: What does the dashboard show when no earthquakes match? A green banner that says "All supplier sites nominal" with a timestamp. Not a blank div.

Artifact 4: The 'Unsexy' Migration Script

What it is: A single-file script, with tests, that migrates data from a legacy format to a modern one, handling malformed records without halting.

Why it signals FDE readiness: FDE work is 40% migration. Customers have 20 years of garbage data. Your script must process 2 million rows, log every anomaly, and produce a reconciliation report that a customer's auditor can trust.

Concrete build: Migrate a directory of 10,000 XML files (simulating HL7v2 healthcare messages) into JSON records in a local SQLite database.

• Input: A folder of XML files. 3% contain invalid segments. 1% have mismatched patient IDs.
• Script behavior:
  • Process all files. Never crash.
  • Write valid records to SQLite.
  • Write invalid records to a quarantine/ folder with the original filename and a .err.json file describing the parse failure.
  • Print a summary to stdout: Processed: 10000 | Migrated: 9600 | Quarantined: 400 | Duration: 12.3s
• Tests: pytest tests that assert the quarantine count is correct when you inject a known-bad XML fixture.

The decision log inside the script: At the top of the file, a comment block:

"""
DECISION: We chose SAX parsing over DOM because input files can
reach 500MB and customer hardware has 8GB RAM constraint.
TRADE-OFF: SAX loses parent-child context for nested segments.
We compensate by maintaining a manual stack for PID/OBR segments.
"""

This artifact pairs naturally with the automation patterns in Build a Personal Finance Categorizer from Bank CSVs with Gemini and Supabase. Same principle: structured extraction from messy input, with clear error boundaries.

Artifact 5: The Live Bug Postmortem

What it is: A GitHub Issue or a markdown document in a repo that reconstructs a real production bug you encountered, diagnosed, and fixed — including the wrong turns.

Why it signals FDE readiness: FDEs debug under pressure with customers watching. The ability to communicate the investigation path clearly is as important as the fix itself.

Structure it like a Google SRE postmortem, scaled down:

# Postmortem: Stripe Webhook 401 Spiral on Customer Acme Corp

**Date:** 2024-11-14
**Duration:** 34 minutes of missed events
**Impact:** 12 subscription renewals not processed in real-time

**Timeline (UTC):**
- 14:03: Stripe begins returning 401 on webhook deliveries
- 14:07: Monitoring alert fires (webhook success rate < 90%)
- 14:09: I SSH into prod and confirm `stripe webhook-endpoint list`
  shows the correct signing secret
- 14:12: WRONG TURN: I assume secret rotation happened without
  our knowledge. Spend 8 minutes comparing secrets in Vault.
- 14:20: Realize the issue: A deploy 1 hour earlier changed the
  Express `rawBody` middleware config. `req.body` was being
  JSON-parsed before `stripe.webhooks.constructEvent()`
  received it, invalidating the signature.
- 14:25: Rollback deploy. Confirm webhook deliveries resume.

**Root Cause:** `express.json()` middleware was applied to the
webhook route, consuming the raw body buffer.

**Prevention:** Added integration test that sends a real signed
Stripe event against a local server and asserts 200.

Why this works: It shows you don't hide your mistakes. You systematize them. The "WRONG TURN" section is the most important part — it proves you can course-correct under pressure and document it for the team.

Assembling the Narrative: The FDE Portfolio Page

Your portfolio page itself is an artifact. It should be a single, fast-loading page that prioritizes text over animation. No 3D hero sections. No "I'm passionate about..."

The structure that converts:

1. Header: Your name. "Forward Deployed Engineer" (not "Aspiring" — you are one, you're just not hired yet).
2. One-line positioning: "I ship integration spikes, decision logs, and customer-facing dashboards in constrained enterprise environments."
3. Three featured artifacts: Each with a 2-sentence description that names the constraint. "Built in 48 hours against a simulated 15-year-old Oracle schema." "Deployed on an AWS EC2 micro to simulate customer hardware limits."
4. Decision log link: Prominent. This is often the first thing an FDE hiring manager clicks.
5. Comp and context awareness (optional, sharp): A small note: "Targeting roles with 20-40% travel and on-site customer deployment. Eligible for TS/SCI clearance." This filters out roles that aren't actually FDE.

If you're looking for more project ideas that demonstrate the "build under constraint" muscle, Build a YouTube-to-Blog Repurposing Agent with Groq Llama 3 and LlamaIndex walks through an automation pipeline that touches API integration, structured output, and practical error handling — all core FDE signals.

FAQ: The FDE Portfolio and Getting Hired

How to get into an FDE role?

The most reliable path is to build a portfolio that proves you can operate in customer environments, then apply directly to companies with dedicated FDE programs (Palantir, Scale AI, Anduril, Applied Intuition, Vannevar Labs). A CS degree helps but is not required. What matters is evidence of shipping under constraint. If you need structured prep for the specific interview format, the FDE Interview Loop: Preparing for Signal Over Leetcode Memorization covers the onsite rounds in detail.

What items should you include in your career portfolio?

For FDE specifically: shipped integration code (not just frontend), Architecture Decision Records, a customer-scoped dashboard with a real user persona, a migration script that handles malformed data, and a production postmortem that shows debugging methodology. A personal website should frame these artifacts, not replace them.

Is FDE a good role?

Yes, if you value impact and variety over deep specialization. FDEs are among the highest-paid early-career engineers (often $130K–$180K base, with equity pushing total comp above $200K at top firms). The trade-off is significant travel (20–50%) and the pressure of debugging in customer facilities. It is not a good role if you want remote-only work or to focus on a single codebase for years.

What are three things a portfolio should have?

1. Evidence of constraint: A README that says "built in 72 hours against a rate-limited legacy API." 2. Written decision rationale: An ADR or comment block that explains why, not just what. 3. Customer empathy: A user persona or a postmortem that considers the downstream impact on a non-engineer.