Part VI · Getting the job · Chapter 17
Building proof
Projects that look like deployments, stories with numbers, and how to tell a real FDE role from a relabelled one.
11 min read
Everyone applying for FDE roles says they are customer-focused and ship fast. Very few can point at something that proves it. This chapter is about building that proof deliberately, and about judging whether the role you're offered is really FDE work.
What you'll take away
- 01What makes a project read as deployment experience rather than a tutorial.
- 02Five project ideas that exercise the skills in this handbook.
- 03How to write up a project so a hiring manager sees your judgment.
- 04How to turn work into résumé lines with outcomes.
- 05Questions that tell a real FDE role from a relabelled one.
Proof beats claims
Hiring managers for FDE roles are looking for evidence that you can take something ambiguous, make sensible decisions about it, ship it, and show that it helped. A tutorial project shows that you can follow instructions. A deployment-like project shows judgment. The difference is rarely the technology. It lies in four features:
- Real, messy inputs: data you had to clean, not a curated dataset.
- A user who isn't you: a friend's business, a community, a team at work, the public.
- A measured result: before and after, even if small.
- Visible decisions: what you chose, what you rejected, what you deliberately left out.
Projects that look like deployments
| Project | What it proves | Make it real by |
|---|---|---|
| A permission-aware assistant over public documents from several organisations (say, three councils' meeting minutes) | Ingestion, retrieval, permission filters, citations, evals | Treating each organisation as a separate tenant, with a test that fails on cross-tenant answers |
| A workflow for a small business you know (quotes, bookings, invoices) | Discovery, reframing, the lightest-tool choice, adoption | Measuring their time before and after, and writing up what you didn't automate |
| Rules vs classifier vs model on one task, priced | Unit economics, honest evaluation | A table of accuracy and cost per item, and a recommendation you'd defend |
| Break your own system and write the incident review | Debugging, observability, blameless reviews | Injecting a realistic fault (a stale index, a permission bug), then tracing and fixing it |
| An integration or MCP server for an open-source tool | Working in someone else's codebase, API design, review etiquette | Getting it merged, which means meeting a real maintainer's standards |
One finished project with a strong write-up beats five half-finished ones. Pick the one closest to the kind of FDE role you want: product FDE roles reward depth in one platform, services roles reward range and speed.
The write-up is half the project
Most portfolio projects are judged from their README in about two minutes. Write it for that reader, and make your judgment visible.
- 1
The problem, for whom
Two sentences. Who had the problem, and what it cost them. - 2
The baseline
How it was done before, with a number. - 3
Decisions
Three to five, each with the alternative you rejected and why. This is the section hiring managers read most closely. - 4
What you didn't build
And why not. It shows you can scope. - 5
Results
Before and after, the eval results, and the cost per unit. - 6
What went wrong
A failure you hit and how you diagnosed it. It is the most credible paragraph on the page. - 7
What you'd do next
With more time, data or users.
The section that gets you hired is usually "what I decided not to build, and why".
Résumé lines with outcomes
A strong line names the outcome, the scope and how you did it, in that order. Customer-facing context and a number do most of the work.
| Weak | Strong |
|---|---|
| Built a RAG chatbot using LangChain and a vector database | Cut policy look-up time for 40 support agents from ~6 to ~1 minute by building a permission-aware assistant over 900 documents, with citations and a test set of 200 real questions |
| Worked with stakeholders to gather requirements | Reframed a client's request for an AI agent into a routing workflow after sampling 300 tickets; launched in 5 weeks instead of the proposed 12 |
| Improved system performance | Reduced p95 answer latency from 14 s to 4 s by capping reranker input and moving inference to the users' region |
| Responsible for deployment | Ran a staged rollout to 6 teams with agreed stop conditions; paused one team in week 2 and fixed the cause in 3 days |
Building in public
Short, honest write-ups of what you built and learned, posted where FDE hiring managers read, compound over time. A build log works better than opinion: what the problem was, what you tried, what the numbers said, what surprised you. It doubles as interview preparation, because you will have already explained your decisions in writing.
Keep it specific and modest. "471 posts in, 186 worth reading, and here is how I decided" is more credible than any claim about transforming an industry.
Telling a real FDE role from a relabelled one
Because the title is fashionable, some roles called FDE are really pre-sales, support, or internal automation with a new name. None of those is bad, but they build different careers. Ask these questions in the process:
| Ask | Healthy sign | Warning sign |
|---|---|---|
| What is the product, and who uses it? | A clear product or service with named customer types | Vague answers; 'we're figuring that out' |
| How many customer deployments has the team done? | Several, with stories about what went wrong | None yet, and no customers lined up |
| How is an FDE's success measured? | Customer outcomes, adoption, renewals, product feedback | Only deals closed, or only tickets closed |
| How much of the week is building? | A large share is hands-on engineering | Mostly demos and slide decks |
| How do field lessons reach the product team? | A defined channel and examples of features that came from the field | They don't |
| What does travel and on-call look like? | Specific and bounded | Unlimited, or 'whatever the customer needs' |
Try it
Rewrite and judge
Part 1. Rewrite this résumé line: "Developed AI solutions for enterprise clients using Python and cloud services." Assume you built a document-extraction workflow for an insurer's claims team of 25, handling about 4,000 claims a month.
Part 2. A job ad for a "Forward Deployed Engineer" says: "Own the technical win in sales cycles, deliver compelling demos, and support account executives to exceed quota. Travel up to 80%." Is this an FDE role? What would you ask?
Write your answer down first, then reveal the worked answerWorked answer
Part 1. For example: "Cut claims intake time for a 25-person insurance team by about 60% (4,000 claims a month) by building a document-extraction workflow with validation rules and human review for low-confidence fields; agreed accuracy targets with the claims lead and ran a four-week pilot before rollout." Use your real numbers. Never invent them.
Part 2. As described, it is a pre-sales or solutions engineering role: success is measured by quota, and the work is demos. Ask what happens after the sale and who builds the deployment, whether the role owns customer outcomes after signing, and how the 80% travel is spread. If no part of the role carries a deployment through to production, it won't build FDE experience, whatever the title.