Portfolio Conversion: Turning Engineering Work Into ML Evidence

Software engineers entering ML often have a portfolio problem that is the inverse of college graduates: they have years of real production engineering experience and may even have shipped ML-adjacent features - yet their resume and portfolio do not communicate ML readiness because they have framed everything in SWE terms. The solution is not to discard your SWE experience - it is to translate it into ML evidence.

This module gives you the framework to audit your work history, identify ML evidence hiding in SWE projects, and build targeted proof-of-concept projects that close the gap.

What ML Hiring Teams Are Looking For

ML engineering roles have a different bar than SWE roles:

Signal	SWE Evidence	ML Evidence
ML fundamentals	None directly	Supervised/unsupervised projects with real evaluation
Production ML	None directly	Served model, drift monitoring, retraining pipeline
Tooling fluency	General coding	PyTorch, sklearn, HuggingFace, MLflow, Feast
System design	Scalable services	Covers ML-specific tradeoffs (quality/cost/latency)
Experimentation culture	A/B testing general features	A/B testing model changes, eval harness

Most SWEs have strong signal in system design and can build evidence in the others with targeted projects.

Auditing Your Work History for ML Evidence

For each past project, ask:
1. Did we make data-driven decisions? → Evidence of experimentation mindset
2. Did we build any recommendation, ranking, classification, or anomaly detection?
   → This IS ML work even if not called ML
3. Did we A/B test features? → Evidence of evaluation discipline
4. Did we build any data pipelines? → Evidence of data engineering fluency
5. Did we handle high-volume prediction or scoring?
   → Evidence of serving experience

Concrete translations:

Your SWE experience	ML evidence it demonstrates
Built a fraud rule engine	Feature engineering, precision/recall tradeoffs
Implemented a search ranking for e-commerce	Learning to rank, offline/online eval
Built a notification system with engagement optimization	Prediction scoring, A/B testing
Maintained a data warehouse	Feature store thinking, pipeline reliability
Monitored service SLOs	Monitoring mentality, translates to model monitoring

The Portfolio Project Formula

A strong ML portfolio project has four components:

1. A real problem: not a tutorial dataset - a problem you care about or that reflects a real industry use case
2. Proper evaluation: a held-out test set, the right metrics for the task, offline + online eval if applicable
3. Production consideration: deployment, serving, monitoring, or pipeline - at least one beyond the notebook
4. Documented decisions: why you chose this model over alternatives, what did not work, what you would do differently

pythonCopy
# Example: customer churn prediction - production-grade version

# Not: notebook that runs XGBoost on a CSV
# Yes: this structure

"""
churn_predictor/
├── data/
│   ├── raw/               ← DVC-tracked
│   └── processed/         ← DVC-tracked
├── src/
│   ├── features.py        ← Feature engineering, point-in-time correct
│   ├── train.py           ← MLflow-tracked training run
│   ├── evaluate.py        ← Offline eval: AUC, PR-AUC, calibration
│   └── serve.py           ← FastAPI endpoint with health check
├── tests/
│   ├── test_features.py   ← Unit tests for feature logic
│   └── test_serve.py      ← Integration tests for API
├── notebooks/
│   └── exploration.ipynb  ← EDA only - no production logic here
├── Dockerfile
├── mlflow.yml
└── README.md              ← Problem statement, approach, results, limitations
"""

What to Put on Your Resume

Before (SWE framing):

"Built a recommendation system for the product catalog using collaborative filtering."

After (ML framing):

"Designed and shipped a two-tower embedding model for product recommendations serving 2M users, achieving 23% lift in CTR vs. rule-based baseline in A/B test. Built Prefect data pipeline with point-in-time feature joins and MLflow experiment tracking; deployed via FastAPI with Redis semantic cache."

The ML framing answers five questions the hiring team asks:

• What was the model? (Two-tower embedding)
• What was the scale? (2M users)
• Did it work? (23% CTR lift, A/B tested)
• Was it engineered properly? (Prefect pipeline, MLflow, FastAPI)
• Was it in production? (Deployed, cached)

Conversation Framework for Interviews

Structure every ML project story using this framework:

1. PROBLEM: What business problem were you solving? What were the constraints?
   (Don't start with the model - start with the problem)

2. DATA: What data did you have? What did you have to build or collect?
   (Shows data engineering instincts)

3. APPROACH: What did you try? Why did you choose this approach over alternatives?
   (Shows decision-making, not just execution)

4. EVALUATION: How did you measure success? Offline and online?
   (Shows rigor - this is where many candidates fail)

5. PRODUCTION: What happened when you deployed? What did you monitor?
   (Shows production ML experience)

6. LESSONS: What did not work? What would you do differently?
   (Shows growth mindset and intellectual honesty)

Interviewers who ask "tell me about an ML project you shipped" are running this framework in their heads. Covering all six points proactively makes you stand out.

Filling Portfolio Gaps with Targeted Projects

If your work history lacks certain signals, build them:

Missing signal	Project to build	Time investment
Supervised learning basics	Churn prediction with proper eval	1 weekend
LLM engineering	RAG system over a document set you care about	1–2 weekends
MLOps basics	Add DVC + MLflow + CI pipeline to any existing project	1 day
Model serving	FastAPI + Docker + health check for any trained model	1 day
Embeddings + retrieval	Semantic search over a personal dataset	1 weekend

Two well-executed portfolio projects with production-grade structure signal more than five notebook-only tutorials.

Common Mistakes and Bad Instincts

Treating the portfolio as a showcase of completed tasks. Hiring teams do not care that you "implemented a neural network." They care about why you made the decisions you made and what you learned when something went wrong. Document your reasoning and your failures.

Hiding SWE experience because it does not feel "ML enough." Your distributed systems, API design, data pipeline, and monitoring experience is a genuine competitive advantage over ML researchers who cannot ship. Lead with it, then connect it to ML.

Over-polishing presentation at the expense of technical depth. A beautiful README on a shallow project does not impress ML engineers. A rough README on a project with solid evaluation, production considerations, and honest failure analysis does.

Where to Go Next

• interview-readiness-for-ml-ai-engineering-roles: practice the ML system design and coding questions you will face in interviews
• capstone-build-and-operate-a-production-style-ai-system: build the capstone project that anchors your portfolio