Programming Interview Tips
September 2011 (perspective of a Ph.D. student)
In early September 2011, I spent two weeks intensely preparing for programming interviews. Here are some notes that might be useful for job applicants who are preparing for these types of interviews.
Before you begin, you need to approach your practice sessions with the right attitude. Think of programming interviews as a form of standardized testing. Don't whine and think to yourself, "but I'll never have to manually reverse a linked list in my job, so these questions are lame!"
Ph.D. students are especially elitist because they somehow think that they are "above" preparing for petty programming interviews. That is a fine attitude if you are applying for pure research or academic jobs, but if you are interviewing at a company that uses programming interviews, then you've gotta prep!
As an analogy to high school standardized testing, I raised my SAT scores by 400 points (back when they were still out of 1600) through a few months of intense practice; there is no way that I could've gotten into MIT with my original scores.
So before you even start practicing, you've gotta just view these interviews as yet another standardized test, another game that you need to play well and beat.
I don't care how smart you are; there is simply no substitute for practicing a ton of problems. Work on problems for as long as you can before your brain explodes, then take a long break to reflect and internalize the lessons you learned through your struggle. And then repeat!
I practiced in front of the whiteboard for 1 to 2 hours at a time and did 1 to 3 practice sessions per day for two full weeks right before my interviews. That was around 40 hours of focused practice, which felt about right to me. You might need to practice more if you have less programming experience.
I used these two books as my main sources of practice problems:
In addition, the Stanford lecture notes on linked lists and binary trees were also a great source of problems:
Even if you are not familiar with the programming languages used in these solutions, you can still code up solutions in your own language of choice and write tests to verify that they are correct.
At The Interview
When the interviewer presents a question to you, immediately sketch out a bunch of examples and ask a ton of clarifying questions to make sure you understand exactly what the interviewer is asking you to do.
Draw several examples and ask your interviewer questions of the form, "for this case, you want the result to be X, right?" Do not make any assumptions without first checking them over with your interviewer.
And whatever you do, don't flip out or try to jump straight to coding up an answer. Chances are, you either
The former is obviously bad, but the latter might actually be worse, since you might have seen a similar problem that does not exactly match the problem you have been given. You will look like an idiot if you try to solve the wrong problem by recalling it from memory!
Common Programming Interview Idioms
Here are some common idioms and patterns that I have observed from doing hundreds of practice interview problems.
Mappings and sets (hash tables)
Always test your algorithm on edge-case examples. e.g., what if the user passes in an empty list or tree, or a list/tree with a single node?