Code Interview Reading List(codingforinterviews.com)
codingforinterviews.com
Code Interview Reading List
http://codingforinterviews.com/books
49 comments
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.
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.
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."
There is some discussion of the topic in "Making Software: What Really Works, and Why We Believe It."
Hmmm. I agree that 'orders' is not an appropriate choice of words.
But I usually don't interpret this kind of claims literally, so I took the GP remark as saying that in practice (IRL) there was no such 'wide gap in productivity', which is opposite to claims/data I saw before (as you mention, 5-20x) and to my own experience.
But I usually don't interpret this kind of claims literally, so I took the GP remark as saying that in practice (IRL) there was no such 'wide gap in productivity', which is opposite to claims/data I saw before (as you mention, 5-20x) and to my own experience.
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.
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.
> 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.
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.
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?
> What's the point?
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?
They're affiliate links, if you buy anything off amazon within 24 hours of clicking one of them, he gets a cut.
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
http://news.ycombinator.com/item?id=4997734
http://news.ycombinator.com/item?id=5008406
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).
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).
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
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
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.
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?
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?
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.
This may affect your response rates. Just saying.
Wow, that is terrible, sorry for the eyesore.
If you're still interested, try it now. It should hide for mobile browsers.
If you're still interested, try it now. It should hide for mobile browsers.
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.
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.
They've released an update book which supersedes 'Algorithms for Interviews': http://www.amazon.com/Elements-Programming-Interviews-Adnan-...
Will look into this, thanks for the pointer. Have you read it yet?
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).
To me, technology is the tool to make things run, but only good algorithms could optimize those running things.
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)
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)
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.
Seriously, it becomes very stupid, a new profession has came: The Interview Specialist.
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.
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.
I can't blame other people for studying for tests, I can just blame the tests.
Have you actually ever competed in online competitions like Topcoder or algorithm competitions like ACM ICPC?
For solving these kind of problems knowing a bunch of known algorithms won't take you too far. They will only be useful in the beginner stages, but as you progress you need to invent new algorithms, make modifications to the existing algorithms (so they test that you really understand the idea behind them), combine different algorithm design techniques, etcetera.
They are often a good proxy to test how creative in problem solving you can be, not just mere rote memorization of algorithms and how good are you at remembering known algorithms.
For solving these kind of problems knowing a bunch of known algorithms won't take you too far. They will only be useful in the beginner stages, but as you progress you need to invent new algorithms, make modifications to the existing algorithms (so they test that you really understand the idea behind them), combine different algorithm design techniques, etcetera.
They are often a good proxy to test how creative in problem solving you can be, not just mere rote memorization of algorithms and how good are you at remembering known algorithms.
I am a region finalist & happen to know a few ICPC world finalists, and though one of them is very sharp analytically, I am not sure how good a proxy such problems are for a web developer, or even for most technical positions. Some of the best problem solvers I know CS-wise (not algorithmic puzzle solving, but real CS research/ implementation) are not that fast of thinkers to do very well in such circumstances without a lot of pattern matching through practice.
You're very confident of your abilities. It could be that they did actually give the job to a stronger candidate.
Sure, I'm far from a great web developer. But I do resent being asked monkey-dance questions that ignore my experience and expertise, in favor of questions I would've done far better on right out of school.
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.
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.
[deleted]
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.
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.
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).
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.
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.
I agree with you. But I'm probably not teaching you anything by saying that mastering important frameworks like :
- Win32 API
- Write device drivers WDM or other
- .NET / ASP.NET
- Java standard library
- Sockets, UNICODE
- DOM, HTML, CSS, Javascript
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.
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.
"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.
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.
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.
I've found actually pairing with the candidate to be a better measure than quizzing their knowledge of algorithms, etc.
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.
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.
> 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.
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.
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.
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.
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.
[deleted]
For those with a some run time in this field: Is coding for interviews mostly distinct from coding in real life?
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.
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.
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.
[deleted]
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).