Technical Interview 2.0
I read a great article by Kathy Sierra of “Creating Passionate Users” fame this morning. She brought up the point of how glib talking people usually get their way more often then their less-articulate counterparts. While it is not always true that the fast-talkers are wrong, the problem comes in when the deep-thinkers are overlooked when they might be right.
Kathy’s article was in the context of making business decisions, having meetings about development issues and deciding on a course of action. But the discussion made me think about another conversation I had recently with a developer friend about interviews for development jobs.
It seems as if technical interviews are definitely stacked in favor of the glib. Considering the fact that many of the best developers (at least in my experience) are often the introverts and don’t like to rush into things headfirst, they are at a disservice with the typical method of interviewing.
It usually goes like this:
- You get the “Tech Screen”: a 30-45 minute phone barrage of very specific (to the point of “Trivial Pursuit”) questions on code syntax, platform terminology and even IDE menu options. Under pressure, its often difficult to recall that kind of information, and questionable whether much of it is worth knowing off the top of your head. That’s what Google, intellisense and your ability to point and click are for. Frankly, I’d be suspicious of people who do know the name of the 3rd item under the Tools->Debug menu as either being obsessive compulsive or “cheating”. And just because you do know all of the trivia doesn’t mean you have problem solving skills.
- If you can get past that stage you’re typically brought in to interview in a conference room with one or more people warily (or wearily, depending on how many interviews they’ve already done that day) staring at you from across the table who briefly explain some super difficult business problem that has plagued them for several years and expect you to come up with a watertight solution with about 10 seconds of forethought. Either that or you get the “Mensa from hell” type of “logic” problems involving gas stations and blenders that you may or may not have the worldly experience to figure out in the limited amount of time you have to spit out your answer. Cross your fingers, turn on the glib and buzzwords and hope your stream of consciousness answer is somewhat acceptable.
It’s amazing that any introvert developers get hired!
A developer’s job is about solving problems, but not instantly. Its about learning new technologies and methodologies to solve those problems if you don’t already have the appropriate knowledge. Its about becoming aware of your environment and working within those constraints. And its about efficiency: using whatever tools you can find to save you time, reusing things you and other people have developed to keep you from reinventing the wheel and leveraging whatever knowledge resources (search, books, friends) you have available to you to get the job done. But all of that takes time, and those skills are not accurately measured in the typical kinds of interviews that I and other developers I know have been exposed to (or given!).
Wouldn’t it make more sense if you were given a set of reasonable project requirements with the tools and environment you’d be using at your potential employer (see virtualization) and access to whatever personal tools you’d use if you were working there (ie, internet access, IM, phone, your library of code snippets, your favorite books), and allowed to take 8-24 hours to complete the project to the best of your ability. Then your potential employer could review your work and call you in for a code review so you could justify your choices. Someone who got through that process in good standing would stand a lot better chance of being successful in your company in the long run. It would give people a chance to be judged on what they DO and not what they SAY. And it would get rid of the fast-talking BSers.
“But what if you had your buddy code the whole thing for you?”, the interviewers might say. It doesn’t really matter if the code review process is implemented well. Since one more aspect of development is to be able to understand code that other people write, its still an appropriate test of someone’s ability. Who cares if you really wrote it if you can step through each part and thoroughly explain it to the interviewer’s satisfaction. If there’s still a question of aptitude, the interviewee could expand some functionality during the course of the interview. I have a whole network of developer friends with different areas of expertise that I call on when I need help with some concept I haven’t had to deal with before. And they call on me when I have knowledge that they need as well. We share code snippets all the time. It’s another tool. It’s another method. It’s just part of being a good developer. But in the end it’s all about whether the interviewee really understand the code that they’re presenting. If they didn’t write it this time but they understand and can explain it, they’ll be able to write it next time.
I would rather have someone come onboard at my company who had already demonstrated their capability with problems similar to what they will be expected to work with in my environment than take the chance that the silver-tounged person who knew all the answers can’t produce. That’s the risk you take with the standard tech interview process that’s all based on talk. Time for a newer approach!
