Interviews reveal a lot. What they can't reveal is the gap I want to talk about, because it never shows up on a CV. It shows up at 3am, when something breaks and the person on call has excellent cloud instincts and no idea where to start looking.

A lot of engineers now start their careers entirely in the cloud, and the troubleshooting instincts you used to pick up from bare metal in your first years are getting skipped. The cloud is a fine place to start a career; it's where the jobs are, and I'm not going to pretend otherwise. But some part of the craft only transfers if you learned it with your hands, and I think we're quietly losing it.

I want to be careful with this, because it's one trivia question away from being a boomer rant. It isn't one. Nobody is better for having suffered through SCSI termination (okay, marginally better, but that's not the argument). The argument is that the cloud hides the layers, and the layers are where the answers live.

What the metal teaches you, without asking

If you read about the rack in my studio, you already know I learned this the slow way. Pulling cable through a room I also slept in. Labeling both ends of every lead because future-me would otherwise be crawling under a desk at midnight. Watching link lights like a hawk because a port that negotiates at 100Mbps instead of 1Gbps doesn't announce itself, it just makes everything mysteriously slow.

That phase teaches you things no course bothers to mention. That every problem is physical somewhere, even the ones that look purely logical. That the machine you can't SSH into still has a serial console, and the serial console will tell you the truth when the network won't. That a failed disk isn't an incident, it's a Tuesday, and the RAID rebuild will run all night while you watch the percentage crawl and question your life choices.

The biggest lesson is an attitude, not a fact: you learn to ask "what am I actually standing on?" Before the OS, there's firmware. Before the firmware, there's hardware. Before the hardware, there's a cable somebody crimped badly, and it's always possible that somebody is you.

Troubleshooting is a layered habit

The actual skill the cloud skips isn't hardware knowledge. It's the habit of isolating from the bottom up.

Is it plugged in? Is there a link? Does it have an address? Can it reach its neighbor? Does DNS resolve? Does the service respond? One question at a time, one change at a time, and you observe after every change instead of shotgunning five fixes at once and hoping one lands. When you've troubleshooted at the physical layer, where the feedback loop is "walk over and look at the light," this discipline gets drilled into you early, and it never leaves.

Now watch what happens when someone who has only known the cloud hits a real problem. The application can't reach the database. The cloud-native reflex is to restart the pod, bump the memory limit, and check the managed database's dashboard. The metal-raised reflex is to ask what exists between the app and the database: a network policy, a route table, a security group, a DNS record, an ARP entry. The pod restarts and nothing changes, because nothing was wrong with the pod.

The instincts transfer to the cloud with almost no loss, and that's the irony: the cloud is just someone else's metal. The VPC is a switch you didn't have to cable. The security group is a firewall you didn't have to configure from a blank file. The managed database is a machine in a rack, in a building, with power and cooling and a disk in it that will eventually die. Someone else babysits the bottom layers, which is a legitimate trade. But you should know what they're babysitting, because when one of those layers leaks, and they do leak, the person who has seen the thing under the thing recovers fastest.

Why I still build it the hard way

This is where the blog's whole thesis shows up again, and I'll keep it short because it's been said before: I run real hardware at home partly for privacy and sovereignty, but partly because it keeps that layered habit alive. When the 1am VLAN lockout happened in my studio, I learned more in two hours than any certification ever taught me, precisely because every layer in the path was mine: my switch, my firewall, my config mistake. There was no provider to blame, no ticket to file, and no abstraction to hide behind.

There's a version of engineering where everything is someone else's responsibility except the top layer. It's comfortable and it pays well and I don't think it makes you a worse person. I just think it makes you a more fragile engineer, and fragility only becomes visible during incidents, which is exactly when it's too expensive.

So if you're early in your career and you've only ever worked in the cloud: go break something you own. A spare box, a Raspberry Pi, a old laptop with Linux on it. Cable it, address it, break the network on purpose, and fix it from a serial console with no dashboard in sight. It's cheap, it's private, and no interview question can take the instincts from you afterwards.