Forward deployed engineer portfolio projects

What to show for each project

Our suggestion: make a reviewer able to answer these without asking you.

• The customer problem, in their words, and who it belonged to.
• The constraint that shaped the design: data, security, deadline, an existing system.
• The decision you made, the options you rejected, and why.
• What you built and how you know it works: tests, a demo, a failure you handled.
• What you would do next, and what you left out on purpose.

The documents that carry it

Code alone leaves out the judgement. These free templates give each document its sections:

• Customer brief and assumption register — before building anything: turn a customer request into a bounded problem.
• Discovery summary — after stakeholder interviews, before choosing an approach.
• Pilot scope and acceptance criteria — once an approach is chosen: agree what the pilot will and will not do.
• Architecture decision record — when a design choice will be hard to reverse or needs a reviewer's sign-off.
• Threat model — before a design handles customer data or takes actions on a customer's systems.
• Incident root-cause report — after an incident is contained: show it is understood and cannot silently happen again.
• Executive readout — at the end of a pilot: give the sponsor what they need to decide.

Five project shapes

Generic ideas, not DrillHall missions. Use a fictional or public customer, never a real one's data.

1. Connect two systems that do not fit. Pick two public APIs with different auth or data shapes, join them for a made-up customer, and handle the failures: timeouts, rate limits, bad records. Write down what you do when a call fails and why.
2. Fix a failing pipeline and explain it. Take an open-source project with a real bug, reproduce it, fix it, add a test, and write the root-cause report. The report matters as much as the patch.
3. Scope a pilot for a fictional customer. Start from a vague request, write the customer brief and discovery summary, then a pilot scope with acceptance criteria someone else could check and a list of what is out of scope.
4. Put guardrails around an AI feature. Build a small AI-assisted workflow, define what a bad output is, test for it, and record the risk that remains. Include a threat model.
5. Hand a project over. Take any of the above and write the executive readout: what was done, what it showed, what you recommend, what you would do next.

Presenting it

• One page per project, opening with the problem and the result, then the documents.
• Link the repository and say which parts you wrote.
• Do not claim customers, revenue or production use you do not have. A clearly fictional customer is fine if you say so.

One worked example: Project Atlas

Project Atlas is DrillHall's own engagement: ten stages with a fictional enterprise customer, covering stakeholder discovery, safety architecture, bug fixes, incident response and an executive handover. The scenario estimates 10–14 hours. It is in a private pilot and checkout is closed, so you would need an invitation. We cannot say it will help you get a job. The assessment page says what it judges, and the free preview shows a short mission.

Read next: forward deployed engineer skills and how the role differs from adjacent ones.

Sources

1. What are Forward Deployed Engineers, and why are they so in demand? · The Pragmatic Engineer (Gergely Orosz) · 2025-08-12
2. Forward deployed engineer interview questions · FDE Academy (sells interview preparation) · 2026-04-09