4 ms·

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 the

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 that teach programming as a trade and a CS program at a top school. I imagine the experiences are quite different. Much like there would be a difference between someone who learned from Learn C++ in 21 Days vs the hallowed Abelsson and Sussman (Alyssa P Hacker anyone?). - I think most lower division books can be read by anyone and they would glean the same amount of knowledge. In fact, I would say there isn't much difference if someone went to somewhere like OpenCourseWare and learned it themselves. - I think you'll find more difficulty at the top end. While it's possible that self-taught programmers would do these exercises, if I ever meet one I'll bow down before him. I'm talking about classes like CS 162 Operating Systems (http://inst.eecs.berkeley.edu/~cs162/sp11/ http://inst.eecs.berkeley.edu/~cs162/sp11/) or CS 170 Efficient Algorithms and Intractable Problems (http://inst.eecs.berkeley.edu/~cs170/sp11/ http://inst.eecs.berkeley.edu/~cs170/sp11/). - With that said, I personally rarely (if ever) use the things I learned in these classes. Perhaps if I wanted to write my own language, my compilers class would be useful. Or maybe if I got really deep into machine learning, then my AI class would have been more use. So, I guess with that said, it's really about what doors were open to me on matters that, even when taught, seemed impossible to understand. Doing it self-taught is just that much harder unless you're the guy from Good Will Hunting. All in all, I'd say that for the majority of people who are not that specialized (like web developers) it doesn't make much of a difference. The people for whom it made a real difference went on to do research in a specific area and are the ones who are hired for some specific knowledge they have (eg. classification algorithms, machine learning algorithms, security, complex statistical models).

freshfunk 16y ago
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.
- strlen 16y ago
  > ask someone who's been out of school for a long time the difference between a thread and a process 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...)
  - fhars 16y ago
    But "amortized" is irrelevant in the context of quicksort, as it is not an amortized algorithm. You may hit an unlucky streak and get the worst case of O(n^2) behaviour on every call. An amortized algorithm on the other had would guarantee that while each individual operation on a data structure may hit the worst case, it will always (and not just in the average case) average out over many operations on the same data structure.
    - strlen 16y ago
      Doh, screw up on my part. You are completely right. An amortized algorithm would be something like a dynamic array (std::vector or ArrayList) in this case, which is doubled every time it hits capacity.
  - strlen 16y ago
    Err, as fhars poster pointed out quicksort is not an amortized algorithm, I should have used a better example. It is, however, a good example of an algorithm with a worst case running time of N^2.

freshfunk 16y ago

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.

strlen 16y ago
> ask someone who's been out of school for a long time the difference between a thread and a process 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...)
- fhars 16y ago
  But "amortized" is irrelevant in the context of quicksort, as it is not an amortized algorithm. You may hit an unlucky streak and get the worst case of O(n^2) behaviour on every call. An amortized algorithm on the other had would guarantee that while each individual operation on a data structure may hit the worst case, it will always (and not just in the average case) average out over many operations on the same data structure.
  - strlen 16y ago
    Doh, screw up on my part. You are completely right. An amortized algorithm would be something like a dynamic array (std::vector or ArrayList) in this case, which is doubled every time it hits capacity.
- strlen 16y ago
  Err, as fhars poster pointed out quicksort is not an amortized algorithm, I should have used a better example. It is, however, a good example of an algorithm with a worst case running time of N^2.