
Code Interview Reading List - bcjordan
http://codingforinterviews.com/books
======
diego_moita
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>).

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

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

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

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

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

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

------
h2s

        > 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
They're affiliate links, if you buy anything off amazon within 24 hours of
clicking one of them, he gets a cut.

~~~
bcjordan
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>

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

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

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

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

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

~~~
michaelt
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
To me, technology is the tool to make things run, but only good algorithms
could optimize those running things.

