Preparing for technical interviews

Question

When interviewing for a programmer position, how can I be very thoroughly prepared for the technical interview (writing code on a board)? I'm asking specifically about interviews at companies(like Google) that tend to ask more algorithm design questions, algorithms that aren't in all college courses or textbooks and are used very often in daily programming. It seems that just doing a lot of programming doesn't do much to improve one's chances at the technical interview because the questions usually aren't something you're likely to encounter so what are some ways to be well prepared for these?

Examples of questions are to write code to: serialize/deserialize a tree, verify if a given node is valid in a binary search tree by climbing up the tree (rather than the other direction which can be done with a normal search), or find the maximum subarray. Usually the interviewer is looking for the most efficient answer and relatively quickly.

I did look at the book "Programming Interviews Exposed" but it doesn't seem to have that many sample questions and they aren't difficult enough.

Do you have any suggestions how to be very well prepared for these algorithm design type questions?

Answer 1

Actually creating working implementations of the various algorithms and data structures that you think might come up is the best way. Don't concern yourself too much with trying to know them all, as that it nearly impossible.

Having an excellent command of Big O notation is important in such interviews.

When I interviewed with Google, I was asked to code a Quick Sort and be able to discuss its performance characteristics under different scenarios.

Answer 2

I think the preparation is what you've already done up to this point, and trying to "cram" for an interview is the wrong approach.

While it never hurts to brush up on areas you might be weak on, trying to target potential technical questions that you may be asked is really a losing proposition, because the interviewer is probably going to ask you all kinds of questions (if they are a good interviewer) and if you go in expecting it to be like a test you've studied for, you're probably in for quite a shock.

TIP
I'd just make sure whatever you put on your CV that you know it well, the worst possible thing to do is put something down that you've only used once or twice and then get crushed in the interview by some question that you don't know because you aren't familiar enough with the technology.

TIP2 When I interview people, I look for attitude and aptitude. If the person has a great attitude (or work ethic is another way to put it) and their aptitude for learning is good, then this is a candidate that I'm interested in. The thing is, if they have those 2 things, then they can learn whatever the whiz-bang technology of the day is.

Homework
While I don't recommend cramming for an interview, I do recommend reading Joel's excellent article on interviewing, which should give you some valuable insights.

Good luck!

Answer 3

Simply show an understanding and technical know-how of the technology you are being interviewed for -- if you do that, you shouldn't have any issues. Other than that, simply just be honest. If you don't know the answer to a question you are asked, admit that you don't know the answer. Don't waste the interviewers time trying to magic up an answer to something you've never had exposure to. You would be suprised how far the answer "I don't know." will go in a technical interview. No one knows the answer to every programming question. In this line of work, you simply don't get exposed to everything there is to know about programming, and any good interviewer will understand that.

Be excited, be passionate, don't bull-shit.

Hope that helps. Good luck!

Answer 4

These questions are usually designed to be challenging and the interviewer isn't necessarily expecting you to have the right answer. More important than seeing a candidate regurgitate a correct answer is seeing how they work through the problem. Failing to solve their problem on short notice but demonstrating that you can think through it in a logical, methodical way is more valuable to most interviewers. After all, the problems you will tackle on the job aren't always going to be problems that you have seen before. If the interviewer wanted something that could simply spit out answers to a given problem, they would have bought a book. They are hiring a person because they need someone who can adapt and attack whatever problem that they may be assigned. Scribbling down an answer that you happened to know off of the top of your head doesn't demonstrate any real capability (beyond that of a parrot) to the interviewer.