No FDE Title? Build FDE Project Evidence Instead

No FDE Title? Build FDE Project Evidence Instead

Many software engineers trying to move into Forward Deployed Engineering make the same resume mistake.

They add a section like this:

• familiar with large language model application development;
• knowledgeable about RAG, agents, and prompt engineering;
• participated in AI projects;
• possess strong business understanding.

Every statement may be true. Together, they still provide almost no evidence.

An FDE resume is not a list of technologies you recognize. It is a compact record of how you turned an ambiguous problem into a working, evaluated, and usable result.

Current FDE roles make that distinction visible. OpenAI describes FDE ownership across discovery, technical scoping, system design, build, and production rollout. Scale AI emphasizes translating customer challenges into solutions and developing across the stack. Palantir has long described forward-deployed engineers as software engineers who work directly with customers to solve operational problems.

The hiring signal is not:

I know the vocabulary used by FDEs.

It is:

I can show evidence of doing the work that FDEs are expected to own.

You do not need to pretend that your previous title was FDE. You do need to make your relevant evidence easy to inspect.

The rule: transform the evidence, not the history

Resume improvement is legitimate when it changes the structure and clarity of a true experience.

It becomes misrepresentation when it changes the underlying facts.

You may:

• explain the real operational problem behind a technical project;
• identify the actual user and workflow;
• describe design alternatives you considered;
• show test cases, failure analysis, and iteration;
• publish a sanitized architecture diagram or repository;
• distinguish your contribution from the team’s contribution;
• state that a project was a personal prototype, internal tool, hackathon entry, or simulated case.

You may not:

• invent a customer or employer;
• describe a personal project as a paid engagement;
• call a prototype a production deployment;
• claim ownership of work completed by another person;
• create adoption, revenue, accuracy, latency, or cost numbers that were never measured;
• imply access to confidential data or systems that you did not have.

The goal is not to package yourself as a role you have never held.

The goal is to demonstrate role-relevant behavior with honest, inspectable evidence.

Why technology-only bullets fail

Consider this resume bullet:

Built a RAG knowledge-base chatbot using an LLM, vector database, and prompt engineering.

It names an architecture, but leaves the evaluator with unanswered questions:

• What problem required a knowledge assistant?
• Who was expected to use it?
• Where did the original workflow break down?
• Why was retrieval necessary?
• Which documents were permitted?
• How was the corpus divided and indexed?
• What did a good answer require?
• How were unsupported answers handled?
• What did the applicant personally build?
• What evidence showed that the system helped?

A technology list answers, “What components were present?”

FDE evidence answers, “Why did this system deserve to exist, and what did you learn by trying to deliver it?”

That is why a credible project story needs five parts:

Problem and workflow
→ ownership
→ solution and tradeoffs
→ validation
→ retrospective and delivery artifacts

1. Start with the problem and operating scenario

Do not begin with “I built a knowledge-base QA demo.”

Begin with the friction you intended to change.

For example:

Support agents repeatedly searched across product manuals, policy documents, and historical FAQs. Similar questions received inconsistent answers, and agents had no fast way to trace a response back to the approved source.

This framing immediately establishes:

• the user: support agents;
• the workflow: receiving a question, finding approved information, answering, and escalating;
• the failure mode: slow retrieval and inconsistent responses;
• the risk: an answer may not be supported by approved material;
• the opportunity: assist retrieval and drafting without removing accountability.

If the project is simulated, say so:

Built a self-directed PoC around a simulated support workflow using public product documentation.

That sentence is weaker than a real customer deployment, but far stronger than an invented one. It tells the evaluator exactly what kind of evidence follows.

Questions your project should answer

Before rewriting the bullet, document:

1. Who experiences the problem?
2. What task are they trying to complete?
3. What happens before and after your system?
4. Which data or documents are involved?
5. What makes the task slow, risky, inconsistent, or expensive?
6. Which action remains with the user?
7. What would count as a meaningful improvement?

This is the first FDE move: put technology back inside a business workflow.

2. Make your ownership explicit

“Participated in an AI project” is almost impossible to evaluate.

Replace it with a precise scope:

• interviewed two internal users and mapped the existing workflow;
• defined the initial use case and out-of-scope requests;
• implemented ingestion, retrieval, citations, and the review interface;
• created the evaluation set and analyzed failure categories;
• deployed the prototype to a test environment;
• partnered with another engineer on authentication while owning the retrieval pipeline.

Good ownership language separates:

This is not excessive caution. It makes the resume more believable and gives the interviewer a clean place to begin probing.

3. Explain the solution through decisions and tradeoffs

“Used RAG” is not a design explanation.

A stronger account describes why retrieval was selected and what had to be decided:

