AI Engineer Portfolio Projects That Get Interviews

An AI portfolio that shows a demo and nothing else leaves its main claims unverified. Alex builds a "chat with your deployment runbook" app. It answers one question, looks good on GitHub, and still has no evidence when a reviewer asks:

• How do you know the answer came from the document, not the model's memory?
• What happens when the policy PDF has a conflicting table on the next page?
• How much does each query cost, and how would you make it cheaper?

Alex doesn't have answers. The app is a wrapper around an API call, not evidence of engineering judgment. A strong AI engineering portfolio lets a reviewer run the product, inspect code, read trade-offs, see evals, and understand what still needs work.

A reviewer-focused rubric

LeetLLM recommends treating the portfolio as an evidence packet, not assuming that every hiring team uses the same rubric. The criteria below are our preparation recommendations for making engineering judgment inspectable.

Make these signals easy to inspect: a clear user problem, tests and setup docs, typed schemas, small modules, evals, prompt history, failure analysis, citations, logs, cost notes, timeouts, deployment notes, private-data handling, prompt-injection notes, and a README that explains trade-offs without hype.

Your portfolio should answer one question: would this person be useful on a team building AI software? If a reviewer can't run your project in under ten minutes, find the eval results, or tell what you'd improve next, the project isn't finished. It's a draft.

💡 Key insight: A portfolio project isn't a demo. It's a bundle of inspectable evidence: eval rows, traces, citations, cost notes, and a README that explains trade-offs without hype.

Project 1: document QA with ingestion proof

This is the classic RAG (Retrieval-Augmented Generation) project, but our recommended bar is higher than uploading a PDF and asking questions. Make the project inspectable with ingestion proof: parser logs, chunk preview, source citations, eval questions with expected source chunks, retrieval metrics, a before/after chunking or embedding comparison, and failure analysis.

Use a small public corpus: your own docs, a public handbook, a public policy set, public API docs, or course notes. Don't use private documents in a public demo.

What makes it strong

Weak version: upload PDF, ask question, get answer.

Strong version: inspect extracted pages, remove repeated headers and footers, preview chunks, show cited answers, run evals, and explain failed cases.

This project shows that RAG quality starts before the model call. If chunks are too large, retrieval returns generic text. If the parser drops tables, the model misses exception rules and version notes. Surface those failure points before spending time on visual polish.

Project 2: eval dashboard

Many beginners stop at "it looks correct." An eval dashboard shows how often the system passes a fixed rubric.

Build a small app that compares prompt or model versions over a fixed dataset. Alex's access-request classifier has rows like: input "I can't open the admin report page", expected category "account", and must-mention term "permission".

Version the evidence

Useful columns are dataset version, prompt version, model version, judge-rubric version, pass/fail, failure reason, latency, and tokens. Together, they prevent hidden test drift and turn quality changes into something a reviewer can inspect.

