We’ve been doing a fair amount of interviewing at my current employer, primarily looking for software developers to work on the same team where I break test software.
I find the interview process fascinating. I maintain that the most important skill for a member of a software development team is the ability to communicate effectively (both orally and in writing) and our interview process exercises those abilities.
I Care About the Why Over the What
Several of our interview questions are fairly open ended. There’s not a right answer (although occasionally there is a clearly wrong one). We aren’t as concerned with which of the nearly-unlimited potentially-right answers you give us, but more concerned with how you explain said answer. In fact, I’d rather hear a questionable answer with a solid explanation than a textbook-perfect answer but no ability to explain how one reached that conclusion.
That Explanation Translates to Software Design
We don’t want folks who can explain things just for the sake of explaining things… as we design software, those explanations are key. It seems that weekly (if not even more often) I’m engaged in a discussion with a developer and we talk through how a software component will behave. Perhaps they came up with the design on their own or perhaps it came about as a result of discussions with others.
Out of each one of these discussions, things evolve. Perhaps I offer an insight that changes the course of their design. Maybe they explain the rationale and my vision becomes clearer. Sometimes I play the role of the duck and they have an epiphany on their own.
Rarely does excellent software come from one developer working entirely on his or her own. Good software generally comes from a team… a team that can communicate and explain ideas.
photo by Flickr user poportis, used under Creative Commons licensing