Skip to content
    All guides

    Forward Deployed Engineer

    AI Portfolio, Case Study and LinkedIn Profile for FDE Roles

    Turn the capstone into a portfolio entry with a README, a case study and honest evaluation numbers, then write a LinkedIn headline and summary that point to it.

    By Published 6 min read

    • fde
    • portfolio
    • case-study
    • linkedin
    • career
    Share

    This lesson is part of FDE Career: Positioning, Portfolio and Outreach. Enroll for free, then sign in, to read it in full.

    Enroll to unlockAlready enrolled?

    What you'll learn: how to turn the capstone into a portfolio entry with a README and case study, report evaluation numbers honestly, check a repository before publishing, and write a LinkedIn headline and summary.

    At a glance

    Figure 1. The portfolio from repository to profile

    flowchart LR accTitle: The portfolio from repository to profile accDescr: The capstone repository has a README that explains the problem and how to run it. A case study page explains the design, the evaluation and the limits. The professional profile links to both. A hygiene check on secrets, data and licence runs before anything is public. C["Capstone repository"] --> H["Hygiene check: secrets, data, licence"] H --> RM["README: problem, run, test"] RM --> CS["Case study: design, evaluation, limits"] CS --> P["Profile: headline, summary, links"]

    How to read this: each box depends on the one before it, so nothing reaches your profile unchecked.

    • A portfolio entry shows what you built, how you tested it and its limits.
    • Evaluation numbers come from a run you can reproduce.
    • A profile points to evidence; it does not replace it.

    Scenario

    Composite scenario, not a real company. A backend engineer finishes a small retrieval service for a fictional distributor and publishes it. The README says "AI-powered product assistant, production-ready, 98 percent accurate". A reviewer clones it and finds no tests running, a key committed in an example file, and no source for "98 percent". The numbers are illustrative and the scenario describes no real person.

    What you will be able to do

    • Structure a README and a case study for the capstone.
    • Report evaluation results with counts, method and limits.
    • Run a hygiene check before publishing.
    • Write a headline and summary that link to evidence.

    Prerequisites

    Finish Positioning your enterprise experience. You also need a working capstone and its evaluation output (your 30/60/90 plan).

    Core ideas

    The README

    Section What it must say
    Problem One paragraph, labelled fictional data and customer
    What it does Three bullets: inputs, outputs, refusals
    Run it Commands that work on a clean machine, without a key (the mock provider)
    Test it One command, and what a pass means
    Evaluation The table your run produced and the command that reproduces it (in the capstone, python -m eval.run_eval)
    Limits What it deliberately does not do

    The case study

    A short page for a reader who will not clone the repository: problem, constraints, design (one diagram), what you measured, what failed, what you would change. "What failed" earns trust: name one error the evaluation caught and what you did.

    At the customer: "How do I know your numbers are real?" Point to a command that regenerates them and a golden set the customer can read.

    Reporting numbers honestly

    Report counts with denominators ("5 of 6"), name the method (same questions, same scoring rule, which strategy) and say how small the sample is. Fictional data shows the method works, not that a real catalog would score the same.

    Hygiene before publishing

    WARNING

    Check the history, not only the current files: a committed key stays in history until the history is rewritten. Revoke or rotate any key that was ever committed (GitHub's guide on removing sensitive data starts there). Confirm the data is fictional, add a licence, and remove anything from a client or employer. If the work touches an employer's code or data, ask someone qualified before you publish.

    LinkedIn basics

    Layouts change, so use whichever fields your profile offers. Three things matter: a headline that says what you build and for whom; a short summary (what you do, one piece of proof with a link, what you are looking for); and experience lines from the previous lesson's bullet formula. Link the case study where visitors see it.

    Worked example

    Assumptions: counts from the reference build's eval/results/latest.json (mock provider, strategy B, generated 2026-11-02), not from any real catalog. The golden set has 36 questions: 6 unanswerable, 4 access-control, 4 ambiguous and 22 ordinary (36 - 6 - 4 - 4 = 22). Replace them with your own run.

    Fact Count from that run How to write it
    Unanswerable questions refused 6 of 6 "6 of 6 refused"
    Access-control questions refused 3 of 4 "3 of 4 refused; q36 (white label) got clarifying questions instead"
    Questions where partner-only content reached a public user 0 of 36 "0 of 36 leaked" (the baseline leaked on 5)
    Ordinary questions with every expected product in the top 3 21 of 22 "21 of 22; q09 found one of its two products"

    Check: 21 divided by 22 is 0.955, about 95 percent, and 3 divided by 4 is 0.75. Prefer counts: with 4 questions, one refusal moves the percentage by 25 points. These are in-sample checks (the same author wrote the golden set and tuned the pipeline against it): say so. The access-control miss is your "what failed" section.

    Practice task

    Fill in the case-study template with your own capstone run.

    TITLE: <what it does, in plain words>
LABEL: Learning project. Fictional customer and data.
PROBLEM: <2 sentences>
CONSTRAINTS: <access control, no invented products, offline tests>
DESIGN: <one diagram, 3 bullets on the key decisions>
EVALUATION: <table from your run: counts, method, command to reproduce>
WHAT FAILED: <one real failure the evaluation found, and the fix>
LIMITS: <what is not covered>
LINKS: <repository, how to run>
    1. Write the README sections in the table above.
    2. Fill in the template with numbers copied from your own evaluation output.
    3. Run the hygiene check: search the history for keys, confirm fictional data, add a licence.
    4. Draft a headline and summary linking to the case study.

    Exercise

    Spot the flaw. Find at least four problems in this portfolio entry: "A production-ready AI assistant for a major manufacturer. 98 percent accurate. Built in a weekend. Clone it and add your paid API key to run. Used by sales teams."

    Answer

    "Production-ready" and "used by sales teams" claim real use. "Major manufacturer" implies a real client. "98 percent accurate" has no count, method or sample size. Running needs a paid key. There is no limits section and no fictional-data label.

    Done when your README follows the table, the case study has counts from your run, the hygiene check is clean, and you have a draft headline and summary.

    Hint 1: I cannot find a failure to report

    Read the misses in your per-question results.

    Hint 2: how do I search the history for a key?

    Search the whole history for the key's prefix. If you find one, rotate it first, then rewrite the history or publish a fresh repository.

    Common mistakes

    • Claiming "production-ready" for a learning project.
    • Reporting a percentage with no count or method.
    • A README that only works with a paid key.
    • Committing a key or a customer file, even once.

    Knowledge check

    1. Why report "5 of 6" instead of "83 percent"?

    A small denominator makes a percentage look precise: one question moves it by 17 points. The count shows the sample size.

    2. What does a README need so a stranger can try the project?

    Commands that work without a key, one test command, and the evaluation command. Without them nothing can be verified.

    3. Why search the history for secrets, not just current files?

    A secret committed once stays in earlier commits. Rotate the key and clean the history before going public.

    4. What should the "what failed" section contain?

    One real failure the evaluation found and what you changed. It shows you measured honestly.

    5. What can a fictional-data result show, and not show?

    That your method and code work as designed. It cannot show how a real catalog would score, so say so under limits.

    You can now

    • Write a README a stranger can follow.
    • Write a case study with counts, method and limits.
    • Run a hygiene check before publishing.

    Further reading

    Last verified: 2026-11-02

    Next

    Outreach, referrals and a practice routine

    Enroll to keep reading

    Lesson 2 of 3 · FDE Career: Positioning, Portfolio and Outreach

    Turn the capstone into a portfolio entry with a README, a case study and honest evaluation numbers, then write a LinkedIn headline and summary that point to it.

    In the rest of this lesson

    • Worked example
    • Practice task
    • Exercise
    • Common mistakes
    • Knowledge check
    • You can now

    Enrolling is free. It unlocks every lesson in FDE Career: Positioning, Portfolio and Outreach, tracks your progress across devices and keeps your quiz scores. The newsletter is optional.

    EnrollSign in

    Ask about this article

    Get answers grounded in this post. AI-generated — based on this article, and may be imperfect.

    FDE Career: Positioning, Portfolio and Outreach· Page 2 of 3
    PreviousPositioning Enterprise Integration Experience for FDE RolesNext Outreach, Referrals and a Weekly Practice Routine for FDE
    Scaled AI Weekly

    Enjoyed this? Get more like it every Monday.

    Real architecture decisions, LLMOps patterns that survive production, and engineering leadership advice — from 12+ years of building at enterprise scale. Free. No spam. Unsubscribe anytime.

    Get new articles by email

    Free. We email a confirmation link first, and you can unsubscribe from any email.

    Join engineers building production AI systems

    Comments

    Back to all guides