Skip to content
AI Full-Stack Wiki

An AI Engineer Portfolio That Gets Interviews

Build a portfolio for AI full-stack roles: which projects to show, how to write a README hiring managers read, how to prove quality with numbers, and how to share it.

Difficulty: Beginner13 min readUpdated
On this page· What a portfolio is for

Why this matters

Hiring managers for AI engineering roles see hundreds of chatbot demos. Most look the same, and most cannot be run. What stands out is evidence of engineering judgment: a deployed project that solves a real problem, with decisions explained and quality measured. A portfolio is not a gallery of everything you have built; it is a short, convincing argument that you can ship AI features that work.

What a portfolio is for#

From project to interviewA project becomes evidence when it is deployed, documented as a case study with decisions and numbers, and shared where hiring managers look; that evidence leads to conversations and interviews.shareBuilda real problemShipdeployed, usableProveevals, numbersExplaincase study, demoInterviews

Hover or tap a component to see what it does.

From project to interview: build something real, ship it, prove it with numbers, explain your decisions in a case study, and share it where hiring managers look.
Show text description

Most portfolios stop after the first box. Each step to the right multiplies the value of the work already done.

  • Build: One substantial project beats five tutorials. Solve a problem a real user has.
  • Ship: A live URL or a one-command local setup. If reviewers cannot run it, it barely exists.
  • Prove: Eval results, latency, cost per user, test coverage: numbers turn claims into evidence.
  • Explain: A README and a short write-up: problem, decisions, trade-offs, results, and what you would do next.
  • Interviews: Shared on GitHub, your site, and LinkedIn, the evidence starts conversations.

A reviewer spends a few minutes on your portfolio. In that time they should be able to answer three questions:

  1. Can this person ship? Is there something deployed or runnable, beyond a notebook or tutorial?
  2. Do they make good decisions? Do they explain trade-offs: why this model, why RAG and not fine-tuning, why a workflow and not an agent?
  3. Do they measure? Are there evals, costs, latency numbers, tests?

Choose two or three projects, not ten#

Depth beats breadth. A strong portfolio for an AI full-stack role usually has:

SlotWhat it showsFrom this wiki
FlagshipA complete product: auth, data, AI features, limits, evals, deploymentCapstone SaaS
Depth pieceOne hard problem done well: retrieval quality, an agent with approvals, an MCP serverDocs Q&A, Support agent, MCP server
Your own ideaCuriosity and product sense: a tool for a community you belong toAnything, ideally used by real people

Make at least one project solve a problem for real users: a teammate, a club, an open-source community. "Used weekly by 30 people" is worth more than any feature list.

The README is the product page#

Most reviewers never run your code. They read the README. Structure it for a 2-minute skim:

README.md
# Acme Docs Assistant
 
Ask questions about the Acme SDK docs and get cited answers. Live: https://docs-assistant.example.dev
 
![Demo: asking how to paginate results](./docs/demo.gif)
 
## Results
| Metric | Value |
| --- | --- |
| Retrieval recall@5 (48 questions) | 94% |
| Answer pass rate (judge + code checks, 3 trials) | 89% |
| "Not in the docs" correctly detected (12 out-of-scope questions) | 11 / 12 |
| p95 time to first token | 1.1 s |
| Cost per answer | ~$0.006 |
 
## Architecture
(diagram) Ingest job → Postgres + pgvector → hybrid search → rerank → Claude with citations.
 
## Key decisions
- **Hybrid search over vector-only**: error codes and API names were missed by embeddings (recall 81% → 94%).
- **Relevance threshold** before calling the model: out-of-scope questions get an honest answer for free.
- **Incremental ingestion** with content hashes: re-indexing after a docs change costs cents, not dollars.
 
## Run it locally
`cp .env.example .env.local`, then `docker compose up -d && npm install && npm run db:migrate && npm run dev`.
 
## What I'd do next
Multi-version docs, and a feedback loop that opens docs issues for unclear pages.

Notice what is not there: a long feature list, the tech stack as a wall of badges, or setup instructions longer than the explanation.

Prove quality with numbers#

Numbers make claims credible. If you followed the evals article, you already have them. This script turns an eval results file into the README's results table, so the numbers stay current:

scripts/readme-results.ts
import { readFileSync, writeFileSync } from "node:fs";
 
interface CaseResult {
  id: string;
  tags: string[];
  passRate: number;
  tokens: number;
}
 