• RAG versus a long prompt: the document set changed and exceeded a manageable static context; answers also needed source references.
• Chunking: sections were divided by document structure rather than arbitrary character counts because headings carried meaning.
• Retrieval: the system combined semantic retrieval with metadata filters for product, version, and document status.
• Citations: every answer displayed the supporting passage so a user could verify it.
• Abstention: when evidence was insufficient, the system asked for clarification or routed the question to a human.
• Access control: retrieval respected the user’s document permissions.
• Observability: queries, retrieved passages, latency, feedback, and failure categories were logged without exposing restricted content.

An FDE-oriented project also describes what was deliberately excluded.

For example:

The PoC did not allow the model to issue refunds or modify customer records. It produced a cited draft for an agent to review because action authorization and audit requirements had not yet been designed.

That sentence shows more production judgment than another paragraph of tool names.

Use a decision record

For every important architectural choice, capture:

Decision:
What did we choose?

Context:
What problem or constraint made the choice necessary?

Alternatives:
What else did we consider?

Tradeoff:
What did the choice improve, and what did it make harder?

Evidence:
How did we test whether the choice was reasonable?

These short records become excellent interview material because they show how you reason, not only what you implemented.

4. Validate the result without inventing numbers

A credible FDE project must include evidence, but evidence does not always mean a polished business KPI.

Use the strongest level that your project genuinely supports.

An evidence ladder

Not every personal project can reach level five. That is acceptable.

The mistake is skipping levels two through four and inventing a level-five number.

What you can measure in a knowledge-assistant PoC

Build a representative evaluation set rather than relying on a few impressive demos.

Record:

• questions answered with direct supporting evidence;
• questions where the retrieved passage was relevant but the response was wrong;
• questions where the answer was plausible but unsupported;
• questions the system correctly refused or escalated;
• common retrieval failures;
• answer latency;
• human review time;
• repeated user corrections;
• performance across different document types or versions.

Groundedness deserves special care. An answer can be supported by a retrieved passage and still be incomplete, outdated, or inappropriate for the user’s situation. Citation presence is not the same as correctness.

If you did not run a controlled time-saving study, do not write “reduced lookup time by 50%.”

Write what you actually know:

Compared manual search and assisted search across 30 representative questions; recorded completion time, citation validity, unsupported claims, and reviewer corrections to identify where the PoC helped and where human escalation remained necessary.

That statement is specific, testable, and honest even before the final results are impressive.

5. Treat failure analysis as evidence

Candidates often hide project failures. FDE interviews frequently make those failures more valuable than the happy path.

A useful retrospective can include:

• the initial hypothesis that turned out to be wrong;
• which document structures hurt retrieval;
• where metadata was incomplete;
• how user language differed from the documentation;
• which questions needed clarification rather than retrieval;
• why a large model did not solve a data-quality problem;
• what permissions or integration work blocked a production path;
• what you would test next with more time or access.

For example:

Initial chunking split troubleshooting tables from their headings, which produced relevant-looking but incomplete evidence. I changed ingestion to preserve section and table structure, added document-version metadata, and expanded the evaluation set with multi-step diagnostic questions.

This is strong evidence because it connects observation, diagnosis, intervention, and retesting.

6. Rewrite the project as a four-part resume story

The visual notes behind this article propose a useful structure: problem, solution, validation, and retrospective.

For a resume, add ownership and compress the result.

Before

Familiar with large-model application development. Built a RAG knowledge-base chatbot using LangChain and a vector database.

After

Built a self-directed support-knowledge PoC using public product documentation to address slow, inconsistent FAQ lookup. Owned workflow framing, document ingestion, metadata-filtered retrieval, citation display, and an evaluation set of representative support questions. Added abstention and human review for unsupported answers; failure analysis exposed document-version and table-chunking issues that informed the next iteration.

The revised version does not claim a customer, production rollout, or invented KPI.

It still demonstrates:

• problem framing;
• workflow awareness;
• personal ownership;
• architecture;
• governance;
• evaluation;
• iteration.

A reusable project template

Project:
[Clear name based on the workflow or outcome]

Context:
[Who has which problem, in what workflow?]

Project type:
[Production / internal pilot / client PoC / hackathon / personal prototype /
simulated case]

My ownership:
[What I personally discovered, designed, built, evaluated, or deployed]

Solution:
[Architecture and integration in plain language]

Key decisions:
[Why this approach; alternatives and tradeoffs]

Validation:
[Samples, tests, user feedback, operational signals, or outcome metrics]

Failures and iteration:
[What did not work and what changed]

Delivery artifacts:
[Repository, demo, architecture, evaluation report, runbook]

Limits:
[What was not tested, deployed, or proven]

7. Turn the Demo into a delivery package

A Demo proves that a happy path can be shown.

A portfolio should help another person judge whether you can deliver.

For each flagship project, prepare:

1. A one-page case study
   Problem, user, workflow, ownership, solution, validation, and result.

