- Every interview is different. While there may be many similarities between different interviews, every interview will be unique. Every interviewer has a different style and every candidate has a different background. Various other factors come into play as well like time of day. Interviewing in the morning can be different than interviewing in the afternoon, especially candidate or interviewer is not used to waking up early.
- The questions asked will vary depending on the position and the level it's at. The example here is meant to represent the kind of interaction that would take place with someone who is interviewing for a developer position requiring a college degree and some experience. This persona is assumed purely to facilitate the discussion. Interviews for positions at lower and higher levels follows a similar pattern. In many cases, the same questions will be asked of people at different levels with different expectations for the responses given. In response to the persona, I'd also like to point out that a college degree isn't an absolute requirement for most positions. It does help with getting an interview in the first place though.
- The important part is the method, not the specifics of the example. I would highly recommend against memorizing problems and solutions. Knowing how to solve problems is the key to success.
- This example focuses on the technical interview.Some of the interviews will be technical in nature, but won't involve coding. Some won't be technical at all and will focus entirely on the candidate's personality. While it may happen on occasion, don't expect that every interview through the day will follow the pattern of this example.
1. The Warmup
The warmup is all about helping the candidate to relax a bit. We all know interviews are nerve-wracking and we want to test the undiminished skill of the candidate. In the actual job, there will be many times when there is intense pressure and the team must be able to operate under such circumstances. However, we don't want candidates to be worried about whether they'll get the job. Rather, the pressure should come from the limited time they have. This is more like the deadline-driven pressure they will face later.
Interviewer: Hi, my name's Alice. Pleased to meet you, Bob.
Candidate: Hi Alice. Likewise.
Interviewer: I hear this is your first time in Seattle? How are you liking it so far?
Candidate: It's nice. It doesn't seem as wet as I thought it was going to be.
Interviewer: Yeah, it does actually rain a fair amount, but it's more like drizzle than downpour. So, have you a chance to talk much with other folks about our team and our product?
Candidate: I actually ran out of time in the last interview, but I got a high-level view when I talked to John this morning.
Interviewer: Did you find anything to be of particular interest?
Candidate: Yeah, the asynchronous processing seems really interesting. I've done a bit of that in the past and there are some good challenges around it.
...
What's going on here is a bit of selling the candidate on Seattle, finding out what the candidate's interests are, seeing if there's something for the candidate to get excited about on the team, and a friendly conversation about technology/problems the candidate is interested in. In all, this should be about 5 minutes. 10 minutes would be long since that would take up over 15% of the time allotted to the interview.
2. The Filter
Next comes a simple whiteboard problem that is meant to see whether the candidate should be in the interview at all. This usually isn't an issue since pre-screening over the phone is a fairly effective means of identifying whether the time and financial expense that goes into bringing someone in for a full interview should be paid.
Interviewer: Alright, I hate to interrupt our conversation, but we should really move on. Are you ready for some whiteboarding?
Candidate: Yeah, let's go ahead.
Interviewer: Great. Can you write some code to reverse a list?
Candidate: Sure. In what language?
Interviewer: What are you most comfortable with?
Candidate: I'm pretty comfortable with C, Java, and Perl. I think Java would be my preference.
Interviewer: Okay, perfect. Go ahead with Java then.
...
When you do code interviews, interviewers will usually ask you to work in whatever language you're most comfortable. Of course, there are some cases in which that won't be true. For example, when the interviewer is only familiar with languages similar to C and your preference is to work in LISP, some accommodation is probably in order.
The filter problem should really take between 5 and 10 minutes, including some validation of the solution. When candidates struggle with this one, it's usually a good indication that they aren't quite ready for the job they're applying for. Again, keep in mind all interviewers are different and not all of them will start with a simple problem. Whatever the case, try not to think too much about the mechanics of the interview and stay focused on solving the problems.
Sometimes, poor results on a filter problem will lead to cutting the remainder of the day short. If this happens, it's nothing to be embarrassed about. It just means you need to continue building your skills and come back for another try later (assuming that's what you want). In most cases, shortening the day is the right thing to do since it's respectful of both the candidate's time and the interviewers' time.
To practice for this type of question, my recommendation is to find as many simple problems as you can (or make them up) and try solving them on a whiteboard while you time yourself. If you can, get a friend or two to watch while you do this and point out mistakes. You might get a face full of humble the first time you do this, but if the job is worth it, this practice is also worth it. Over time, you'll find that you get better at solving these kinds of problems quickly as you develop a methodology for cranking out a validated solution. The added benefit is that methodology will also be applicable to...
3. The Real Coding Problem
This is the part of the interview that is really meant to challenge candidates in terms of their ability to solve algorithmic problems with code. This will require a solid understanding of more advanced concepts like pointers, recursion, concurrency, etc.
Interviewer: Looks good. So, here's another one. We need a dictionary class that can print the word list in alphabetical order. Can you implement the class for me?
Candidate: Yeah, definitely. Since we need to print the list of words, I'm assuming the dictionary is dynamic. Can I also assume that word-lookups are frequent and printing the list is relatively infrequent?
Interviewer: Yeah, that's fine.
Candidate: Are there any constraints on how long the function takes?
Interviewer: It should be as efficient as possible, given how we've defined the problem. *smile*
Candidate: *smile*
...
Remember to clarify the assumptions you are making in solving this problem. Many or even most of the assumptions will be up to the candidate as long as they make sense. For years I used to think that candidates needed to ask questions to show the interviewer they are careful in understanding requirements. Once I had spent some time on the other side of the table, I realized that while understanding the requirements of what you're creating is, indeed, important, what's more important to the interview is just getting the assumptions on the table as quickly as possible. That will maximize the amount of time spent on coming up with a great solution to the problem and answering any additional questions the interviewer may have.
In the end, this problem shouldn't take too long to solve. The key is to come up with a reasonable solution quickly and code it up. In my opinion, the biggest challenge is deciding on a single solution since there is some ambiguity around the problem. We don't want to fall into the trap of analyzing every trade-off in excruciating detail. What's more important is for the candidate to make it known that he or she is aware of the trade-off. Something to keep in mind is that even though coding is quiet-time for most people, you need to be vocal in interviews so the interviewer is aware of what's on your mind. Interviewers do want to see a candidate's ability to identify and evaluate trade-offs, but not to the detriment of getting through the interview and having a full picture of the candidate's skills. There will be plenty of evaluation of trade-offs in the open-ended design problem.
When the interviewer does need a little more insight, he or she will ask questions. Expect plenty of them both during and after the coding. Some example of questions include:
- Are you satisfied with your solution?
- Are there any problems with the algorithm/code?
- How would you optimize this?
- What is the run-time?
- What if multiple thread were accessing it at the same time?
- What if this were running on a system with limited memory?
- What is an alternative way in which this could have been solved?
4. The Open-Ended Design Problem
Do you remember all those open-ended math problems, essay questions, and projects you had to do in high school and college? They just keep coming. Life is full of ambiguity and businesses are built on making good decisions in the face of uncertainty. The open-ended design problem tests a candidate's familiarity with important concepts and their ability to made reasoned trade-offs.
Interviewer: Okay, there's a bit of a change with the next problem. I'd like to talk about how you'd solve a larger problem. You won't need to write anymore code, but feel free to use the whiteboard.
Candidate: Sure.
Interviewer: Assume we have a very large distributed system. A major challenge in building and maintaining distributed systems is debugging. How would you design logging to support this system?
...
This kind of question can be open-ended to an extreme. Clearly, there are innumerable ways to solve such problems. What the candidate needs to do is work with the interviewer to define the constraints. In this case, spending some time exploring the options is expected and, in fact, required. It's not so much about hammering out a solution as it is about the path taken to get there. In this part of the interview, the interviewer will look for the ability to identify and address requirements, limitations, strengths, and weaknesses. The interviewer will also look for the process the candidate uses. Do they try to do all the thinking up-front and stick with the initial solution? Or do they do it iteratively, coming up with a rough concept first and continually refining it?
There will definitely be some weaknesses in the system, just as there will be strengths. The candidate should be able to describe what these are while working towards a solution and give reasoning for why they went one way or the other.
5. Question Time
At this point, the candidate may have a few extra minutes to ask some questions of the interviewer. Some interviewers expect candidates to have good questions and some don't care if they ask anything at all. Personally, I like it when candidates ask questions since I appreciate inquisitive nature and it usually provides an opportunity to know a little more about the candidate. But it isn't important and holds no bearing in the hiring decision. Of course, questions like "how much do you make" are in poor taste and shouldn't be asked. That will be taken as being invasive of the interviewer's privacy and indicative that the candidate is more interested in money than the team, product, and company. The time for money questions will be a few weeks later when, hopefully, you'll get an offer!
And that concludes this technical interview. On to the next hour with the next interviewer!
