Imagine the following interview with two interviewees, “Player A” and “Player B”:

Interviewer: “Okay, sir. Let’s say a ball is hit a little bit to your left. How do you field it?”

Player A: “Well, I’d take a few steps to the left and try to get my body in front of the ball. I’d use my left-hand to field the ball, switch the ball over to my right hand, and throw it to first.”

Player B: “I’d take a few steps to the left, keeping my body bent at the knees and the back so I could respond to any strange hops the ball might take. If I can get completely in front of the ball, comfortably, I will, but I might have to field it with one hand to the left of my body, if I can’t get my body in front of it. Depending on the direction I’m moving, the time it took me to get to the ball, and whether I got completely in front of it or not, I might have to throw it on the run.”

Based upon the two player’s answers to this question, Player B gets hired.

This might seem like the right call. The problem is that Player B is a recent college grad that majored in English and played intramural ball. Player A is Derek Jeter (Yankees shortstop) before he was really known as the Derek Jeter.

What if you were the interviewer and you had made this decision? You would’ve just altered the entire course of your team. There’s a good chance that from this decision forward you’d be losing a lot of games to the team that hired the person you let pass by.

The above scenario is analogous to the sad state of interviewing in the software industry. Interviewers ask inane questions that don’t have anything to do with whether the interviewee is a good software engineer. I’m not against a company asking basic questions in an attempt to weed out people that don’t have any idea at all about building software, but I am against getting through that process and then being asked similar questions in the next stage of the interview process. That’s almost always the way it goes, right?

One problem that arises when trying to solve this dilemma is that the software world is littered with posers[1] that don’t have any idea how to build software, and then these people are asked to interview people. It’s not even their fault in some cosmic sort of way: they are asked by management to interview the prospective employees. Uninformed managers asking unskillful developers to do such important activities is not a good way for an organization to operate. Since ignorance is bliss, though, these people have no idea what’s going on. Is it really their fault?

If you’re serious about hiring a good software engineer there is only one, effective way to hire serious candidates:

1. Conduct a screen interview that weeds out any people that truly don’t belong. In this interview ask relatively basic questions about constructing software. By “relatively basic” I don’t mean totally simple questions; I mean questions that aren’t based on some obscure piece of information you read in the latest technology magazine you subscribe to. Ask questions such as “What is an interface?” or “What problems do you associate with using the ‘static’ keyword?” or “What can you tell me about responsibilities within a software system.” Don’t ask questions such as “How does the compiler optimize a for loop?” Such questions have no relevance toward the creation of software unless you are building software that optimizes for loops. Questions such as this are only asked when the interviewer wants to consciously or unconsciously appear “smart.”[2] There is no time for such silliness if you’re a serious person—and there is certainly no value in such questions for the organization you represent. If your company builds software there are not many more important decisions than hiring good software engineers, so get serious about it or get flattened by the competition. Someone out there is doing things right and they will annihilate you if you don’t clean up your mess.
2. This is the most important step: sit down with the person you are hiring and develop something together. It doesn’t matter what it is. The goal is to get a feel for what the person is capable of when actually developing software and to see if the candidate can fit somewhere in your team. Before a sports team signs a player to a contract the team watches him play. The team doesn’t talk to the player about playing.[3] It shouldn’t be much different in the software world. Sit down and develop something together. The candidate doesn’t have to do things exactly like you or your organization. For example, if you’re a TDD shop like we are you don’t have to make sure the interviewee fully understands TDD; all you have to do is to see if writing software with her feels right. There isn’t even a perfect definition of “feels right.” It’s all up to you. In the case of TDD you’ll more than likely force the coding to follow TDD principles whether the candidate has ever done TDD or not. Going through this process will uncover a lot about the potential hire: What kinds of questions does she ask? What are her thoughts regarding TDD? Does she really seem willing and able? More answers than you have questions for will come to the forefront. Having answers surface to unasked questions is always a good thing in an interview, and the nuances of a person’s personality will flow through when you work together. You’ll be amazed at what you learn if you learn to pay attention.

If you’re not serious about hiring a good software engineer then you’re a poser. May as well make it easy and flip a coin.

Post Mortem:

In the end, it really doesn’t matter what you do. The outcome of whatever interview process you choose will be directly proportional to how much the interviewee’s abilities reflect your own. If you only ask the candidate questions, the questions you ask will be based upon your skill and experience in the software world--and the answers you seek will reflect your own answers.[4] If you’re not very good you’ll more than likely hire someone that isn’t very good, regardless of what you ask or do. If you do sit down and develop a piece of software with the candidate, you will develop it according to your ability and look for traits in the candidate that match your own traits. But, at least in the case of writing code together, you will get a much, much more accurate assessment of the interviewee than you will get by asking questions. An overriding reason for this is because coding together is a dynamic, exponentially greater reciprocal relationship than asking questions is. Asking questions generally flows in one direction—from the asker to the answerer—instead of equally in both directions.

In the case of an interview, bidirectional transport wins.

---

[1]  A poser is a faker, but worse. A poser is a faker, only a poser doesn’t understand they are faking. Such people are incredibly annoying and boring. In this way one could say that Poser derives from Faker. I’d probably prefer to have Poser implement IFaker, but that is an argument for another day.

[2]  Knowing an answer to this kind of question has nothing to do with being smart. There is a lot more to being smart than keeping extraneous information in one’s head. Intelligence has much more to do with how one associates information with other information, not how one collects it.

[3]  A team may talk to a potential player about playing, to get a feel about their attitude and personality, but this is a fraction as important as how the player plays the game. Occasionally a team will let a good player pass by, but only if the player has enough personality baggage that it would get in the way of their playing upside.

[4]  It is possible that you are very intelligent and very wise, but inexperienced. If so, you will ask questions and look for answers you currently believe are correct, but you might interview a candidate that is just as intelligent as you but much more experienced. In this case--if you are very wise--you would be prepared for and open to the possibility the candidate is actually better at developing software than you. You would hire him or her on the spot. Many people do not set aside their ego well enough to reach this level of maturity.