Okay, first of all, **BAD** link to put in your post if you happen to want quick feedback :-) I spent two fricken hours wandering Paul's site before deciding I should either get back to work, or at least respond to your query. I had not seen his site before (shame on me)...

Anyway, you clearly can not show this article to your management. That would be like slapping them in the face and then referring to each of them as "Mr. Poopy-Pants." This would be more an "internal document" to your group to help plan your approach, but do NOT show it to anyone else.

I won't relate stories of my past management or theories on good vs bad or developer vs management background since that seems to be well covered above. What I will say is the truth of the matter is it is not skill, training or experience that matter most. Those all help, but what matters most is desire.

That and a little PR with a dash of semantics...

What I mean by this is don't get caught up in a single detail (we want a developer to manage us). Just like in software, make sure you are solving the right problem. In this case, you don't really want a "developer" to manage you; you want someone who understands and **likes** developers to manage you.

So I would make the following recommendations:

1. Change the job title from VP of Development to CTO (assuming you do not already have one of those). This might "scare" away some of the PHB's and limit the playing field.

2. Keep in mind this person does have to manage, not do. Like all the others on this list said, someone not willing to be socially acceptable, politically correct, and at least a little bit subtle won't help you out. Cut them from the process immediatly.

3. Insist on the bulk of the interviews and strongest weight in the decision process come from your group. Most places consider this (at least interviews by the team) to be pretty standard so a little subtlety should get you this.

4. Ask a variety of questions but the biggest one to sneak up on is "Why do you want to manage technical people." Best answer I ever go to this was "because programmers fascinate me and I want to figure out how to manage them..."

5. Ask general, but not specific technology questions. By that, I do not mean ask "which is better, Java or DOS batch files?" I mean, ask things like "when is the best time to switch underlying technologies?" "what's the balance between **great code** and code that just runs?" "what's more important, meeting the customer requirements or meeting the customer needs? What's the distinction and how do you manage the difference?" No one will ever agree on the answer to these questions in a general sense, so you and your group need to decide for yourselves the quality of the responses.

6. Ask about their hobbies and what they do for fun. Remember, you have to work with this person. That includes hanging with them at the company party, making small talk before a meeting starts, saying something cheery when you cross in the hall. Plus, this will give you better information on thier "soft skills" as well as give you an indication of what it will be like to work with this person.

7. Avoid questions that put them in an adversarial role right off the bat. eg. "What would you do if the other suits wanted us to do something and we said that was a bad idea? Determine for yourself from other conversation (like the one above) whether you think you can trust them. If you feel you can trust them then you have your answer without having to be abrupt about it.

Regardless of the skills involved, if you can't stand to be around the person, you're not going to work well with them.

I'll probably take a shot or two for this one, but I've become convinced asking technical questions on an interview is virtually worthless. Trying to do so leads you into one of the following time-wasting traps:

• contrived, idiotic scenarios involving primitive natives and a log bridge
• what I call, "stupid party tricks" questions. ie. how would you do this in SQL? I've found people don't like when I answer "I wouldn't, I'd use PERL..." but that's off topic...
• Our company has been struggling on this problem for six months, can you solve it for free in the next five minutes?

In your case, you would have the added problem (as others have pointed out) of excluding very good possible candidates by hitting them with a technical interview.

I think people are more and more beginning to believe the best programmers cannot be measured by what they know, but rather by what they can figure out. This can only be determined by actual work experience with the person (which you cannot get or simulate) or by peripheral converstaion and "gut" feeling.

Anyone who manages such a group needs to be able to manage this and undestand intrinsically that no one in thier group can be pigeon holed and that managing them is a full time job. More like fostering, mentoring or parenting than traditional management. But you can't test for that either so your best indication is going to come from "chatting" rather than skills testing.

So, my new theory (always got to have a theory) is to not interview for a position, but to interview for a friend. You have one caveate to that. If the person is going to work for you, they need to be a person you think you can mentor. If they are going to work with you, they should be someone you'd be willing to waste a few minutes with in the break room. If they are going to manage you, they need to be someone who's leadership you are willing to submit too after you've given all your best arguemnets.

Strictly speaking, as "professionals" we get the job done with whomever our lot is cast with. But if you have a choice, why not hire a freind, even if that person is a "new" freind found through the interview process?

End of the day, if you don't like talking to the person and you don't think they will represent you well without you standing there to make sure, try to pass them over, regardless of thier technical wizardry. Likewise, someone you enjoy talking to who seems genuinly interested in your group, can learn what they need to know.