Algorithms and Data Structure Interview Preparation Guide

This article is part of a series I’ve written on senior .net developer interviews. The goal of the series is not to provide a list of interview questions that you might be asked, but to provide a list of questions that ensures that you have a comprehensive understanding of .net and software development. To read the complete guide, visit Interview Preparation for Senior Software Developers.

Steve Yegge already wrote an excellent article on what you need to know in terms of algorithms and datastructures (Get that job at Google) so this post will cover some additional thoughts and how to get the knowledge that Steve is talking about.

Types of Interviews and Generalizations

First, software interviews can be divided into two types : technology focused interviews and interviews focused on software fundamentals. By technology focused interviews, I’m talking about interviews where a question will be based on a vendor’s product such as SQL Server. For software fundamental interviews, I’m talking about interviews where questions are more vendor neutral (so databases in general rather than SQL Server). If you are going to a technology focused interview, it is quite possible you won’t be asked any questions on algorithms or data structures (which in my opinion is a bad sign of what your co-worker’s abilities might be). Assuming you will be asked these questions, here are some thoughts about companies that preform each of these types of interviews.

Software Fundamentals Interviews

Technology Focused Interviews

Google, Amazon, Altera, Yahoo, Apple, Microsoft

Typically consulting companies or companies that need to gain expertise in a new area

Are more concerned with how intelligent/trainable someone is rather than how many technologies they know. They are interested in developing employees in relevant areas if the potential is good.

Expect high productivity early on from new employees

Senior developers and leads are very knowledgeable

May not have experienced leads – hiring may be based on technology buzz words and HR processes rather than software engineering concepts

People that work for these companies generally hold co-workers in high regard

Co-workers may have less respect for each other

These companies generally offer hire salaries and are more competitive about getting good employees (in my experience)

May offer a very high salary if technology is niche. Otherwise, expect salary to be a bit lower.

Not necessarily looking to fill a technology niche that you can be a leader in

Often offers more leadership opportunities, especially if niche technology (since there may not be strong senior developers)

Job postings mention fundamental concepts like OOP or design patterns and not specific technologies. The postings may also request experience in one of several languages rather than C# or java specifically

Job postings mention years of experience with a specific technology. Will generally list things like:

For senior positions, questions will start with fundamentals but seniority will be based on answers to open ended design questions (and resume experience)

For senior positions, determining seniority the interviewer will probably expect you to know a specific detail about the technology. The problem with this is that at the senior level, there are many specific questions about the technology and with this type of questioning, the interviewer is trying to find holes (based on his own understanding) rather than your strengths.

Since interview time is limited, occasionally an interviewer will throw in a tough algorithm problem (often involving a trick) and base evaluate your understanding of algorithms based on that.

Note that the points above are just my general observations and do not always hold true. I’ve had technology specific interviews for consulting companies that definitely contain all the desirable attributes from the software fundamentals section above. Currently, my preference is for software fundamentals interviews since I find technology focused interviews tend to be all over the place. There are usually a couple questions covering a huge number of technologies and your entire understanding of that technology is based on just one or two questions. In this situation, it is very easy to have a false negatives and false positives since questions are not comprehensive.

How to prepare for algorithms and data structure questions

So, assuming you are going to get questions on algorithms and data structures, how do you get that knowledge?

1. Determine what you don’t know

2. Learn the stuff you don’t know

Get a solid foundation in algorithms and data structures – If you don’t know a lot about algorithms (this was my issue since I didn’t study a lot of computer science in university) or need a brush up, check out the two books below. My key criteria for recommending these books is that they are easy to read cover to cover compared to other algorithms books. The best technique for interviewing is to make a list of all the key algorithms (Algorithms (Sedgewick, Wayne)) and then beside each one, describe how to solve it in just a few sentences. It doesn’t need to be in detail; just enough so that you know how to start solving the problem.

Algorithms (Sedgewick, Wayne) -I like head first type books that I can read quickly and remember easily without falling asleep. I think this is as close as an algorithms book gets being similar to the heads first series in that the explanations are easy to understand and not too dry. Here are my favourite things about this book.

Light read, not scary compared to other algorithm text books, not too much math

Offers simple readable code for all data structures

Does a fantastic job of providing clear descriptions of optimizations for each algorithm. This really allows you to shine in interviews because you can show off with something that might be new even to the interviewer

Algorithms organized by problem rather than method (for example, there are chapters on graphs, string matching, searching, sorting, etc but no chapters on greedy algorithms, dynamic programming, etc). Some people may not like this so if you are looking for something that is also pretty easy to read but organized by problem solving approach, I suggest

Algorithms (Dasgupta, Papadimitriou, Vazerani) - I did not read this book cover to cover like the one above. However, I do use it from time to time as a reference and it is a solid follow up to the Sedgewick, Wayne algorithms book. It contains more details on algorithm approach than then one above, however, it is not quite as fun to read.

3. Practice under similar conditions

Join TopCoderand do some practice problems and do at least 5 single round marathon (SRM) competitions – You don’t need a super high rank (even division 2 is fine) but you need to be able to effective approach problems. The things you can expect to be comfortable with after doing about 5 SRMs and reading the editorials after the matches are:

Analizing complexity – you will be surprised how often a brute force solution is enough based on inputs. This will cause you to ask input constrain questions during the interview which shows that not only can you solve problems in multiple ways, but that you know when to use each approach.

How to categorize types of problems – Is it greedy, or dynamic programming

You will be decent at dynamic programming – Interviewers love DP questions because they can be very tricky (I don’t mean just using memoization for fibinocci). You will need to correctly identify which states need to be remembered and in cases where there are many candidate states, this is very tricky

In the end, you will approach your interview algorithm problems with confidence. Just doing practice problems by hand before the interview is not the same since it is so easy to just look up the answer and say “oh yeah, I’m pretty close. I would totally get that next time”. SRMs force you to wait a couple days for the answer after the match which really helps learn the methodology

Thoughts on Questions with a Trick

A trick question is one where you need to have a moment of inspiration to solve the algorithm. For example, given a sorted array of numbers, determine if there are two that add to 30. If you have not seen the problem before, you might ho and hmm until it clicks. Have a pointer on each end of the list. Add the two numbers together. If the result is greater than 30, move the pointer on the right on position left. If the result is less than 30, move the pointer on the left one to the right. This O(n) solution does not determine if the candidate knows anything about alogrithms. It just shows that either the candidate got a moment of clarity at the right time, or has seen the problem before. In my experience with interviews at tech giants Amazon and Google, I did not receive any trick questions.

Trick questions give a lot of false negatives and as far as I’ve seen, mature companies have decided to stop using them. If you do get asked a trick question and don’t get the answer, don’t feel bad. Perhaps the company asking it needs to update their hiring policy :)