Main image of article 5 Steps to Cracking the Coding Interview
Software engineers typically face a double whammy when it comes to a job interview. They not only have to ace their meeting with the hiring manager and team members, but also need to score well on their coding tests. Gayle Laakmann McDowell knows a lot about this. She's the author of Cracking the Coding Interview: 150 Programming Questions and Solutions and The Google Resume. She's got good advice on acing coding interviews.

[youtube http://www.youtube.com/watch?v=aClxtDcdpsQ&w=560&h=315&wmode=window&h=315]

Prepping for the Phone Interview

For starters, never assume the pre-screen phone interview will be a breeze. It never is. Even during this initial screening, coding tests can be as rigorous as they are in the  second round of coding tests, says McDowell, a former software engineer who once served on Google's hiring committee. Typically, the interviewer and you will share a document in which you are expected to do some coding. In other cases, you'll take an online multiple choice coding quiz or use an online test site like Interviewstreet. And don't think you'll be dealing with HR on the pre-screen. "Usually, it's a peer who will do the pre-screen because the information they're evaluating is very technical," McDowell says. This interview is meant to evaluate you for:
  • Knowledge of computer science fundamentals, such as data structures and algorithms.
  • Analytical skills.
  • Coding skills.
  • Cultural fit.

On to the Second Interview

The second interview is usually with the hiring manager, members of the team you'd be working with, and frequently, a third person from an entirely different team. It's this last person you should pay especially close attention to. "You may have a team that's been short-staffed for months, so they're eager to hire anyone. This [neutral third-party team member] is a bar raiser. Their questions may not be harder, but their standards are higher," says McDowell. Usually, she adds, the bar raiser asks harder questions.

5 Winning Steps

When faced with a whiteboard test, McDowell advises taking these critical steps:
  • Ask questions. You want to make sure you understand what you're being asked to solve.
  • Talk out loud as you solve the problem. The interviewer wants to know how you think and problem solve. If you remain quiet, it's harder to ascertain that.
  • Openly discuss the trade offs in your algorithm decisions. Acknowledging the weak links in your approach demonstrates that you're aware where potential trouble spots may arise, and offers up why you were willing to make your trade-offs.
  • Write code. Although you can sketch out pseudo code for an outline, you need to inform interviewers that's what you're doing so they don't assume it's your final version. After writing pseudo code, you'll need to hunker down and write the actual code.
  • Test your code. Interviewers expect to see bugs, so don't be shy about fixing them. What they're looking for is how you fix the bugs. If each interviewer notices a pattern where you take a band-aid approach that's likely to introduce other problems, don't expect to be hired.

Here's a close-up of McDowell's coding on the whiteboard:

Bombing the Interview — or Not

After an interview, you'll want to assess how you did. But it's not worth the effort, and you'll often be wrong. "I've found there is zero correlation between how you think you did and how you did," McDowell told me. "You may think you did well because the interviewer was nice to you, but it could be because they felt sorry for you. Or, you may think you didn't do well because the interviewer was tough, but the interviewer may have been pushing you harder because you were doing so well." Keep in mind that interviewees are graded on a curve, McDowell says. So, just because you think you completed the coding test in a fast 10 minutes, you don't know whether the other candidates have been doing it in five.

Reasons for Rejection

Not getting these jobs often boils down to a lack of problem-solving skills, or not being able to solve the problem quickly enough. It means, unfortunately, the interviewers didn't think you were smart enough to handle this particular test. Another deal breaker is arrogance. Remember, you often have to work as a team. "Engineers are consistently rejected because of arrogance," McDowell says. "Be careful how you answer questions. Rather than say something like, 'I did all the hardest parts of a problem,' be specific and explain what you accomplished." If you know you tend to be arrogant, temper it by demonstrating how well you can listen and remain cool if the interviewer challenges you with questions like, "Can you further optimize your code?" Says McDowell: "The worst thing a candidate can do is argue with the interviewer." If you want to grab more of McDowell's advice, she'll be one of the speakers at Silicon Valley Code Camp this weekend. It's a free event at Foothill College in Los Altos Hills, Calif.

Related Links