Death to the Technical Interview

Coding is hard. Most would agree and - if not - then either you know something I don't (likely) or you don't know what you're doing (also, likely). With that said, coding while a potential future employer is scowling over your shoulder and murmuring inaudibly makes the process incalcuably harder. So, allow me to tell you why we all should join the chorus calling for the death of the modern technical interrogation.

1. It's not a good indicator of technical ability.

Ok, if the position happens to be one for which disarming a nuclear bomb is a possibility, disregard this argument. Otherwise, in what possible high-pressure situation will you ever be expected to solve an obscure data structures problem on a whiteboard. With no syntax checking or debugger. In front of three scrutinizing neck-beards. Answer: Never.

Now the logical followup question to this bold claim is: If the technical interview is a poor indicator of technical prowess, what's a good one? How do we separate the Michael Jordan's of programming from the...bad basketball player equivalent? To this, I say there are two alternate ways to accurately and easily gauge a programmers ability.

• Github profile: How many repo's do they have? How active are they? Do they contribute to open source projects? And then, of course, the obvious code quality questions.
• Programming project. Having an applicant complete a small task in their own time and in their own lair yield's both a better reading of ability and results in a much less stressful experience. This definitely does NOT mean a project on collabedit or an equivalent collaborative editor where someone is just virtually giving code the stink eye rather than in person.

me walking out of every technical interview ever

2. It's unpleasant for all involved.

Somewhat recently while working at TheShelf (awesome company that all fashion bloggers should want to be a part of), I had the opportunity to conduct my first technical interview. It started out innocuously enough with the usual pleasantries, but shit hit the fan real quick and real hard. The position was one which would require a fairly comprehensive knowledge of Javascript so I started the interview with - what I thought - was a fairly simple indicator of experience with closures (a programming paradigm). A few minutes in and after some bumbling about with the marker, still nothing was written on the white board. Five minutes later and I had written the first quarter of the answer on the board. Another ten minutes passed and now the atmosphere in the room was distinctly tense. Finally, after 15 minutes I had given her the entire answer and we cut off the interview there. I know it must have been terrible for her, but man it was pretty traumatic for me too. Bad technical interviews rank pretty damn high on the awkard scale.

my face watching the train wreck unfold

3. Questions are hard to craft? Questions are hard to craft.

It's far too easy to underthink technical interview questions. They must - in fact - be tailored to the individual being interviewed. That is to say it's irresponsible to ask a 10+ years of experience professional what the difference between a method and a function is while the same question is perfectly appropriate for a recent grad. This makes the process of creating a suite of interview questions exhausting, error prone, and just a huge time-suck.

Now us Python developers, Ruby developers, Java developers, PHP developers, and (God help you) Perl developers, let us put aside our meaningless and largely annoying quibbles to unite under a single banner. For once, let's say who cares whether Django or Rails is the superior framework and just join our voices to call for an end to the modern technical interview.

to the technical interview, so say we all