Chase Seibert

Director of Engineering at Dropbox

Interviews for software engineering positions are equal measures normal job interview and extemporaneous logic bomb de-arming with an audience. Most developers know the drill; you stand up in front of one of more senior developers and have to write code on a whiteboard to solve what’s normally a fairly academic toy problem, the likes of which you have not thought about since college, what with being busy writing real code for real problems.

The Whiteboard

Having given countless interviews myself over the last 10 years, I have noticed that a non-negligible percentage of candidates simply lock up when faced with the prospect of whiteboard coding. Many don’t seem prepared for this eventuality at all, which is kind of surprising given that I personally can’t imagine any decent software companies NOT doing this during an interview.

So, you’re going to have to do whiteboard coding. Accept it. The good news is that it’s actually easier that coding on a computer. I have personally tried to out-smart the whiteboard by bringing a laptop to an interview, thinking that doing what I do every day would be more successful than the unnatural exercise of coding without a feedback loop. Big mistake.

As a candidate, the person interviewing you should be your feedback loop. That’s what they are really after anyway; an insight into how you think about coding. Plus, you only have to write code that looks like it will work to the satisfaction of all parties present. If you whip out a computer, the code will HAVE to be write, because you’re going to be running it.

The key to keeping your composure is to practice breaking test problems down into five stages. Restate the problem as they have given it to you. Come up with examples, including edge cases. Work out an algorithm by doing the problem by hand on the whiteboard. Only then do you write some code. Finally, reason out loud about the time your algorithm will take to run. This is known as REACT.

The Other Stuff

Assuming you get past the technical coding portion of the interview, an additional chunk of candidates flub what should be an easy “softer” portion of the interview. The absolute key to this part is preparation. You’re going to be asked questions, mostly of the kind you could guess ahead of time.

  • Tell me about yourself.
  • Where do you want to be in 5 years?
  • What are your greatest strengths and weaknesses?
  • What are 5 annoying things about your favorite language and framework?
  • Why are you looking for a job?
  • How well do you work in a team?
  • Tell me about a mistake you made at work.
  • Have you ever not gotten along with a coworker?
  • What makes you a great employee?

Just don’t shoot yourself in the foot here. This isn’t the time to show your sarcastic, cynical side. You should write out the answers to these questions ahead of time, keeping in mind the answers an employer is going to want to hear.

Then, it’s time for you to ask question. In fact, don’t even wait for the official offer to ask your own questions, just launch right in whenever you have one that’s appropriate, or if there is any dead air time. Your primary goal as an interviewer should be to make the other person talk, ideally even more than you are. People remember conversations more favorably when they did more of the speaking. Plus, it leaves less time for them to grill you.

Again, preparation is key here. You may be meeting up to 10 people at the company. Write out at least 50 questions, ideally more. Think about all the processes, policies and technical decisions you’ve seen in past jobs, and ask them about how they do those things.

  • What technical debt are you going to be working on over the next year?
  • How many hours did you work yesterday?
  • Have you contributed to any open-source projects as a team?
  • How often do you hang-out outside of work?
  • Does your 401k provider suck as much as the rest of them?
  • You glorious bastard, I read your book! Why did you say this on page 47?

Caveats

Although live-coding on a laptop is risky, I still recommend bringing one. Occasionally someone will ask you to solve a problem you have actually already solved in real life. In that case, wiping out the code and taking a look at it together could both save you a whiteboard session, and lead to a deeper conversation.