Interview Guide - 45m

We don't believe there's anything to gain by surprising candidates in an interview. Programmers don't typically code under pressure at real jobs. We want to see how you do when fully prepared, not when nervous. To that end, we list here the two types of questions we ask, how we evaluate them, common mistakes candidates make, and how they can avoid these mistakes.


Experience questions

One of the best ways to tell if someone is a good programmer is to talk about the programming they've done in the past. This is fairly simple. We ask you to pick a project that you're proud of, and talk to us about it. Then we ask questions about how you built it, and why you made the decisions you made.

The primary thing we look for is depth of understanding. We want to see how you thought about the technical decisions you made.

There are a few mistakes that candidates make on experience questions. Here's how to avoid them:

  1. Always know which project you're going to talk about ahead of time.
  2. Choose a good project to talk about. If a candidate picks a project with no technical depth (a static webpage, say), it's hard for us to dig in. On the other hand, if the project has lots of technical depth but the candidate doesn't deeply understand it, it's also hard for us to dig in. The solution is to pick something with technical depth, that you understand. A school or group project is fine. We don't care if it's impressive. We care that you are excited about it and understand it (these things usually go together).
  3. Don't undersell yourself. Candidates are sometimes too modest, and are unwilling to talk about their accomplishments. The best advice we can give to people who may have this problem is to practice. Decide early what project to talk about, and make a list of all the things you did on this project. Then, practice talking about these things with a friend.

Programming questions

We don't believe in asking hard algorithm questions or brain teasers, but we do think there's value in asking candidates to program. We often ask multi-part questions, starting with something very simple, adding requirements, and seeing how the candidate changes the program. We like to do this over a screen share, so the candidate can work in their own environment and language.

The primary thing we look for in programming questions is fluency in code, how well the candidate understand the problem and their own solution.

There are two common mistakes that candidates make in programming questions:

  1. Candidates sometimes can't solve one question, think they're failing, and become nervous. People don't perform well when nervous. The solution is to understand how we evaluate interviews. We're not looking at average performance. We're looking at max performance. It's totally fine to start with simple, inefficient answers, to ask for help, or to not understand part of a question. We expect this. The goal is to find the other things that the candidate knows really well.
  2. Candidates are sometimes unaccustomed to solving small problems in a relatively short time. They are accustomed to solving large problems over days and weeks. This is what programmers actually do. Unfortunately, no one wants to spend days in an interview. The solution is to practice a little. Find a list of programming problems, and work through them. We like
  3.  Project Euler and the Matasano Crypto Challenges. Although we don't do whiteboard coding, many companies do, and we recommend that candidates practice this as well.