the way we interview is all wrong

(disclaimer: this is directed at companies who hire IT folks, programmers and QA folks specifically. I don't know how this will map across domains, but it might. Thanks for reading anyway. Also, I tend to use masculine pronouns for brevity. typing his/her s/he all the time gets in the way of writing and reading)

I'm going to cover this from both sides (company and candidate), so don't fret. I'll get to you in a sec.

Dear interviewer: ask open-ended questions and make them write code. writing code in the real world isn't a pop-quiz, don't make the interview a pop-quiz. Dear programmer: have code you can show.

Before I go too far, let me quantify my soapbox a bit: Some programming and OO fundamentals are required to make it in software. --The same way some knowledge of Italian is required to get around in Italy. We all need some foundation to be walking-man conversant. I'm not debating that. What I am concerned with, however, is the indoctrination that when we interview candidates, we have to quiz them on these foundations. Skip it.

if the candidate is knowledgeable, the vocabulary you're looking for will be there naturally

The worst interview formats I've been a part of --as candidate or interviewer-- are the canned list of questions and syntax memorization quizzes. Knowing what an Observer pattern is one thing, knowing when to apply and experience implementing it is much more valuable. Here's a non-programming example: I could spend a couple nights Googling about appendectomies, but do you want me taking yours out? (no, you don't --I got into software for a reason). Don't interview for memorization. Interview for experience and application. How do you do that? Ask open-ended questions. (Insert plug for STAR interviewing) I don't mind leading with, "Can you describe what an Observer pattern is?" --but that's a closed question; "yes" or "no" ends the inquiry. Definitely follow up with, "okay, tell me of a situation where you recognized the need, how it was applied, and what were the outcomes?" This gets us to a real conversation and we can uncover what the candidate knows and --maybe more importantly-- how they communicate. One of my favorite questions, after the candidate has spent some time detailing a project or implementation, is to ask what they would go back and refactor.

"If you could go back and fix/redo/refactor one piece of that project, what would it be and why?"

It forces retrospection and analysis on-the-spot. This question plunges deep into the candidate's ego. Quickly filter out anyone who says nothing needs to be refactored. The good ones have already thought about it. Candidates who point to political or cultural changes can be yellow flags; this is a technical interview, and I'm looking for the candidate to focus on himself. I appreciate (more than some, I imagine) cultural and political impediments to writing the Best Code Ever. Unfortunately, there aren't nearly enough Fog Creeks and 37Signals. More common is the Big Public Company with a few hundred programmers, cube farms, and battles for local admin rights. The 'more realistic' world is impediments and politics. We need to focus on whether this candidate recognizes that no code is perfect, and refactoring is an intrinsic operation. When a candidate calls out "people" as the thing they'd refactor, I guide him back to his code.

Interviewing is an exercise in mapping: mapping what you hear to the types of developers you've experienced and their relative productivity and technical skill. Unfortunately, as an interviewer you are forced into broad generalizations based on little data. Even multiple interviews over a couple weeks is a short amount of time to really get to know your potential teammate. Probing questions that reveal hubris, desire for learning, and effective problem solving is the way to go. I've had poor results with developers believing their code doesn't need refactoring. Software development is complicated, non-linear, and multiple-choice. That new business logic slammed in the day before the deadline? Yeah, that's probably not perfect. Listen for the candidate that knows what he did poorly, what could have been done better, and knows what to do now to correct it.

Listen to how the candidate walks you through her example. Is she able to concretely describe the objects, interfaces, implementations? If you ask for explicit details, are they easily described? Do you have to ask the same question in various ways? Get the candidate to speak in specifics: classes, interfaces, abstraction layers. You want to hear the vocabulary.

Okay, here's the deal: you, Company, want to hire programmers. Great. Here's my advice: Ask for code. Ask the candidates to write code (whether FizzBuzz or something more complex). Ask the candidate to walk you through their toughest technical problem and how they solved it. Do not accept 'people' as their toughest hurdle. We all make mistakes; we all learn through experience. Your better programmers know and leverage this. You may be surprised how many programmers get FizzBuzz wrong. Would you hire a graphic designer, writer, or home builder without seeing samples of their work?

And you, Programmer. Go implement FizzBuzz. Put the code on GitHub. Now go write a small to-do app. Write unit tests for that code. Put the code on GitHub. Build your portfolio. As a hiring manager (and one who writes code), I care less about syntactical gymnastics and more about solving problems. Show me you've solved problems --with code. Show me you know what Separation of Concerns means --with code and conversation, not the academic definition. Show you me you like writing code, which is why you have a github account and you've been working on a nodejs implementation of FizzBuzz that emails the results.

It all depends on what you want to do with your life. I know that sounds horrible, but it's true. Software development is commoditized. I hope that isn't alarming; the industry has been this way for years. How do you, as a programmer, differentiate yourself? You write code. On your own time. This demonstrates that you see problems, and you can solve them. It shows you like to code.

Have some code somewhere you can show it. It shows you actually like being in this business.