How to Build an ML Portfolio Project That Gets You Hired
For Aspiring ML engineers and career switchers · Based on Egor Howell Production-Grade ML Deploy Framework
// TL;DR
If you're applying for ML engineering roles, the Production-Grade ML Deploy Framework gives you a differentiated portfolio project that signals real engineering competence. Instead of another notebook, you ship a fully automated system: a two-domain architecture (forecast + optimise), single-responsibility code, tests outnumbering source lines, CircleCI gates, daily retraining and deploy-on-merge via GitHub Actions, a Supabase database, and a Streamlit dashboard hosted on a VPS. Use the 25 Questions Formula to pick an idea nobody else has, ship a working baseline fast, and start applying while you iterate — describing what you've built and what you're improving.
Why do most ML portfolio projects fail to get interviews?
Because they stop at a notebook. A trained model with 92% accuracy proves you can call `.fit()` — it doesn't prove you can build a system that runs in production. Recruiters and hiring managers see hundreds of Titanic and house-price notebooks. The Production-Grade ML Deploy Framework fixes this by forcing three bars: sufficient quality (production code, tests, CI/CD), scalability in principle, and differentiation — something most candidates simply won't have.
The difference is in the signals. Single-responsibility files, a Makefile, tests that outnumber source lines, a protected main branch, automated retraining, a live database, and a deployed dashboard all say the same thing: this person builds like an engineer, not a student.
How do you pick a project idea that stands out?
Use the Personal Interest → 25 Questions Formula. List five things you genuinely care about outside work — sport, finance, gaming, health, music. For each, write five questions. That gives you 25. Then ask which of those questions ML or data could answer. Pick the one that is both most personally motivating and least likely to appear in another candidate's portfolio.
This matters twice over. A personally motivating project is sustainable to build through the hard deployment steps, and it gives you a genuine, memorable story in interviews. Choosing a topic because someone else called it a good idea is a named pitfall — it shows.
What should you actually build?
Build a two-domain system: a forecasting/ML component AND an optimisation/action component. A model that only predicts is weaker than one that predicts and then drives a decision. In the reference project, Prophet forecasts feed Markowitz portfolio optimisation. Your version might forecast injury risk and optimise squad selection, or forecast demand and optimise restocking.
Then structure the code the way production teams do — grouped by action:
- `main.py` — orchestration only, no logic
- `extractor.py` — data ingestion
- `processor.py` — preprocessing and feature engineering
- `model.py` — training and inference
- `optimizer.py` — downstream decision logic
- `database.py` — Supabase integration
- `streamlit_app.py` — the front-end
- `settings.py` — all constants
Add a Makefile with `make install`, `make lint`, `make type-check`, `make test`, `make check`, and `make dashboard`. Skipping the Makefile is a named pitfall — it's low-effort, high-signal.
How do you make it automated and live?
Manage Python with Pyenv and dependencies with Poetry. Write tests with pytest — at least two or three per function, targeting more test lines than source lines. Wire CircleCI to run lint, type-check, and test on every push, and protect main so nothing merges without passing. Add a GitHub Actions cron workflow to retrain daily, and a deploy workflow that SSHes into a VPS on merge to main and restarts the Streamlit systemd service. Store every secret in environment variables and GitHub repository secrets — never hardcode credentials.
When should you start applying for jobs?
Now — while you build. You do not need a finished project. Ship a working end-to-end baseline, then apply and iterate on a live system. At interview, describe what you've deployed and what you're actively improving. That narrative signals continuous learning, which is exactly what employers want. Waiting for perfection is the single most common way candidates waste months.
Next step: Run the 25 Questions Formula today, pick your two-domain idea, and scaffold the canonical repo (`src/`, `tests/`, `Makefile`, `pyproject.toml`). Get main.py writing to Supabase and a Streamlit dashboard reading it — then start applying.
// FREQUENTLY ASKED QUESTIONS
How long does it take to build a project with this framework?
It depends on your experience, but the framework is deliberately designed to ship a working baseline fast, then improve it. Because you apply while iterating, there's no fixed 'done' date. Use plug-and-play models like Prophet to move quickly through modelling and spend your time on the engineering and deployment — the parts that differentiate you.
Do I need prior DevOps experience to follow this?
No. The framework deliberately avoids complex cloud infrastructure like AWS in favour of approachable tools — Pyenv, Poetry, CircleCI, GitHub Actions, Supabase, Streamlit, and a VPS. Each workflow step gives concrete configuration guidance, and running `make check` locally mirrors what CI enforces, so you can learn the DevOps concepts as you build.
What do I say about the project in an interview?
Describe the full pipeline — how data flows from extraction through modelling, optimisation, storage, and the live dashboard — and highlight your CI/CD gates, testing discipline, and automated deployment. Then explain what you're actively improving. This demonstrates both production competence and continuous learning, which are exactly the signals hiring managers look for.