How (Not) to Interview a Developer


My team has an open headcount for a developer and, if things go as planned, my team will have more open headcount for developers, so I’ve been talking with lots of developers. Coming from a marketing team and previous to that being a writer/editor for a variety of trade publications, I have a unique skillset for interviewing developers. That is to say, I have no skills for this at all. None, nada, zip, zero, zilch. Bupkus.


Yet, for the past two weeks, I’ve been talking to a host of people who’ve architected and built everything from sophisticated ASP.NET applications to complex VSIP plugins. Since most of the conversations are informational, I spend the time explaining about my project, about Microsoft, and about Seattle. I listen to the folks talk about what they’ve done, what they’re most proud of, what the like the most about Visual Studio, what they hate the most about Visual Studio. 


As a marketing director, I could usually tell within 5-15 minutes whether a person would make a good Microsoft product manager, be a fit for the team, and be qualified for the specific role. Rarely did I need the full hour to get a sense. But here, on this new turf, I am at a loss.


So how do you tell in a one-hour interview whether a developer is going to have the skills to succeed?


Comments (14)

  1. kfarmer says:

    Part of being a good developer lies in the ability to communicate your thoughts to others.  Not many of us are necessarily *great* at it, but we try, and we get better as thoughts are solidified.

    Perhaps you should take advantage of your lack-of-programming background, and have them explain how and why they designed their code the way they did.  What were the tradeoffs?  Of the interviewees, who was more at-ease and effective in communicating?

    My friends are probably annoyed at me for not taking "I’ll never understand so don’t bother explaining" as an answer from them.  I think that’s a bunch of BS — they’re smart people.  They just need to be told in terms they’re familiar with.

  2. Yaron says:

    As a non-developer you can pretty much forget about being able to tell if someone will be a good code jockey. You need one to know one. What you can tell is if this person is going to be a good member of the team. Do they think PMs are just there to get coffee and take notes? Are they capable of discussing different product goals and providing insight on the coding challenges the goals will present? In other words, is this someone you can collaberate with? If the answer is no, don’t hire them. If the answer is yes, then go find a few devs to make sure they can actually write good code.

  3. Jon Price says:

    I’ve interviewed hundreds of developers over the 15+ years of my career. I never rely on or care what arcane facts they know (or what they say they know by what is on the resume).

    Technology and arcane facts can be taught faster/easier than best practices of the development cycle.

    Developers that have no use for documentation or can’t even explain themselves in written form, are useless in a team setting regardless of what they know or what they can code.

  4. Dasher says:

    kfarmer is right.

    The only other aspect I would suggest is to give them a problem and ask them to discuss how they would solve it.  To explain their thinking, as kfarmer suggests is good.  But not all problems are solved by applying technical knowledge – so see if they can think outside of the box.  Creative problem solving is important.  Another important attribute is somebody who doesn’t feel the need to rewrite everything from scratch, somebody who can work with existing code.  These people are worth their weight in gold – it means they don’t think that their solution is the only way to solve the problem.

    The best manager I’ve ever had wasn’t a coder but a people person.  The worst was a wanna be coder (who used to stand over your shoulder and comment on what you were working on) – so don’t fret and trust your instincts.

  5. Usually a dev interview loop will have a mix of people. Programming is only half the story, and so only needs to be half the loop.

    Things I look for in developers, and heck, in prospective Microsoft employees in general, are some of the following:

    How passionate is the person about technology? Is it just a job, or are they here to make a difference?

    The same, applied to the discipline they’re going to be working in. One thing I am cautious about is people who have unrealistic expectations for what they’ll be doing. I get this a lot from folks interviewing for MSR, for example.

    How are they at problem solving? You don’t have to be a programmer to figure out if a problem solution is good. Heck, it doesn’t even need to be a programming problem. Are they methodical? Creative? Flexible? You can start by describing a problem your team has recently attacked, and see how this person approaches fixing it. You can be guided by your own experience and discussions with that problem.

    How are their communication skills? While not AS necessary for a developer, it’s still nice if they can string words together and make a sentence. Ideally they should be able to explain complex technologies to technical but non-programming people.

    How well do they know the boundaries of their knowledge? We’re always learning as part of our jobs, but you’re not going to be very effective at doing so if you don’t realize you have things to learn.

    Good luck!

  6. Dasher says:

    If you’re still looking for a Program Manager for Tuscany (who is lives in Rome, just down the road from Tuscany).  Let me know – I’d be happy to relocate :)

  7. johnmont says:

    Sticking to what I know, watching for the ability to explain things, and working with others are the key things I’ve been looking at. I just hate the feeling that I can’t personally attest to the day-to-day abilities of each and every person on my team.

  8. Name says:

    Developers need to get the job done. I hate to say it but it is IMPOSSIBLE for a business person that has not worked as a developer on a major project to interview other developers. If you have the technical experience and done similar work yourself the process becomes quite obvious, you can tell after 5 minutes if the guy knows what he is talking about or not. Beyond that (this comes 2nd, not first) it is about communication skills and trade-offs, some of the best all-around developers hate working in teams with others (can you live with that, larger companies usually can’t, so you either hire mediocre people, or people that will at some point hate working for you). Most importantly you need to figure out if the guy knows how to get stuff done. As with everything it all depends on what you’re looking for – there is no 100% all around developer that can just do everything, there are a few, but why would they want to work for you…

  9. Nat says:

    … is to program with them on real code.

    If you can’t do that yourself, get your good developers to do it.

  10. Xepol says:

    Beware of any developer that looks comfortable in a suit.

    And ya, if the guy is blowing smoke, you can usually tell.. I was forced to interview someone one who’s sum total experience was writing scripts for an IRC bot… It took a while to drag it out of him that that was the total sum of his extensive internet development skills, or his development skills for that matter.  It took me even longer to believe that someone would send him to me to interview for a software development job (nope, no cameras, no guy named Skip with a big smile… wtf?)

    The interviewee (a <18 teen), his parents, and their neighbour, my boss, seemed annoyed when I told him that he needed to get real training because I didn’t consider being a script-kiddie the same thing as "a promising computer prodigy".  

    Took a while but the boss finally got it… "Look, he takes OTHER people’s scripts and modifies them to run on a program that does all the internet stuff for him" "ya, but his mom says he’s really smart" "Look, you can tweak a batch file right?" "Ya, so what?"  "Would you want me to hire you to do my job? It’s the same thing." "Oh, never mind."

  11. johnmont says:

    Heck, I’m not even sure if I’d hire *me* to do my job. :-)

  12. mheller says:

    Like anything else, learning to get a quick sense of developers during an interview takes practice. You got good at interviewing product managers by interviewing product managers; you started by knowing what product managers need to do.

    In one of my favorite interview stories, I was the interviewee. (I took a different job, as a cyclotron physicist, that came out of the same round of interviews.) See http://www.mheller.com/Adventure.html. The interview is after the second dingbat, although it makes more sense if you read the whole thing.

  13. johnmont says:

    I found this link in the Register http://www.regdeveloper.co.uk/2006/03/17/cplusplus_interviewing/ that touched on some of the same topics.

  14. Interesting article I read in the past about interviewing developers : http://www.joelonsoftware.com/articles/fog0000000073.html