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
- Anonymous
March 11, 2006
The comment has been removed - Anonymous
March 11, 2006
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. - Anonymous
March 11, 2006
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. - Anonymous
March 11, 2006
The comment has been removed - Anonymous
March 11, 2006
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! - Anonymous
March 12, 2006
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 :) - Anonymous
March 12, 2006
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. - Anonymous
March 12, 2006
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... - Anonymous
March 12, 2006
... is to program with them on real code.
If you can't do that yourself, get your good developers to do it. - Anonymous
March 14, 2006
The comment has been removed - Anonymous
March 15, 2006
Heck, I'm not even sure if I'd hire me to do my job. :-) - Anonymous
March 16, 2006
The comment has been removed - Anonymous
March 17, 2006
The comment has been removed - Anonymous
March 21, 2006
Interesting article I read in the past about interviewing developers : http://www.joelonsoftware.com/articles/fog0000000073.html