Put Your Homelab on the CV? Maybe Just Wait for the Interview

There’s a thread doing the rounds about whether you should put your self-hosted setup on your CV. A senior engineer at a big tech company said if they saw a serious homelab listed, they’d rate it highly. Reasonable take. But the replies are the interesting bit, because everyone has a different idea of what “serious” means, and a few people admitted to running their whole setup off gear they “acquired” from a previous employer. That’s a different blog post.

I’ve got a small homelab. Nothing heroic. A few containers, a reverse proxy, backups that I’ve actually tested (this matters more than people think), and a Pi-hole that my daughter complains about when it blocks something she wants. I did not build it to impress anyone. I built it because I like understanding how things work end to end, without a platform team standing between me and the outcome. But I get why it comes up in interviews. It’s a decent proxy for whether someone actually enjoys the boring, unglamorous parts of the job, the certs, the monitoring, the “why did this break at 2am” parts, rather than just the parts that look good in a sprint demo.

Where I land, after twenty-odd years in this industry, is closer to the “ask, don’t list” camp. Put it on the CV and you risk it reading as filler, or worse, slightly try-hard, especially once you’ve got real professional experience to lean on. But mention it in an interview, when someone asks what you tinker with, and it can do a lot of work. It shows you’re curious without being told to be. It shows you’ll go looking for a problem to solve rather than waiting for a ticket. Early in a career, when there’s not much else on the page, I reckon it’s worth including. Later on, it starts to compete with actual runs on the board, and you don’t want it to look like you’re padding.

There’s a bit in the thread about skipping the “I torrent everything” stack when talking to certain employers. Fair. Nobody needs to know how you sourced your media library when you’re trying to convince a company with billions tied up in IP that you’re a safe pair of hands. Talk about the architecture instead. Talk about why you put things behind SSO, why you separated what’s publicly exposed from what isn’t, why you chose Docker over bare metal or the other way round. That’s the actual signal. Anyone can follow a YouTube tutorial with sudo and blind faith. Fewer people can explain the trade-offs they made and why they’d do it differently next time.

What I find genuinely interesting, and I say this as someone who spends a lot of his working life around exactly this stuff, is that self-hosting is one of the few places left where you get to make every decision yourself, badly if you want, and learn from the consequences without a change advisory board getting involved. There’s something clarifying about being your own ops team. You can’t blame Kubernetes, you can’t blame the on-call roster, you can’t blame a vendor. It’s you, at your kitchen table, working out why your reverse proxy config decided to eat itself.

I don’t know if it should go on a CV. I do know that when I’ve interviewed people over the years, and someone lights up describing why they picked their particular backup strategy or how they debugged a flaky VPN, that tells me more than a bullet point ever could. The document gets you in the door. The conversation is where the actual signal lives.