Part of the technical assessment I have for hiring new platform engineers involves troubleshooting a service hosted in a headless Linux vm.
Troubleshooting and fluency on the command line are among what I consider core skills. Being able to dig through abstraction layers is not just essential for when things go wrong, they are essential for building infrastructure, and really tells you whether an architecture is fit for purpose.
One of my favorite interview questions: "Here are some SSH credentials. What does this system do?"
Sometimes there aren't any docs. Sometimes the docs are wrong. It's important to be able to establish what the actual running situation is.
Sure... but, I’ve got decades of experience doing that stuff, just not frequently enough to keep it in my head, these days. I usually want a small project server to just do shit and the less there is between that and booting up a fresh Linux install, the better. For example, I don’t keep firewall command line syntax in my head, but I know what needs to be done, and I always seem to need it with small home projects. I lose nothing by having a trustworthy gui do it. I’d give this a shot. I doubt I’d use it in a professional environment, but that’s not really my use case these days.
From a professional perspective, this is a solid question. And yeah, between the basic tool suite (top/cd/ls -l/df -H/grep/pipe '|'/ssh) and some common sysadmin/engie knowledge, I could get by with Linux just fine. "Just fine" doesn't cut it for troubleshooting sludgepipes and Kubernetes though, and my skills with Powershell finally gave me the confidence boost to take CLI/TUI seriously on Linux.
And man, zero regrets. It's nice having an OS not fight me tooth and nail to do shit, even if it means letting me blow my feet off with some commands (which is why, to any junior readers out there, we always start with a snapshot when troubleshooting servers).
Now to finish my mono-compose for my homelab and get back to enjoying the fruits of my labor...