Hiring, Auditions, and Interviewing For Success

Today Sam Altman, one of the Y Combinator partners, posted an article called How to Hire. There’s much to agree with in here, and a few points that I think are wrongheaded (mostly around the overused-and-underdefined phrase “culture fit”, and some assertions which are really just ageism), but the point that generated the most discussion on Hacker News was the idea of an audition.

Have people audition for roles instead of interviewing for them.

This is the most important tactical piece of advice I have. It is difficult to know what it’s like working with someone after a few interviews; it is quite easy to know what it’s like after working with them

Whenever possible (and it’s almost always possible), have someone do a day or two of work with you before you hire her; you can do this at night or on the weekends. If you’re interviewing a developer, have her write code for a real but non-critical project. For a PR person, have her write a press release and identify reporters to pitch it to. Just have the person sign a contractor agreement and pay them for this work like a normal contractor.

I’ve seen this discussion happen a dozen times, and the sides break down the same way:

–Pros: Whiteboarding is artificial, and real coding is a better reflection of skills; hiring is a two-way street; wouldn’t you want to really get to know your colleagues?; I wish someone would test me that way.

–Cons: it’s simply not true that people have “a day or two” to give you outside of the interview process – some combination of work, family, and personal obligations. “The developers who know what they’re worth won’t put up with this.”

The best answer, of course, comes from remembering the goal of interviewing in the first place: to find people you should hire, and then hire them. Obvious stuff, but there’s a less-obvious corollary: if there’s part of your process that keeps you from finding people you should hire, you should change that process. No matter how awesome your company is, asking for homework as part of the interview process will keep some people you would want to hire from interviewing.

If you think that a working session will give you different data than a whiteboarding session, then integrate it into your interview day: instead of five hours of whiteboarding, do two hours of whiteboarding, two hours of real-world programming, and an hour to establish values alignment.

Real-world programming could be pair programming, or could be what one of our clients does, where they ask the candidate to bring a laptop with their development environment, and a VGA connector (or they’ll provide one), gives the candidate a problem and a projector, and watch while asking questions.

With a setup like this, you give the candidate multiple ways to show success (i.e. he freezes at the whiteboard but can write great code the first time through; she takes a while to get into a problem but clearly understands data structures), and you gather a wide variety of information.

(BTW, many companies actually don’t have a contractor agreement – and even more individuals wouldn’t know what to do if they were paid as contractors. Don’t hand-wave this away.)

(Pedantic note: the use of the word “audition” in the original context doesn’t make sense. An “audition” is an interview, but with singing and dancing, or crying on command. If you audition for a play, they don’t have you come spend a few days as Peter Pan before someone decides if you get to stay.)