ML systems often accumulate hidden technical debt when data, code, models, and evaluation criteria drift independently.^{[1]Reference 1Hidden Technical Debt in Machine Learning Systems.https://research.google/pubs/hidden-technical-debt-in-machine-learning-systems/} A dashboard that tracks versions shows you understand that problem.

Make it inspectable: include a JSONL eval dataset, deterministic checks, optional LLM judge rubric, side-by-side comparison, CSV export, and a short "what changed and why" report. Two prompt versions, ten rows, and one comparison table tell a clearer story than a chatbot with no tests.

Project 3: support copilot with human review

A support copilot drafts replies, but a human approves them. This is more realistic than a fully autonomous support agent, and it shows product maturity because it doesn't pretend the model should send everything on its own.

Alex's support copilot handles a SaaS company's workspace-access queue. The model reads policy context, drafts a reply, validates citations and tone, and then waits for a human to approve or edit.

Workflow:

Required proof: policy citations, editable draft UI, approval state, rejection reason, prompt version, sample audit log, and tests for unsafe or unsupported answers.

This project shows you can design AI products that respect real constraints. A model that grants admin access without checking permissions is a liability, not a feature.

Project 4: AI coding assistant for one repo

Build a small repo assistant that answers questions about a codebase or drafts safe changes. Keep it scoped.

Good scope: one repository, file citations, test-location suggestions, a patch for one requested file, and explicit approval before shell commands. Bad scope: an "autonomous engineer" that can fix anything.

Constrain the claim

SWE-bench is a useful reminder that real repository tasks are harder than isolated code questions.^{[2]Reference 2SWE-bench: Can Language Models Resolve Real-World GitHub Issues?https://arxiv.org/abs/2310.06770} Your project should show that you respect repository context, tests, and review.

Required proof: file citations, task scope, generated diff, review checklist, tests or dry-run mode, and a prompt-injection note for repository text.

A coding assistant that explains "Why is check_admin_permission in accounts.py?" with a file citation is more trustworthy than one that claims to rewrite the whole service.

Project 5: cost and latency optimizer

Many teams care about AI cost and user experience. Build a tool that compares model-call options on a real task.

For the support copilot from Project 3, Alex compares direct calls, shorter prompts, prompt caching, batch jobs, smaller models for simple cases, and retrieval before generation.

Compare one fixed workload

Show p50 latency, p95 latency, input tokens, output tokens, estimated cost per 1,000 requests, error rate, and eval pass rate. Use real measurements from the same task set so "cheaper" doesn't quietly mean "worse."

Don't invent precision you don't have. If costs depend on provider pricing, say when the estimate was made and link the pricing source or config. Be honest about when each lever applies: prompt caching helps only when requests share a long, stable prefix, and Batch API jobs fit offline work where a user isn't waiting for an immediate response.^{[3]Reference 3Prompt cachinghttps://developers.openai.com/api/docs/guides/prompt-caching[4]Reference 4OpenAI Batch API Guidehttps://developers.openai.com/api/docs/guides/batch} Knowing when a lever doesn't apply is as strong a signal as the savings number itself.

This project proves that you understand trade-offs, not prompts alone. A smaller model may answer simple runbook lookups faster, but fail on ambiguous incident summaries. Showing both sides on the same task set is the proof.

The minimum repo bar

Every portfolio project needs enough evidence for a reviewer to trust the repo isn't abandoned.

Minimum evidence: README, .env.example, tests, eval data, a short design doc, screenshots or video, known limits, and deployment notes. A reviewer should be able to run it, confirm secrets aren't committed, check behavior, inspect quality data, and understand what you'd improve next.

Put proof in the first screen

Use that list as a repo audit before you publish. If setup, safe config, tests, evals, limits, and deployment notes aren't findable within a minute, the repo still reads like a prototype.

Use Docker only when it helps the reviewer run the app or understand deployment. Docker's docs are the right source for container basics and image practices.^{[5]Reference 5Docker Documentation.https://docs.docker.com/} If a project requires paid model access, include a mocked mode so tests and demos still work. A reviewer shouldn't need a live API key to verify your eval logic.

Your README should surface the evidence: what the project does, where to run it, which eval data and metrics you used, where it fails, what data is logged or redacted, and why this design beats simpler alternatives. The "Failure modes" and "Trade-offs" sections are where strong reviewers look first.

What not to build

Avoid projects that are hard to review:

Weak projects are hard to verify: generic chatbots with no product problem, PDF chat with no citations, agents that can do anything, prompt collections, local model benchmarks with no method, and apps with no tests.

You can still build these for learning. For a reviewer-facing portfolio, our recommendation is to turn them into proof: add evals, citations, logs, tests, a design doc, and failure analysis.

Common pitfalls

• "It looks correct to me": write ten rows with expected outputs, run every change against them, and count passes and fails.
• The demo costs $5 per query: add retrieval or prompt trimming, then measure tokens before and after.
• The agent sent a reply without approval: add an approval step and log who approved what and when.
• Two weeks on CSS, two days on the model: build evals, retrieval traces, and failure analysis first. The UI can stay plain.

Ship order and final check

If you can only build two projects, build these:

1. Document QA with ingestion proof.
2. Eval dashboard.

If you can build four, add support copilot with human review and AI coding assistant for one repo. If you want one operations-heavy project, add the cost and latency optimizer.

This mix is our recommended way to demonstrate product work, retrieval, evaluation, agents, and operations without collecting unfinished demos. For each project, prepare a short story around the user problem, model strengths, model failures, quality metric, logs, invalid-output handling, cost reduction, private-data handling, and what you'd rebuild after another month.

Role family still matters. Shipping five product RAG demos doesn't by itself map to frontier-lab or systems/ML loops that weight distributed training, kernel performance, research depth, or large-scale infra. Match projects to the roles you target, and use the salary guide's role-family framing so portfolio proof tracks the hiring bar you actually want.

Before you call a project interview-ready, check three things without hand-waving: can a reviewer verify the main claim from traces and evals, can you explain the first known failure, and can you compare quality, latency, tokens, and failure rate before making cost claims?

🎯 Production tip: If a project needs a live API key, ship a mocked mode so reviewers can run eval logic and tests without your credentials. A plain UI with working evals beats a polished chat shell with no proof.

Don't build huge. Build inspectable. A small app with tests, evals, traces, and an honest failure report beats a broad demo that's hard to verify.

Use one completed project as the handoff from tutorial work to shipped evidence. Pick a real problem, write the eval set first, and let the numbers guide your design.