None of which you will ever be called upon to do during your career. You are paid to judiciously use all of the above, not regurgitate the standard implementation. Which is not to say that your efforts are entirely wasted - there is value in deep understanding of the fundamentals, but it is an insufficient parameter for employment.
> "Wrote several built-in linux commands and other commands (i.e. tail, ps, pstree, etc.) from scratch using only the linux kernel and system calls."
See above. Rewriting shell commands is really, really, really far from, say, engineering a highly scalable e-commerce platform that can take literally millions of hits per minute.
The problems we work on in private industry is way harder, way bigger, and way more involved than reimplementing select, discrete pieces of Linux. We also do it in teams, so your lone gunman bit won't exactly work out.
This is the problem we run into when interviewing hardcore academics - so many John Wayne-types who have never worked at production-scale, who have never experienced the full breadth of building a product (as opposed to simply write working code), who trivialize the endeavor, and then find themselves overwhelmed. Computer science is only a tiny sliver of what a software engineer has to do in his day to day.
> "If this isn't enough experience, then I must be living in a fantasy land."
Welp, sorry to burst your bubble. It's insufficient. You could've spent all of that time interning for software companies and your odds will be much, much better. To be fair though, there are a lot of your peers who don't even have said projects under their belts, so you're far from scraping the bottom of your peers.
Experience, experience, experience, this is mantra we need to repeat at every new CS student. Code is only a tiny part of your day in the private sector, your mastery of the full scope of being a software engineer is far more important.
> "but many of these projects (ones with arduino and linux) could qualify."
Unless these projects were shipped to users (whether it's the public or a client), and unless these were done as part of a team, they really won't. The benefit of open source experience is less about the open source part, and more about having been exposed to how a real, product-shipping team operates.
Lone-wolf open source projects are, of course, of some value, since it serves as a reasonable work sample, but it does not eliminate the need for team software experience, which is the real benefit of joining an active open source project.
> "Go figure, they know a lot about algorithms that the programmers probably just use API calls to do."
They know a lot about the algorithms, but they have no fucking clue when it comes to implementing and applying this in a real-world context. And sadly, shipping product is what makes money, knowledge of algorithms is not an end, it is a means.
> " I mean I'm talking extreme no-no's (i.e. magic numbers, lack of enum use, lack of comments, no early exiting loops, god objects etc.) stuff that I actually got marked down for in my college assignments."
Here's the trick: these are minor problems in the grand scheme of things. Which is to say, you can fix a programmer that has bad style, but you cannot fix one that just doesn't know WTF is up. I will hire an excellent engineer with mediocre code style over a mediocre engineer with excellent style. One helps ship a product, the other will write perfect code that has trouble proving relevant IRL.