2. A clear README
   What the project does, why it matters, how to run it, architecture, limitations, and where to get help. GitHub explicitly recommends using the README to explain why a project is useful and how it can be used.

3. An architecture diagram
   Data sources, model, retrieval or tools, permissions, application, logging, and human decision points.

4. An evaluation note
   Test-set construction, metrics or review criteria, error categories, results, and known gaps.

5. A short recorded walkthrough
   Show the workflow, one successful case, one failure, and how the system responds.

6. A runbook
   Setup, configuration, deployment, monitoring, rollback, and common failure handling where relevant.

7. A decision log
   Three to five important choices and the tradeoffs behind them.

8. A privacy-safe evidence folder
   Use synthetic or public data when real material is confidential. Never publish customer data, credentials, internal prompts, or proprietary documents.

The code remains important. The package shows that you understand the work around the code.

8. Choose projects that reveal FDE behavior

One polished project is usually more useful than ten disconnected chatbots.

Strong portfolio projects have:

• a recognizable user and workflow;
• messy or changing data;
• at least one external system or tool;
• explicit permissions or risk boundaries;
• an evaluation method;
• a path from prototype toward operation;
• documented failures and iteration.

Examples include:

• a support copilot that retrieves approved evidence and escalates uncertain cases;
• a sales-research workflow that gathers sources but requires human approval before outreach;
• a document-intake system that extracts fields, validates them, and routes exceptions;
• an operations assistant that recommends actions without executing high-risk changes;
• a data-quality workflow that detects, explains, and tracks schema or entity problems;
• a migration tool that maps legacy records and produces an auditable exception queue.

Avoid selecting a project only because a technology is fashionable. Choose it because it lets you demonstrate a full chain from problem to evidence.

9. Prepare for the interview behind the bullet

Every strong bullet creates follow-up questions.

Be ready to answer:

• How did you know this was the right problem?
• Which user did you observe or simulate?
• What did the old workflow look like?
• What did you personally own?
• Why this architecture?
• What alternative did you reject?
• How did you build the evaluation set?
• What was the most serious failure?
• What prevented production deployment?
• Which risk required human review?
• How would cost, reliability, or access control change at ten times the scale?
• Which part could become reusable across another customer or workflow?

If a project description cannot survive these questions, the problem is not the wording. The project needs more work or a more honest scope.

A 30-day conversion plan

Week 1: inventory your real evidence

• Collect past work, side projects, hackathons, internal tools, and open-source contributions.
• Label each item accurately: production, pilot, prototype, or simulation.
• Identify one project with the strongest workflow and ownership story.
• Remove confidential material.

Week 2: reconstruct the project story

• Map the user and current workflow.
• Write the problem and constraints.
• Record your personal ownership.
• Document three important design decisions.
• List what was and was not validated.

Week 3: strengthen the evidence

• Add a representative evaluation set.
• Test failure cases and unsupported inputs.
• Add citations, access boundaries, logging, or human approval where relevant.
• Record a baseline or comparison method before claiming improvement.
• Write the retrospective.

Week 4: publish the delivery package

• Improve the README.
• Add the architecture and evaluation note.
• Record a concise walkthrough.
• Rewrite two or three resume bullets.
• Practice answering the interview questions above.

At the end of 30 days, the outcome is not merely a better resume.

It is a more credible body of work.

What an FDE resume should ultimately prove

You can have no FDE title and still demonstrate FDE-like capability.

Your evidence should show that you can:

1. find and frame a meaningful problem;
2. understand the user and operational workflow;
3. scope a realistic first solution;
4. make and explain technical tradeoffs;
5. build across the parts required for delivery;
6. evaluate behavior with representative evidence;
7. handle uncertainty, permissions, and human responsibility;
8. learn from failure and iterate;
9. communicate the work to technical and business audiences;
10. distinguish a Demo from a deployable result.

Do not disguise yourself as a role you have never held.

Show that you are already practicing the behaviors the role requires.

Related learning

• Learning Hub Chapter 1: What an FDE Actually Owns
• Learning Hub Chapter 3: Customer Problems and Operational Outcomes
• Learning Hub Chapter 16: Discovery and PoC Scoping
• Learning Hub Chapter 17: Evaluation and Success Criteria
• Learning Hub Chapter 19: The Last Mile of Deployment
• Learning Hub Chapter 23: FDE Career and Interview Preparation

Sources and further reading

• OpenAI — Forward Deployed Engineer, San Francisco
• OpenAI — Forward Deployed Software Engineer, Seattle
• Scale AI — Forward Deployed Engineer, GenAI
• Palantir — A Day in the Life of a Forward Deployed Software Engineer
• GitHub Docs — Using Your GitHub Profile to Enhance Your Resume
• GitHub Docs — About Repository READMEs