My Favorite Software Developer Interview Question

Interviewing for software developers is a challenge. The sheer volumes of technologies, programming languages, protocols and methodologies have created a quagmire of TLAs (Three Letter Acronyms, itself recursively defined!) that recruiters and H.R. struggle with every time a software developer position is open.
 
Java, check; C#, check; XML, check; Tomcat, check; the list goes on and on. As a manager of software developers, you are frequently given resumes of people who know how to spell a given technology but really don't have a grasp of its real purpose. And now you have the opportunity/pain of hiring a developer.
 
First decide if you're hiring a "position player" (a specialist at one position) or an "athlete" (a player who has the ability to play multiple roles on the field).
 
If you are hiring a position player, stop reading this article now. In the interview, ask specific questions related to the job.
 
If you are hiring for competence and the ability to pick up and employ new ideas and technologies quickly and are mature enough in your hiring to know that you don't know what skills your department, and by extension company, will need in six months, then please read on.
 
Given that an interview is a limited time frame to make a decision to hire or pass for another candidate, you have to make the most of the time you have to determine if the candidate brings value to your organization. You could use that time to find your next best friend, or you can bring some real value and find a star performer. So what is the question?
 
"Tell me about a project you really enjoyed."
 
Seems simple enough. If the candidate is early in their career, you can modify it a little to include something they built in school. But just make the statement, and let the candidate ramble for a couple of minutes about whatever they enjoyed doing. It's an open-ended question; there is no "right" answer (and "42" isn't the answer, either). Most candidates will focus on a project that they truly enjoyed working on. Let them talk; don't interrupt, don't prompt, don't fill in the blanks for them. Your hard work of the interview has just begun: start to listen.
 
Listen to how they frame their position in the project. Is it all: "We built it this way..." or did they have some ownership of what they were doing? Do the comments come out like: "We were building XYZ and I took on the ABC component using such-and-such an algorithm." If they get up and start drawing on a white board, listen.
 
Any sizable project will require a team of people working together, so you are not exclusively listening for "I" statements, such as "I found a new algorithm that sped up processing 75% and saved the company a bundle of money", but definitely note those responses. What you are looking for is someone who took ownership of a section, saw it through to the end and understands the business impact of his or her work on the software. If the responses are all of the "we did..." flavor, and you can't prompt them into what they actually did themselves, pass and go find another candidate.
 
If you do hear some personal dedication and pride in the response, it's your turn to ask a more detailed question. And this is the hard part, since you probably know nothing about the product they created or the industry they were working in at their last job. Regardless, your goal is to get the candidate talking again.
First, compliment them. Say something like, "Wow, that sound like it was a lot of work and you make a great impact that saved the company some real money." Practice your responses; don't make this sound like plastic buzzword bingo.
 
Then you follow up with, "It's been n-years since you built that, and now...". And now what? What has changed in the technology landscape recently? You need to be up on a wide range of topics to pull this off. But even if you don't have any idea about anything in their industry, you can still pull it off by falling back to some standard topics. Try this: "...and now we have desktops with 8-core CPUs. If you had to go back today and recreate your project, what would you do differently?" Or, "Would solid state drives change how you approached the problem of X?" For a front end person, "That sounds great for a desktop, how would you change your design for a smart phone?"
 
What you don't want to hear is, "Nothing."
 
The best is when the start getting into the idea of doing the project today. Your job now is to shut up and listen. If they have made all the right responses originally, using "I" statements, now - if they really were competent - they can how see the change would affect how they approached the problem. Some candidates change the drawing they produced on the white board. A lot of times they open up with, "Oh yeah, if we'd have had such-and-such, it would have changed...". Great responses. They understood the problem deeply, and most likely, they will again.
 
And that's my favorite interview question. A single line of thought that goes into what the candidate knew best, not what you were looking for specifically. You might learn something that you need to go research. But you will know more about the candidate than by asking, "How long have you used C#?" It's not the only question in an interview, but it's my favorite.