Code Interview Reading List

I overall agree with you on "Code Complete", but where did you find data that disproves 'orders of magnitude programmer's productivity'? I can't reach the linked website.

I'd be genuinely interested to check that. While still anecdotal, my experience from working in big and small companies in 4 countries is that there certainly is a absurdly wide gap in productivity between programmers.

Very good point about specializing the reading list for the areas developers are interested in. You're right, trying to come up with a one-size-fits-all reading list is foolhardy.

Re: The Pragmatic Programmer and Code Complete, I learned a ton from those books and I'd heartily recommend them to programmers starting their first job or internship, but likely not to someone with a few months before their first round of programming interviews. What do you think?

Maybe I will put together another list more tuned for general programming improvement versus interview-specific prep.

As an aside, Patterns of Enterprise Application Architecture looks very useful, thank you for the pointer.

I'd figure that more interviewers would ask technology-specific questions, but it is hit-or-miss from what I've seen. For example: questions about Framework X or Y that your company actually uses. This would seem to be a lot more important than things that many haven't done since early CS courses (like algorithm gymnastics).

Part of my current work involves designing & implementing pretty intricate & complex algorithms. Earlier I did research & published in a range of ML related sub-fields, primarily NLP & recommender systems. I also read CS papers for pleasure and code in multiple languages.

Yet, if I gave engineering interviews impromptu I am pretty sure I will fail many of them. It's a weird situation in the industry when an experienced person has to go through a bootcamp to revisit/ memorize rather trivial stuff to get a job for which he may well be overqualified.

Sadly true. In my last set of interviews for a web developer position at Google, I aced the questions from fellow web developers, questions relevant to my experience and to web development. Then they sent in a "software engineer" (who probably couldn't code a rich web app to save his life) who asked a disjoint set theory merging question that I struggled with. He grimaced at my "incompetence" and at that moment I hated backend engineers and their superiority complex. Naturally I didn't get the job, but they had the nerve to tell me they gave it to a "stronger" candidate.

Generally aren't these usually the more junior engineers who don't have any sense of responsibility and want to exercise some authority or senior engineers, the best days of their productivity now lie behind them?

It's usually a symptom of a bad company culture to be honest when the people making hiring decisions feel the need to "spread" it around so as not to take the blame for those few bad hires that will inevitably happen.

As engineers we all know that bugs happen and shrug, feel bad for a bit and move on. When someone else makes a bad hiring decision, these same engineers grab the pitchforks demanding to know why they weren't consulted.

It's kind of silly when you think about it as human behavior is much more complex than software. Hiring is hard.

They're affiliate links, if you buy anything off amazon within 24 hours of clicking one of them, he gets a cut.

Just to clarify, as that quote juxtaposition might suggest otherwise, those three instances are from the same, fifth suggested book category—one book that goes in-depth on best practices for developing with "your favorite programming language". I point to five different programming language books, and I suggest you choose only one of those.

  > What's the point?

Re: including pointers to books I haven't read, many solution submitters use python and C++ for their solutions and subsequent job interviews, so I wanted to offer them a good starting point, note my lack of experience with those books and save them some time. I spent a good hour researching what the in-depth language books might be for python, C++ and javascript and offered those suggestions.

Re: the broader purpose of publishing a reading list, a few CS undergrads who read Coding for Interviews separately emailed me about books for interview preparation and general programming practice improvement. A lot of these books get discussed and read in book groups in the industry but not often in undergrad programs.

I hope this helps clarify why I included those. Do you still feel I should remove them?

Here are some that I really liked, which aren't "here's how to program" type books. I'm not going to repeat books that were mentioned in the OP, except to say...The Algorithm Design Manual.

1. Python Essential Reference - Beazley

2. Modern C++ Design - Alexandrescu (mind-blowing; he now works on the D language)

3. Internet Core Protocols: The Definitive Guide - Hall (not a work of any particular genius, but this is stuff everyone should know, in my opinion)

4. Applied Cryptography - Schneier

5. Think Bayes - Downey

6. Interconnections: Bridges, Routers, Switches and Internetworking Protocols - Perlman

i was impressed by peopleware, maybe because it agreed with my prejudices. i doubt it's going to help you with interviews as it's more about culture, but it's a fairly slim book that's worth the read (more than mythical man month, imho).

Your page is difficult to read at lunch on my iOS device because you have those floating social doodads on one side. They obscure your content and I don't want to fight it.

This may affect your response rates. Just saying.

There is a book called 'Algorithms for Interviews' by Aziz & Prakash. It is much more CS centric than CareerCup & does not provide explicit solutions to all problems- which is good.

It also has more difficult questions, on average, and many are not the kind that one would expect in an under hour interview. Nevertheless I find it more easy to read than something like say CareerCup, mainly because it is not so mundane and hence more fun.

There is a very real disconnect between a lot of interviews (whiteboards, algorithms) and what people experience in the (current, prospective) job though.

I've found actually pairing with the candidate to be a better measure than quizzing their knowledge of algorithms, etc.

It's not so much the problem solving and coding skills as the specific algorithm and syntax questions I tend to cram on. My memory is very pattern based so I'm not as good as randomly pulling some snippet up from memory but get me into that problem space and I can more easily give you what you're looking for. This is usually what happens in the real world but in interviews a lot of people just ask random questions with no connective tissue.

"I really dislike the idea of "cramming" for interviews. If a person hasn't been developing problem solving and coding skills throughout their career, then it's hardly something they can read up on and develop in a week before an interview."

You're misunderstanding the issue here. For the type of things that matter in 95% of actual software, it's true that you can't learn all that in a week before an interview. However, those things are somewhat difficult to get across in a 60 minute interview, and good interviewers who can do that are rare. So they resort to algorithm questions because they don't require much skill to know. Which sucks but the interviewee can easily account for it by (re)learning that same stuff with a week of preparation, maybe a little more if they've got no experience in algorithms.

Are you opposed to cramming altogether or just in this case?

I like to think of tests as "you either know it or you don't and if you try to game it you're cheating", but I'm probably just weird that way.

It's the difference between solving a 100-piece jigsaw puzzle with the picture on the box, and solving a 100,000-piece jigsaw puzzle without the box.

A good interview question can be clearly defined in a few minutes, and it can be answered in a few minutes by someone with the general background shared by most programmers without reference to documentation.

Regular coding requires that general background, but often involves larger (and less clearly defined) problems, more complex schemas, more lines of code, more working with other people, more supporting legacy code, and so on. To balance this greater complexity additional tools are available.