Two Types of Interview Questions

There are really only two types of interview questions: those to which the person asking knows the answer (Why are manhole covers round?), and those to which he doesn't (You're building a grocery store, how would you go about determining the number of aisles to make?).

I could talk about how puzzles aren't actually a reliable gauge for programmer success, but then I would invariably digress into how the interview process as a whole is flawed, and then I would have to question the entire institution of work, and it might end up looking something like this. So instead, I'm going to focus on why we ask questions we already know the answers to. In my opinion, this has always seemed a bit inefficient, especially when there are so many unanswered questions. The problem with asking questions that have defined answers is that anyone can Google them. So having someone on your team who knows all the answers doesn't necessarily help you that much. On the other hand, someone with a thoughtful, original approach to some unanswerable question is just the type of person I'd like to call my teammate.

My friend recently interviewed at a reputable startup for a community manager position. Half of her 45 minute interview was occupied by technical brainteaser questions, to which the interviewer knew the answer. In this company's defense, they've never hired before, so we can probably chalk this snafu up to inexperience. But I think it speaks to just how pervasive the brainteaser interview question has become. Even for entirely non-technical roles, candidates are expected to know 'How many basketballs are left?'.

So I'm trying a different approach to hiring. My interviews are designed to judge two things: cultural fit and intellectual curiosity. If the candidate and I get along, great. If the candidate talks excitedly about their past projects, awesome. And if the candidate is visibly hungry to solve the problems we're working on at Scripted, then I offer them a contract-to-hire agreement. Some might scoff at contract work, but a bad match is just as undesirable for the employee as it is for the employer. There is no better way to determine fit than a month long, two-way interview (with lots of pair programming).

The only challenge is finding a project that is sufficiently modular. If the project requires that the contractor study your entire codebase, it's pretty safe to assume that you won't learn much about them in one month. At Scripted, we're currently employing a contractor to build an english proficiency test. He's definitely spent some time getting acquainted with our database, deepening his understanding of the use-case, but what he's building is essentially a standalone product. The way that he's approached the problem is more informative than any interview I've ever conducted.

Obviously there are cases in which a contract-to-hire agreement isn't feasible, but I don't think I'll ever feel truly confident after just an interview.