The most effective approach to an FDE (Forward Deployed Engineer, also commonly translated as Forward Deployed Engineer) portfolio is to use one end-to-end flagship project to prove that you identified the right problem, made sound trade-offs, delivered a working system, validated business outcomes, and take responsibility for post-launch risks. Its purpose is not to prove "I can call model APIs," but to let a stranger verify these five things by following the evidence.

Verification date: 2026-08-19. This page is based on the customer collaboration, end-to-end engineering delivery, and production deployment responsibilities that recur in public FDE/FDSE job descriptions, and provides portfolio-building methods; it is not the official hiring standard of any company.

If time is limited, build one flagship project with complete evidence first, rather than stacking three demos that are only chat interfaces. You can start with the Enterprise RAG + MCP project, keeping the deliverables of each stage in the repository.

Minimum Evidence Standard

Heading "Minimum Evidence Standard"

A publishable FDE case should cover at least the following nine items. Each item should point to files, test results, demos, or dashboards, not just a one-line conclusion.

What needs to be provenMinimum acceptable evidenceStronger evidence
The problem is real and worth solvingTarget users, current workflow, cost of failure, and constraintsInterview notes, baseline data, and a confirmed Discovery Brief
The scope is deliverablein/out scope, acceptance criteria, timeboxesChange request records and why certain features were rejected
The solution shows judgmentArchitecture diagram and at least one key trade-offAn ADR comparing alternatives, costs, and risks
The system is reproducibleREADME, environment examples, seed data, one startup commandCI, automated tests, preview environment, or a screen recording reproduction
The results have been evaluatedDataset description, metric definitions, baseline and resultsPer-slice results, failure taxonomy, regression set, and raw run logs
Permissions and data are controlledData classification, threat list, no committed secretsRBAC/tenant isolation tests, audit logs, and adversarial testing
The system is operable after launchStructured logs, health checks, incident handling instructionsSLOs, tracing/dashboards, alert drills, and rollback evidence
The delivery can be handed overOperating instructions, limitations, and handover checklistPilot feedback, training materials, and confirmation from the follow-up owner
Your contribution is identifiableClear boundaries of individual responsibility and collaborationCommits, decision records, or dated work logs

Four Levels of Evidence Strength

Heading "Four Levels of Evidence Strength"

  • L0 — Claim: "The system is stable," "the answers are accurate." No measurement method; cannot serve as evidence.
  • L1 — Demonstration: Screenshots, architecture diagrams, or one successful demo. Shows it was done, but cannot be verified.
  • L2 — Reproducible: Has data, commands, versions, and expected output; others can rerun it.
  • L3 — Validated by use: Has real or clearly labeled pilot users, baselines, results, and limitations.

The core pipeline of the flagship project should reach at least L2. If you have no real customers, do not write classmate testing or synthetic data as "production deployment": clearly label it as a simulated enterprise scenario, and document the data sources, assumptions, and external validity limitations—this can equally demonstrate rigor.

Recommended Repository Evidence Structure

Heading "Recommended Repository Evidence Structure"

File names need not match exactly, but readers should be able to find key evidence within two clicks.

your-fde-project/├─ README.md                    # 结果摘要、演示、快速开始├─ docs/│  ├─ discovery-brief.md        # 用户、流程、问题、范围、指标│  ├─ architecture.md           # 系统边界、数据流、部署图│  ├─ decisions/                # 关键 ADR│  ├─ threat-model.md           # 数据、权限、滥用与缓解措施│  ├─ runbook.md                # 告警、排障、降级、回滚│  └─ handoff.md                # 培训、限制、负责人、下一步├─ evals/│  ├─ README.md                 # 数据来源、指标与运行方式│  ├─ dataset.jsonl             # 去敏后的黄金集/回归集│  └─ results/                  # 带版本和时间戳的原始结果├─ src/                         # 实现├─ tests/                       # 单元、集成与权限边界测试├─ .env.example                 # 仅变量名，不含秘密└─ SECURITY.md                  # 报告漏洞和安全边界

The README's first screen only needs to accomplish four things: one sentence explaining for whom you solve what problem; a demo entry point; a list of measured results; and the shortest reproduction path. Put the tech stack list after these.

Tell the Project Through a "Decision Chain"

Heading "Tell the Project Through a 'Decision Chain'"

