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.

Don't Leak the Questions!

When you publicly post a question that you were asked after interviewing, you are undoing weeks of work for your fellow engineers. In it's place, you a creating weeks of new work as we develop, test, and calibrate on new questions.

During that calibration, we might ask your fellow engineers sub-optimal questions. They will have a bad time in their interviews, and will post rants about the sorry state of interviewing in engineering. Also, because we're not calibrated, they might get undeserving feedback which causes them to miss out on their dream job.

Leaking interview questions is antithetical to what we're trying to do as engineers. Our goal should be to spare our peers work -- that's what writing clean code and creating nice architecture is all about. Once software engineering becomes a real profession, there will be no need to ask our peers silly little puzzles to evaluate them. But until then, lets be professional and JUST SAY NO.