While this is true, I have never needed to explain CS stuff in an interview, it is also true that very often when faced with a tough algorithmic problem even the little CS foundation my few years of formal education in the field have granted me helps quite a bit. If nothing more than the fact I know what to google for.

It's surprisingly easy to google for solutions once you know what you're looking for instead of searching descriptively :)

Ha, you said it man. Looking back I began to realize that this was the biggest benefit of my degree.

Technically, a homeless person could dig in at a terminal in the library and teach themselves anything they needed to learn about computers. However, first they'd need to know what to look for and by God that was difficult before I spent 4 years talking to people who worked with computers all day. I think my time on Reddit actually enriched me there a bit, too.

You figure out what you need to learn by doing something, which is why working on a project is so nice.

In today's day and age, it's true that Google will likely lead you in the right direction. However there really is no more efficient way to get a mental lay of the programming land than a quality CS program. Dynamic programming algorithms for example, are something that very few will ever stumble into on their own. You might get lucky when Googling, but it's not the same as having a mental model of the breadth of CS fundamentals.

Sure, but I still think it's more efficient to learn while you work on something real. When you do this there is less waste on certain topics you never encounter, and because you need what you're learning it's better absorbed and understood. It's just this method is less practical for employers since they just want someone already equipped with what they need.

Throughout my career, I've met many developers who couldn't code their way out of a paper bag, network engineers who couldn't network their way out of a paper bag, sysadmins who couldn't sysadmin their way out of a paper bag, etc.

I propose a new interview question: How would you code your way out of a paper bag? You will be given several constants, such as the strength of the paper bag, difficulty of tearing, etc, and will be expected to write your own Tear() function and call it properly.

The best part is that when the recruiters/headhunters ask why you rejected a candidate, you can honestly say "he couldn't code his way out of a wet paper bag."