Do not start the project narrative with "I used React, Python, and some model." Write in the following order so that technology and business value corroborate each other.

  • Scenario: Who makes what decision in what workflow? What were the original time costs, errors, or risks?
  • Ambiguities: What information was missing at the start? How did you turn it into verifiable hypotheses through interviews, data sampling, or prototypes?
  • Boundaries: What this effort explicitly does and does not do; how the four-week version differs from the ideal end state?
  • Key decisions: List at least two real options, the rationale for the choice, and the costs you consciously accepted.
  • Delivery cadence: Which biggest risk did you validate first? How did customer or test user feedback change the next version?
  • Results: Compared against a baseline on the same dataset, reporting quality, latency, cost, security, or adoption simultaneously.
  • Operations and handover: Who receives alerts, how to degrade, how to roll back, and who owns ongoing maintenance?
  • Retrospective: Which conclusions remain uncertain? If you had two more weeks, what would you validate first?

You can compress the case summary into this paragraph:

For [users]' [workflow/decision], I delivered [scope] under [constraints]. Compared to [an equivalent baseline], the system moved [metric] from [A] to [B] on [dataset/pilot], while maintaining [quality/security/cost thresholds]. I was responsible for [individual scope]; current limitations are [limitations], and full evidence is at [link].

If A and B have not yet been measured, write "to be measured" and show the measurement plan. An honest blank is more persuasive than a fabricated percentage.

What the Results Page Should Show

Heading "What the Results Page Should Show"

Do not give only one overall accuracy figure. Show at least the following simultaneously:

  • Business results: Task completion rate, processing time, rework rate, or adoption rate; state the measurement basis and sample size.
  • Quality results: Sliced by key scenarios, especially showing high-risk, long-tail, and failure samples.
  • System results: End-to-end latency, error rate, per-task cost, and behavior during dependency failures.
  • Security results: Whether tests for privilege escalation, prompt injection, and sensitive data leakage passed.
  • Explanation of changes: Which decision produced the change, and whether there was a trade-off between quality and cost.

Keep the failure samples. An FDE's credibility comes from being able to define when the system is unreliable, and designing human review, degradation, and stop conditions for it.

Do a Red-Team-Style Self-Check Before Publishing

Heading "Do a Red-Team-Style Self-Check Before Publishing"

  • Can the repository start from a fresh environment following the README? Are the links publicly accessible?
  • Do the results include data versions, code commits, model/prompt versions, dates, and run configurations?
  • Were customer names, personal information, access tokens, internal URLs, or restricted data accidentally committed?
  • Does the architecture diagram match the current implementation, not the original vision?
  • Can all numbers be traced back to raw results? Are sample sizes and failure items shown simultaneously?
  • In team projects, is there a clear distinction between your work, teammates' work, and third-party capabilities?
  • Do words like "production," "enterprise-grade," and "real-time" have corresponding evidence? If not, change them to accurate wording.
  • Are captioned/text versions of demos, clear headings, and image alt text provided?

Using the in the repository

templates/portfolio-rubric.md

self-assessment, then ask someone unfamiliar with the project to verify using only the links. Evidence they cannot find is equivalent to nonexistent.

From Portfolio to Opportunity

Heading "From Portfolio to Opportunity"

Prepare three entry points to the same evidence for different readers, rather than maintaining three separate stories:

Entry pointLengthWhat the reader should take away
Resume project item2–3 linesThe problem, your actions, verifiable results, and a project link
Case study page3–5 minutes of readingThe decision chain, key evidence, constraints, and your contribution
In-depth materialsReproducibleCode, raw eval results, runbooks, and decision records

The tutorial site is for letting learners and peers verify your methods; the personal main site is for handling real cases and collaboration decisions. To see how this evidence plays out in actual AI deployments, you can view the author's project case studies; if your team already has a scenario but the problem boundaries or acceptance criteria are still unclear, you can discuss a project diagnosis.

After completing this, move on to interview preparation and turn each piece of portfolio evidence into a story that can be probed, demonstrated, and honestly answered at its boundaries.

Sources and Boundaries

Title: "Sources and Boundaries"

Job titles, responsibilities, and hiring processes vary by company, team, region, and time. When applying, defer to the information published for the target role on the day of application and to communications with the recruiter.