Sunrise

Prayag Verma | Saturday, November 09, 2013 | 2 comments

As an engineer at Airbnb, I do a LOT of interviewing. I talk to at least two to three people a week, but sometimes it's as many as 5 or 6. All of my interview questions involve asking people a technical question that we can work through to generate real, working code.

Usually, I'll whiteboard the question and we'll spend a moment talking about possible approaches. But the goal is to get the candidate to start writing code quickly so we can get to a solution.

We've all been faced with the terrible, knowledge-based, "I could look that up in 1 minute but I don't have a computer" question. Worse are the gotcha questions that you wouldn't be able to solve unless you happen upon a moment of brilliant insight. The questions I ask aim to avoid that.

Good questions are fun and engaging for candidates. Good questions also always have a path forward. If the candidate is stuck, I should be able to give a hint that allows them to get unstuck but that doesn't give everything away.

I like to arrive at some running code that solves at least a subset of the problem at the end of every interview. If my question just wasn't going well with a candidate, getting something running keeps them from spiraling down a mental failure vortex, and allows them to relax and focus on the next interview.

Preparing to Ask a Question
A lot of work happens before you ever see a particular interview question. First, I myself have probably solved it in one or two possible ways. The first time I solve it, I try to give myself the same constraints a candidate would have -- limited time, no previous knowledge, no specific preparation.

Next, if I'm the one who came up with the question, I will ask it to a few of my coworkers to get a basic calibration. If someone else came up with the question, then I have probably sat in on (shadowed) a few interviews where the question was asked.

By the time I ask you, I am familiar enough to quickly know the various dead ends and blind alleys that you can fall into. I know of a few ways to steer you towards something that would work. Finally, I know how people of various experience and skill levels usually perform. I know enough to be amazed at your quick and clean approach. Alternatively, I've seen how good whiteboarding goes bad and results in spaghetti code that's impossible to debug.