interface EvalRun {
  version: string;
  overall: number;
  results: CaseResult[];
}
 
const pct = (v: number) => `${(v * 100).toFixed(0)}%`;
 
export function resultsTable(run: EvalRun): string {
  const byTag = new Map<string, number[]>();
  for (const r of run.results) for (const tag of r.tags) byTag.set(tag, [...(byTag.get(tag) ?? []), r.passRate]);
 
  const rows = [...byTag]
    .sort(([a], [b]) => a.localeCompare(b))
    .map(([tag, rates]) => `| ${tag} | ${rates.length} | ${pct(rates.reduce((s, v) => s + v, 0) / rates.length)} |`);
 
  return [
    `**Eval results** (${run.version}, ${run.results.length} case${run.results.length === 1 ? "" : "s"}): **${pct(run.overall)}** overall`,
    "",
    "| Area | Cases | Pass rate |",
    "| --- | --- | --- |",
    ...rows,
  ].join("\n");
}
 
// Replace the block between the markers in README.md with a fresh table.
if (import.meta.main) {
  const run = JSON.parse(readFileSync("evals/results/latest.json", "utf8")) as EvalRun;
  const readme = readFileSync("README.md", "utf8");
  const updated = readme.replace(/<!-- results:start -->[\s\S]*<!-- results:end -->/, `<!-- results:start -->\n${resultsTable(run)}\n<!-- results:end -->`);
  writeFileSync("README.md", updated);
  console.log(updated === readme ? "README already up to date" : "README results updated");
}
readme-results.test.ts
import { test } from "node:test";
import assert from "node:assert/strict";
import { resultsTable } from "./scripts/readme-results.ts";
 
test("summarizes pass rates per tag", () => {
  const table = resultsTable({
    version: "support-v3",
    overall: 0.85,
    results: [
      { id: "a", tags: ["refunds"], passRate: 1, tokens: 900 },
      { id: "b", tags: ["refunds"], passRate: 0.5, tokens: 900 },
      { id: "c", tags: ["scope"], passRate: 1, tokens: 700 },
    ],
  });
  assert.match(table, /\*\*85%\*\* overall/);
  assert.match(table, /\| refunds \| 2 \| 75% \|/);
  assert.match(table, /\| scope \| 1 \| 100% \|/);
});

Put <!-- results:start --> and <!-- results:end --> in your README, run the script after each eval run, and commit. Honest numbers, including what does not work yet, build more trust than perfect ones.

Make it easy to try#

  • Deploy it with a demo account or a usage-limited public mode. Protect your API key with per-IP limits and a small daily budget.
  • Record a 60 to 90 second video for reviewers who will not sign up: the problem, the main flow, one impressive detail.
  • One-command local setup: Docker Compose for the database, .env.example with every variable, seed data.

Where to share it#

  • GitHub: pin your best repositories; write a profile README that links to them with one line each.
  • A personal site: a page per project, with the case study (writing about your work).
  • LinkedIn and community forums: a short post per project with the video and one interesting lesson.
  • Open source: a fix or feature in a library you used (an SDK, an MCP server, a framework) is portfolio evidence that maintainers vouch for.

Common mistakes#

  • Tutorial clones. If it looks like a course project, it reads like one. Change the problem, add evals, deploy it.
  • No way to see it work. No deploy, no video, broken setup instructions.
  • Claims without numbers. "Accurate answers" means nothing; "89% pass rate on 50 real questions" means something.
  • Hiding trade-offs. Explaining what you chose not to do shows more judgment than listing what you did.
  • Leaking keys. Check your repository history for secrets before making it public.

Try it

Audit your portfolio like a reviewer

  1. Give yourself five minutes per project, as a reviewer would. Can you tell what it does, see it work, and find one number about its quality?
  2. Rewrite your best project's README with the structure above, including a results table.
  3. Ask someone outside tech to read the first paragraph and explain back what the project does. Fix whatever they misunderstood.

Check your understanding

What makes a portfolio project stand out for AI engineering roles?
Which README section shows judgment most clearly?
Why include results that are not perfect?

Key takeaways

  • Show two or three deep projects, including one complete product and one used by real people.
  • Write the README as a product page: what it does, a demo, results with numbers, key decisions, and quick setup.
  • Generate results tables from your evals so the numbers stay honest and current.
  • Make projects easy to try and share them where reviewers already look.

Next steps#

Finished this article? Track it to see your progress on the roadmap.