DevOps portfolio projects that actually get interviews

There is a standard list of DevOps portfolio projects circulating on every careers blog: deploy a three-tier app, build a CI/CD pipeline, put a static site behind a CDN. The advice is not wrong. It is just that ten thousand other candidates followed it too, and the result is a sea of near-identical repos that a hiring manager has learned to scroll past.

The portfolio still matters. For a self-taught engineer it is often the only inspectable evidence you control end to end. But it matters in a specific, narrow way that most advice misses, and building it without understanding that way wastes months.

What a portfolio is actually for

A hiring manager reviewing a DevOps portfolio is not evaluating your architecture. They are looking, quickly, for answers to three questions:

1. Did this person build something real, or follow a tutorial? Tutorial repos have a smell: perfect first commits, no history of struggle, a README copied from the source material, resources named my-vpc. Real repos have fix commits, TODO notes, decisions.
2. Does this person think about failure? Ops work is mostly keeping things alive, not building it once. A portfolio with monitoring, alerts, backup restores, or a post-mortem instantly separates itself, because almost nobody includes them.
3. Can this person explain a decision? One paragraph on "why Terraform state lives in a remote backend with locking" is worth more than the entire diagram of your VPC.

Notice that none of these require scale or novelty. They require evidence of judgment. That is the design constraint for everything below.

Five DevOps portfolio projects worth the time

1. A production-shaped deployment of a boring app. Take any small web app and run it the way a careful team would: infrastructure in Terraform, deploys through CI, TLS, DNS, health checks, structured logs shipped somewhere, metrics with two or three alerts that would actually fire. The app is deliberately boring so all the signal lives in the operations. This is the one project from the standard list worth keeping, because done properly it touches everything.

2. A monitoring stack you actually use. Prometheus and Grafana (or an equivalent) watching something real: your homelab, your other projects, your router. Write the alert rules yourself and tune them until they stop being noisy. Include the sanitised dashboard JSON in the repo and a paragraph on an alert you deleted and why. Alert fatigue judgment is a senior signal that costs nothing to demonstrate.

3. A break-and-fix log. Run a small Kubernetes cluster (k3s on spare hardware or cheap VMs is fine) and break it on purpose, once a week, on a schedule. Kill a node during a deploy. Fill a disk. Expire a certificate. Remove a workload's permissions. Each entry: what you broke, what the symptoms looked like, the diagnosis path, the fix, what you would monitor to catch it sooner. Three months of this is the closest a portfolio gets to demonstrating incident response, which is the skill interviews for ops roles probe hardest.

4. One automation that saves you real time. A script or small service that does something you actually needed: rotates backups and verifies restores, reconciles DNS records, opens a PR when a dependency updates and your tests pass. The bar is that it ran more than once and you trusted it. Automation you depend on reads completely differently from automation built for display.

5. One public contribution to a tool you use. A docs fix, a reproducible bug report, a small PR. If a maintainer reviews it, it is the only portfolio item where a third party reviewed your work, which puts it in a different evidence category from everything self-hosted. It also gives you a genuine answer to "tell me about receiving code review."

Five is the ceiling, not the target. Two of these, done to the standard above, beat all five done as tutorials.

A portfolio with monitoring, alerts, and a post-mortem instantly separates itself, because almost nobody includes them.

Presentation is half the project

• Every repo gets a README that leads with why. Three sentences: what this is, what decision it embodies, what you would do differently now. The "differently now" line does more work than any badge.
• Commit messages are part of the portfolio. A history of wip, fix, asdf undoes the impression the project built. Write them like someone will read them, because someone will.
• Link one thing, not everything. Your CV and profile should point at your single strongest piece, not a GitHub profile with forty repos where the reviewer has to guess which four you are proud of. Curate ruthlessly; pin the rest.
• Date your work. A portfolio with visible recent activity answers the "is this stale" question before it is asked. One where everything is two years old raises it.

The honest limit of a portfolio

Here is the part the portfolio-advice industry skips: a portfolio proves effort and communicates judgment, but it cannot verify competence. The reviewer was not there. They do not know whether you wrote it, how long it took, what you understood versus copied, or how you behave when something is on fire and the runbook is wrong. Every claim in a portfolio is still, structurally, a claim.

Experienced reviewers know this, which is why a portfolio gets you the conversation but rarely closes it. The closing evidence has to be produced somewhere the evaluator can watch: an interview exercise, a work trial, a real environment with observation. Build the portfolio to open doors. Do not expect it to walk through them for you.

Where we fit in

That last gap - "everything in a portfolio is still a claim" - is the specific thing SkillBricks verifies. An assessment here is a real scenario in a live environment: a broken deployment, a real shell, an observer watching how you diagnose, decide, and recover, not just whether the final state is green. The result is a brick on your wall that a hiring team can trust without taking your word for anything, sitting alongside the portfolio work that shows your range.

The two compound: the portfolio shows what you choose to build, the wall verifies what you can do under observation. Both are free for candidates. If you have spent months building repos that nobody seems to read, here is how the verified half works - and starting your wall takes minutes.