What every computer science major should know (2011)

I notice that the section on Networking has nothing to do with building cross-company relationships with your peers and future business contacts.

Nothing is said about interviewing or salary negotiation.

Suspiciously absent is the section about how to balance doing something correctly against doing it profitably--or how to stop arguing with your manager before you get fired.

I have to assume that someone majors in computer science as a means to land a job in the field. We all know that hobbyists don't need the expensive degree credential. The vast, overwhelming majority of work now available for software professionals is to take someone else's shit code and make it work better. A very tiny fraction of it is producing all-new code that is done right the first time. As a new grad, you are probably not going to get that work, and even if you do, your inexperience in the real world will probably still make it shit code that someone else will have to improve.

You do need a resume, even if you have a stellar portfolio, because the majority of available jobs are filled by people who don't know what a github is, or how much their mechanic charges to fix it.

It is blindingly obvious that the writer is an academic, who has never held a developer position in a startup, a mid-cap, a megacorp, or a government.

In the real world, the only skill you absolutely need is to learn exactly what you need to be productive. You don't just make yourself "T-shaped"--you also cultivate the ability to make yourself "Pi-shaped" by quickly growing a new stem of deep knowledge.

Thanks for completely dodging any kind of substantive point I might have had. I can move the goalposts such that my opinion is always right and I can always win, too. But I generally try not to because that isn't the point of HN, at least as far as I can tell.

Here's my point. There are many, many software jobs. Only a fairly small subset of them need serious data structures and algorithms work. But interviews tend to focus on data structures and algorithms brain teasers, regardless of the actual day-to-day of the job.

I say "fairly small subset" here because that's the actual truth. There's a huge swath of programming that can get by magnificently with nothing more than arrays and hashtables.

I had a friend interview with Google to work in their uptime group or something like that. He had to solve some brainteaser about generating an in-order list of numbers that meet a certain criteria in O(n) time and constant space. I get that someone somewhere thought it was a good idea. But if you're tasked with keeping failures from happening being able to solve that brainteaser doesn't say anything about your suitability for the job. Being able to imagine disaster scenarios and how they'll play out seems a lot more important to me.

Now I'm not Google so who is to say that my opinion is right and theirs is wrong. Perhaps they're happier with the subset of folks who can do both. But it seems like they might well be missing out on the people who can imagine how bad it could get and help plan for that but who didn't take advanced data structures and algorithms.

Give that, I don't accept your premise. There is a huge swathe of programming that can get by day-to-day using nothing more than arrays and hashtables. And, all else being equal, in my experience this work is consistently done much better by people who can understand and reason through what is going on in a slightly more complex data structure, or describe the function of a recursive algorithm, etc. Completely avoidable design errors are often made by people ignorant of why what they were doing was algorithmically silly or using inappropriate data structures. This is often all so avoidable.

I was very explicit that I don't think you should give "brain teasers" and expect people to "perform" them in an interview. And I was very explicit that I think there are lots of other areas that are at least as (and often more) important to get into in an interview situation.

However, any developer with reasonable fundamentals can reason about a red-black tree, even if they've never seen one before.

So yes, I don't expect you prove the big O of the search time, but i might ask you why we would want to balance a tree at all, and what the balancing algorithm is achieving once you're shown it. And I'm not going to ask anyone to implement one from scratch on a board, but I might show you an implementation and ask you what your thoughts on testing and corner cases to analyse would be.

These are perfectly applicable questions (perhaps excepting entry level), and vastly more relevant than how a TLB works, which was my point. To be honest, I'd probably use something even simpler, but don't feel R-B to be unfair.

I even stated that you don't have to get these answers "right" but the discussion is useful. If you get the details wrong but say sensible things, that's great. If you can't reason anything out about it even with some handholding, it's a bad sign.

So I feel you've completely mischaracterized my response, as what I'm talking about has nothing whatsoever to do with your friends description of their google interview.

Now to your broader point - would I prefer a candidate who was an ace at algorithms but couldn't reason about system failures and risk mitigation over someone who could "imagine disaster scenarios and how they'll play out" but can't talk sensibly about a simple data structure?

Honestly I wouldn't particularly want either of them on my team, so I hope there are better candidates.

> Honestly I wouldn't particularly want either of them on my team, so I hope there are better candidates.

It'd be nice, but Google is hiring up lots of people and it's getting hard to get everything you want. Better, faster, cheaper. Pick two.

My point was not to denigrate CS, but in fact to say that it is something larger then just engineering. Sometimes what we do is engineering, sometimes it's science, sometimes it's math, and sometimes it's carpentry.