Last time we looked at how to handle failure. But the real key to leading a software team is to avoid the f-word in the first place. One way to avoid failure is to staff your team with the right people. How do you do that? I haven't a clue. But I do know a whole bunch of ways to ensure that you hire the wrong person. Here are five of them…

5) Ask your candidates nano-questions

It seems like technical interviews have become more and more focused on the tiny trivial pursuit details of technology: "So, Mr. Olsen, exactly which version of Java were you using in this project, was that 7.4.2.0.3.1 or 7.4.2.0.3.2?" Who remembers? Who cares?

The kind of knowledge that is wrapped up in knowing the difference between V1.2a and V1.2c has approximately the same shelf life as unrefrigerated shell fish. I'm certainly not telling you to not to ask technical questions. By all means do ask technical questions. But there is a difference between a technical question What is inheritance? What is the downside of using Java? and questions that could appear in Trivial Pursuit/Geek Edition.

Aside from telling you not much at all, the tiny question has two real costs: first it takes up the time that you could be spending getting to know this person, finding out if they are smart enough, if they have the right background, if they will fit into your group. The second cost of this kind of question is that it tends to tick off those smart, well rounded people that you really do want to hire.

4) Ask them stupid questions

Even worse than the nitty-picky questions are the brain teaser questions that have been in vogue lately: "Now imagine that you have a big cube made up of 10 X 10 X 10 little cubes. Can you tell me how many of the little cubes are visible from the outside?" I always want to answer, "Yes, I can. Next question." One of the most absurd interview experiences I ever had was one where my questioner became angry because I happened to know off-hand that a common piece of paper is about 0.004 inches (.1mm) thick, which foiled one of his clever puzzle questions. He announced that I must of just guessed, despite the fact that my resume showed, and I pointed out, that I had worked for Xerox (motto: when we're out of trees, we're out of business) for the better part of a decade.

Some of the dumbest of these "logic" questions, like the cube one, are actually exercises in spacial reasoning. That is really fine by me: I studied mechanical engineering as an undergraduate and so spent years honing my mechanical reasoning skills. But does this really make me "smarter" or a better software engineer?

3) Ask the 'standard' interview questions

We have all gotten them: What do you consider your strongest feature? ("My nose, next question") How do you deal with troublesome co-workers? ("Superglue, next question") And the all time favorite, "Where do you see yourself in five years?" ("In a mirror, just like now, next question"). The reason that these are bad questions is that a) they don't really tell you anything and b) everyone has (or should have, out of self defense) a practiced answer ready.

What kind of questions should you ask? How about the questions you ask when you first meet someone who is obviously in the same business as you: What are you doing now? How do you like it? Are you having any fun doing that? Have you heard about this or that industry development? Interview the person, not the "How To Ace The Interview" class that he took last week.

2) Assign other people to interview your candidate, then ignore them

If you ask other members of your team to interview a prospective employee – and you should – you gotta get them to take it seriously. I think the best way to do this is to give them veto power: if they veto the candidate, he or she does not get hired. If they don't veto, and hiring the person turns into a mistake, they are partially responsible. Not, call you into my office and yell at you responsible, just we all screwed up responsible. Handing out the veto power makes people take the interview process seriously and it does prevent a certain fraction of hiring disasters.

1) Treat the interview process like a game – a mind game

If there is a theme to all of this, it is that you need to buck the trend in the industry to treat interviewing as some kind of creepy mind game: you against the candidate. It is not a game and it is not you vs. the candidate. You are simply trying to figure out if this might work. If you don't treat it like a game, but you feel like the candidate is, pull out the veto power. No trivia, no stupid mind bending questions or canned questions. Sit down and have a chat. Try to get to know the person.

One of the best interviews I ever had was with this guy who was an expert in a technology I know very little about. I got him to talking about his role in keeping a mainframe database system operational. He told me all about nursing this module along despite the fact that this other data segment was corrupt, of being awakened in the middle of the night because something had gone down. He described to me the procedure that they put into effect on 9/11 when one of their NY data centers was wrecked. He talked at length about the maintenance nightmares in some of the badly written code, and with some passion about the people he had worked with. He may have been BS'ing me the whole way, but I don't think so. Near the end of the interview he expressed some surprise that I hadn't asked him any hard questions. That was the only thing he got wrong in the whole interview.

Next time we are going to look at how you get that new team you've just hired – and their project – off the ground.

– Russ