Portfolio Architecture, Project Storytelling, and Resume Evidence

Technical skill and portfolio evidence are different things. Many strong engineers have weak portfolios - their actual skills are invisible on GitHub and a resume. This module teaches how to convert ML engineering work into hiring evidence that clearly demonstrates capability to a recruiting team.

What Hiring Teams Are Looking For

For ML/AI engineering roles at product companies, recruiters and hiring managers look for evidence of:

1. End-to-end thinking: you can go from data to deployed system, not just train models.
2. Engineering quality: clean code, tests, documented decisions.
3. Judgment under constraints: you made deliberate tradeoffs, not just followed tutorials.
4. Business orientation: you defined success metrics and evaluated whether you achieved them.

A GitHub repository with 50 Jupyter notebooks does not provide this evidence. A case study with a clearly stated problem, an architecture decision record, and measured results does.

The Three-Tier Portfolio Structure

Flagship project (1-2): a complete system end-to-end. Data pipeline, model, serving or evaluation, monitoring or results. 2,000–3,000 word writeup. Should take a reader 15 minutes to understand what you built, why, and what it achieved.

Competency demonstrations (2-3): focused implementations that show specific skills: a custom attention implementation, a RAG system with retrieval benchmarks, a fine-tuned model with before/after evaluation. Shorter writeups (500-1,000 words) with runnable code.

Foundations (ongoing): public contributions, problem solutions, and technical writing that show consistent engagement. Less important than the flagship but good signal for consistency.

Anatomy of a Strong Flagship Case Study

markdownCopy
# [Project Title]

## Problem
One paragraph: what problem you solved, why it matters, and what "success" looks like in measurable terms.

## System Architecture
Architecture diagram + 2-3 paragraph description of components and how they interact.

## Data
What data you used, where it came from, key preprocessing decisions and why.

## Model and Evaluation
What approach you chose, why over alternatives, offline metrics, and what they mean.

## Results
Specific numbers. "Model achieved 0.87 AUC on held-out test set, compared to 0.71 for the heuristic baseline."

## What Didn't Work
What you tried that failed and what you learned from it. This is often the most valuable signal to interviewers - it shows real engineering judgment, not just a tutorial walk-through.

## What I Would Do Next
Honest assessment of limitations and next steps if you had more time/data.

Writing Resume Bullets That Pass the "So What?" Test

Every resume bullet should answer "so what?" - what was the impact?

Weak: "Built a churn prediction model using LightGBM." Strong: "Built a churn prediction model (LightGBM, AUC 0.87) that identified 68% of churners 14 days before cancellation; A/B tested intervention → 12% reduction in monthly churn."

The strong version specifies: what you built (LightGBM churn model), how good it was (AUC 0.87, 14-day horizon), and what it achieved (12% churn reduction from A/B test).

For research or academic projects where you don't have production impact: Acceptable: "Implemented transformer fine-tuning for clinical note classification; achieved 91% F1 on held-out test set, 8pp improvement over TF-IDF baseline."

Making Existing Work Portfolio-Ready

You do not need new projects - you need to document existing work properly. For a project you've already done:

1. Write a 500-word README that covers: problem, approach, results, what you'd do differently.
2. Add a /docs directory with architecture notes and evaluation results.
3. Replace notebooks with a clean src/ package and a Makefile to reproduce results.
4. Add a short RESULTS.md table: model variants, metrics, and which you chose for production.

This takes 4–8 hours per project and dramatically improves signal quality.

Common Mistakes and Bad Instincts

Linking to a Kaggle notebook as portfolio evidence. Kaggle notebooks demonstrate you followed a tutorial, not that you can engineer an ML system. Adapt Kaggle work into a real project with data pipeline, feature engineering, and evaluation harness.

No documented decision rationale. "I used XGBoost" is not evidence. "I chose XGBoost over logistic regression because the 10K training examples were too few for a neural net to generalize, and over random forest because gradient boosting consistently outperformed it by 0.03 AUC in CV" demonstrates engineering judgment.

Portfolio projects that are all toy datasets. MNIST and Titanic signal that you followed tutorials. Build at least one project on a messier, real-world dataset - even if it's publicly available (MovieLens, NYC taxi data, Common Crawl subsets).

Where to Go Next

• Module 30 (Interview Readiness) covers how to present this portfolio in the context of ML interviews.
• The SWE path post portfolio-conversion-turning-engineering-work-into-ml-evidence covers the specific challenge of reframing prior SWE work as ML evidence.