Code Interview Reading List

by bcjordan • 14 years ago

166 45 14 years ago

bcjordan7• 14 years ago

I'm curious to hear others' suggestions, especially for the programming language books I haven't personally read.

Just to note, those are Amazon affiliate links. Proceeds from Coding for Interviews all funnel back into the list's MailChimp fees (I just made it last month, and the list has grown a lot since then).

cgh• 14 years ago

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

naner• 14 years ago

Schneier's Cryptography Engineering (previous ed. was called Practical Cryptography) would be a far more useful crypto book than Applied Cryptography. I believe Schneier himself even recommends skipping his seminal book.

bcjordan7• 14 years ago

Thanks for the suggestions, just ordered a copy of Internet Core Protocols.

Are you familiar with either Expert Python Programming or Effective C++? Would you suggest Python Essential Reference and/or Modern C++ Design over either of those for undergrads preparing for interviews in those languages?

andrewcooke• 14 years ago

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).

rachelbythebay2• 14 years ago

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.

bcjordan7• 14 years ago

Wow, that is terrible, sorry for the eyesore.

If you're still interested, try it now. It should hide for mobile browsers.

kubrickslair3• 14 years ago

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.

mikevm• 14 years ago

They've released an update book which supersedes 'Algorithms for Interviews': http://www.amazon.com/Elements-Programming-Interviews-Adnan-...

bjhoops1• 14 years ago

One of those mentioned in this article that I thought was particularly great was GUI Bloopers. I read this in college and when I went to work in the industry I was almost immediately tagged as a developer with a "good eye for design" (we had no actual designers) despite having had literally no other GUI experience.

This is a fantastic read that should be required reading for everyone in The Enterprise.

(Of course, with this newfound awareness comes massive frustration working on Enterprise applications which routinely serve as anti-patterns of UI design)

diego_moita• 14 years ago

The problem with any book list like this is the scope. Software is turning into a very diverse culture, a very heterogeneous ecosystem. Subjects that are very important to one area might not be as important to other areas. Design patterns are essential for enterprise development, not so much for AI and low level systems programming. Algorithms are essential for the latest but not for the former.

Given this, there are some books you might add or remove depending on the area you are interested (e.g.: Knuth's "Art of Computer Programming", Martin Fowler's "Patterns of Enterprise Application Architecture", ...)

To finish, 2 books people recommend a lot for beginning programmers:

"The Pragmatic Programmer"- Hunt, Thomas: a very good book, with sound advice and very easy to read. The only bad side is that it became so influential that its ideas became vulgarized in thousands of blogs.

"Code Complete" - Steve McConnel : A very dangerous book. It does give have a lot of sound advice. But, IMO, it has some big problems. First is that it gives the false impression that there is a lot of empirical evidence on what works on software engineering. Second, it perpetuates some myths that don't have such evidence: the "orders of magnitude programmer's productivity" and "the cone of uncertainty" (see: https://leanpub.com/leprechauns).

tellarin2• 14 years ago

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.

tjpick• 14 years ago

Original source FOR the "orders of magnitude" claim seem to usually point back to Fred Brooks Mythical Man Month (5-10x) or Robert Glass (Facts and Fallacies of Software Engineering) 28x. I don't think either of these multipliers are accurately expressed as "orders of magnitude", regardless of them being supported by evidence.

There is some discussion of the topic in "Making Software: What Really Works, and Why We Believe It."

bcjordan7• 14 years ago

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.

sigsergv• 14 years ago

And forget about your experience! It doesn't matter at all! Only algorithms teasers and CLRS-excercises combination matter!

Seriously, it becomes very stupid, a new profession has came: The Interview Specialist.

noarchy• 14 years ago

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).

Serplat• 14 years ago

The theory behind it is that material about specific frameworks is easily learned. If a company is looking to hire you, what you currently know matters far less than what you can learn. The best developers are able to master new frameworks in days or weeks, making their current experience near meaningless.

So, instead of testing what you current know, many companies look to evaluate the way you think and your potential to learn. I'm sure that the current methods of doing this aren't perfect, but I think they're a hell of a lot better than asking me minute Hibernate details when I haven't used Hibernate in years.

I currently prefer overall design questions. The type where the interviewer proposes an overarching problem, and you have to design a full system to handle it (not a difficult algorithm necessarily, but the data structures and classes involved). Mix this with a bit of actual coding, and I think the interviewer can get a decent idea of your skills.

kubrickslair3• 14 years ago

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.

jquery3• 14 years ago

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.

thelarry• 14 years ago

I've been there. I think the idea is to look for people who can "solve problems" and can use the right algorithm for the right problem. In the end, it seems that candidates just spend a lot of time practicing algorithm problems in online competitions to get good at the questions so that they can recognize the base problem in interview questions and implement answers really quickly. Just because you've been spending hours doing online competitions and remember algorithms really quickly doesn't make you a good engineer in my book. Especially when you will probably forget all of them the second you get your job and stop practicing.

I can't blame other people for studying for tests, I can just blame the tests.

rhizome• 14 years ago

YAGNI doesn't exist in the corporate world, and software development may be one of the only professions where overqualification is desired.

lclarkmichalek• 14 years ago

You're very confident of your abilities. It could be that they did actually give the job to a stronger candidate.

shawn-butler• 14 years ago

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.

jlarocco2• 14 years ago

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.

In most cases, the point of coding interview questions is to see how a person goes about solving a problem as much as it is to see the solution. "I know this because I just read the solution in 'Interviewing for Dummies'" doesn't help at all.

vertis• 14 years ago

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.

MattGrommes• 14 years ago

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.

scarmig• 14 years ago

"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.

rachelbythebay2• 14 years ago

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.

xtracto• 14 years ago

FWIW I think exactly the same way. Since I was in high school I remember not studying a lot for the exams the day before. This was maybe a combination of me being lazy or uninterested and because I thought that whatever I did not know "by heart" at the time I won't learn in 5 hours.

Still, I got out of HS quite fine, I got a BSc with highest GPA of my generation and went to do a PhD in Comp. Sci.

Nowadays I have to do interviews quite often and I although I use some of the "programming riddles" (there is so much you can test in 1 hour phone interview) I usually try to "read" the most I can from the guy I am interviewing.

jlarocco2• 14 years ago

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

No, I think cramming in general is kind of silly.

> 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.

Yep, that's almost exactly how I think about it.

TinyBig• 14 years ago

For those with a some run time in this field: Is coding for interviews mostly distinct from coding in real life?

Cowen• 14 years ago

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.

michaelt• 14 years ago

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.

revskill• 14 years ago

To me, technology is the tool to make things run, but only good algorithms could optimize those running things.

h2s• 14 years ago

    > Five essential books
    > To fully prepare for your programming interviews,
    > you should have access to information on at least
    > these five key topics:

    > I haven't read this yet myself

    > I haven't read this myself either

    > This book is new. As of this writing, the
    > book has not been released yet. Perhaps it
    > is the Effective C++ of Javascript.

How strange. I've never seen anybody propose a reading list with so many books that they admittedly haven't read themselves. What's the point?

cgag• 14 years ago

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

bcjordan7• 14 years ago

Correct, that is how they work, but not my reasoning for including those books. See:

http://news.ycombinator.com/item?id=4997734

http://news.ycombinator.com/item?id=5008406

bcjordan7• 14 years ago

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?

Code Interview Reading List

Related Stories