A few things: - Renowned CS programs spend less time than you think teaching you how to actually program. Programming is simply a tool to teach things like theory, algorithms, mathematics, logic, artificial intelligence, operating systems, graphics, and so on. I actually took a class on programming C++ and it was one of those independent self-teaching classes. :) - I think one needs to differentiate between programs…
One more thing: This is why I always find it sort of useless during tech interviews to ask someone who's been out of school for a long time the difference between a thread and a process or the difference between sorting algorithms. It's like people couldn't think of an original question that might actually be of some use to the actual job you'd be doing.
Quite the contrary: if you're in the industry, the difference between a thread a process should be very hot in your page cache. Understanding why ``system("cd ..");'' won't work is pretty vital.
As for sorting algorithm, you should at least know the big-Oh for a good sorting algorithm. In many specialties of programming, understanding what "amortized" means (e.g., in the context of quicksort's performance) is also important.
Somebody out of school may naively think that quicksort is always good as it's O(log N) or (if they never took an OS class-- and OS classes are, unfortunately, optional in some universities) not fully understand why their code is burning up 100% of a single core in a 8-core machine and leaving the other 7 idle.
On the other hand, I can agree that asking questions which are only answered from memory (i.e., either you know the trick or you don't) that will only be in a recent graduates page cache (e.g., remembering all the rules of a red black tree, or a dynamic programming solution to a classic problem) but can -- and should -- be looked up, doesn't make sense (if I see you implementing a balanced tree in a project without at least cracking CLRS open and looking at existing implementations, I'll have a chat with you...)