No Stupid Questions

The CS job market is very location specific, so I don't have much advice in that regard.

I've got quite a bit of experience with Linux and I manage a home server, but that probably doesn't differentiate me much.

That said, I have been on my company's rotating interview panel for about a decade now, and while my company's line of work involves a lot of Linux development, I can say that most of our college hires do not possess very much Linux background at all. Sure, they might have used Linux machines for school projects, but rarely do any of them assert to be "experienced" with Linux.

By that, I mean deeper knowledge than just using Bash. If a candidate can tell me why they prefer csh over Bash, or any syntax difference between POSIX sh compared to Bash, that is definitely a distinguishing quality. It speaks of an operator who has enough usage under their belt that they're annoyed by the typical distro's defaults, and more importantly, assessed the available tools, and picked the right tool that works for them.

I cannot understate how valuable it is to us to find a candidate that understands their tooling, especially right out of college. Considering that we assume most new hires have to be brought up to speed over the first few months, a candidate that saves us that effort is at least one rank above their peers.

Deeper functional knowledge comes in other forms as well. It's one thing to know how a C program's main() function is invoked by an OS, but anything which shows a fuller understanding of, say, system architecture and how a timer interrupt leads to a context switch in an assembly ISR, to a returned service call to load an ELF, to a CPU privilege ring change, to crt0, to main(), that is another level entirely.

I've interviewed candidates that had side projects involving retro game disassembly. So maybe they couldn't give me the above level of detail for x86, they could describe the same for MIPS. And that's good enough, because most architectures do roughly the same thing, with a few different semantics and names.

Circling back to managing a server, if you had to deal with PAM, NAT and port forwarding, tunnels and VPNs, compiling from source, or abything like that which is non-trivial, do not sell yourself short. All that stuff is resume material, because if you can relay to an interviewer that you've dealt with real network or machine security tasks, it is distinguishing.

The best part is that you have all of college to learn the CS curriculum, but it's also time that you have to pursue any particular focus that excites you. I've written earlier about how embedded engineers don't really get caught in the hype cycle, so jobs don't suddenly appear then disappear a few years later. If you wanted to do that route, getting started with any microcontroller (eg Arduino, STM32) would help, with a goal to understand all the "magic" that the IDE and compiler are doing. Maybe instead you like das blinkenlights and find yourself drawn to hardware design. It wouldn't be too late to consider a switch to the Computer Engineer (CE) major, so you have a small taste of the EE life.

CS as a field is so large that there are many routes between "I want to work with computers" to a declared major and to a career thereafter. Fortunately, time is on your side; this would be a very different conversation if you were a 4th year college student.