The interview process at Labs is a little different than most. For one thing, everyone in the company is invited and encouraged to participate in every. single. candidate interview in some way, shape, or form. We don’t assign developer candidates to developers, sales candidates to salespeople, etc. For another, we place an inordinate amount of weight and importance on cultural fit, and when we do our technical interviews, we try to make it a place where the candidate can demonstrate what they are capable of doing more than a demonstration of what a candidate already knows. Third, everyone does a technical interview.
This can get tricky.
Needless to say we had a rousing conversation when Laurie Voss’s article was published: This is why you never end up hiring good developers
While I appreciated the sentiment of this article, reading it as a hard and fast set of rules is folly. I’m sure at times everyone has fallen into the trap of ticking off boxes on a “did they do what I asked” checklist without really engaging the candidate or poking to find out what they really know and how they work. The article contains a good set of guidelines if you’ve never performed a technical interview, or you have and you feel lost about what it is you’re supposed to be looking for. With that said, eliminating whole swathes of interview challenges because they are often clumsily or lazily used isn’t smart. I say that with hundreds of hours of technical interviews under my belt in a variety of languages and platforms.
Here’s my soft and loose set of rules.
You should be spending the first few minutes of the technical talking about the candidate’s experience. Actively listen; don’t go about the interview playing the gatekeeper to some preset test. Judge based on what is said (and what isn’t said!) what the candidate’s competency level is. Then 1) confirm that they know what they think they know, and then 2) see how their brain works at solving something new.
The author of the article doesn’t like toy programming assignments like FizzBuzz. I do. Sometimes, FizzBuzz is important. I can think of at least one interview where not being able to come up with a working FizzBuzz solution in ten minutes or so would have saved everyone involved a lot of time. That said, if someone comes in and says they have 15 years of WebSphere and JBoss experience or six years of Rails experience, of course I’m not going to ask them to to do FizzBuzz. Instead, I may ask them to whip up FizzBuzz as a Service (FBaaS) in the platform of their choice, and when given a query string containing an integer, return a webpage containing the FizzBuzz output up to that number, with a form to enter another number to FizzBuzz up to. This should take a seasoned Rails developer 10 minutes and a seasoned JBoss developer 20 (poor Java devs and their java/netty project setups).
Think of it as an icebreaker. This is important because A) it confirms they weren’t overstating what they said they know how to do, and B) gets the interviewer talking and interacting with you before you start asking them about more interesting stuff. Any of the standard beginning developer tasks we routinely pull from our bag of tricks can work. The candidate has a Weather Underground API-based app in the app store, or has been developing a poker simulation, or reimagined the entire Pathfinder character building experience as a functional language experiment? That’s their FizzBuzz.
Is this person a junior developer? Let’s see how they learn something new, because junior devs spend all of their time learning new things. You want to make sure they do it well. Ask them to do FizzBuzz with you in a language that neither of you knows. Here’s a pile of suggestions: Erlang, OCaml, Scala, Rust, Go, Arc, Ada, D, Common Lisp, Perl, Lua, Pascal, Haskell, Clojure, Forth, Smalltalk. Nearly all of these should be available from homebrew in 1 or 2 commands if you don’t have them already. Are they so green that even that’s too scary? Ask them to learn how to unit test in the language they do know, but with a new testing framework neither of you have used. The whole point here is to see how they approach a totally new problem (as working at Detroit Labs is likely to provide a whole host of those) and pay attention to their resourcefulness, curiosity, and ability to handle unknowns and stress. And by picking something you don’t know you level the playing field a bit. Be sure to mention that. “I’ve never done this either and we might not even get it figured out, but what the heck we’ll give it a shot for fun!”
Maybe this person has senior in their previous job title and has the potential to lead others in the team they’ll be joining. This may be a good time to shut the computer and bust out the markers and see how they’d organize and design a social network for cruise ship workers or a skylight that unlocks with an iPhone or a photo sharing app that doesn’t use wifi or an in-dash automotive help system with a camera based UI – something a little weird that you’ve built before. How does their design approach differ from yours? What new technologies or methodologies is this person proposing and how does that differ from the way you approached it? Keep ’em talking about that stuff and find out why they’d do it that way, dig for the gold that is their thought process for solving a problem a certain way. Even if the approach is totally different from how you did it, how well do they think they nailed it? What design patterns do they think might turn up, and what traps do they think others with less experience might fall into on their team? Are those traps the same ones you stumbled into in the last sprint of that project when you were feeling rushed and lazy?
My point of course is to not look for rules. There aren’t rules. Good technical interviewing requires a lot of experience and the ability and work to engage with your candidate. The “Yes” or “No” on whether a candidate gets an offer from Labs isn’t based on whether they finish some dumb programming problem, but whether or not they can demonstrate that they have something new in either experience or creativity or tenacity to bring to their team that will help Labs as a whole. Now that is something useful to test for in a technical interview!