How Would You Interview Potential Managers?

martincmartin asks: "The company I work for is starting to interview development managers, and I've been asked to interview a bunch of them. While there's been a lot written on interviewing programmers and what makes a good manager, how do you interview a management candidate? What questions do you ask? What are good and bad answers? What else do you do?"

Comments

Re:Get him talking

[canUbeleiveIT]

I ask people about their management philosophy, but for people who aren't very reflective, they don't have a lot to say.

This is an excellent point. For whatever reason, many of the really talented managers that I have worked with are simply "naturals." They haven't a clue how to articulate how they do what they do--they just do it. I realize that this probably rubs many /.ers the wrong way, but the smartest and most reflective people aren't necessarily the most effective managers.

One such manager that I used to work with was Patti. She was unremarkable in every way (looks, intelligence, education) and I guarantee that she had never read any "management philosophy" books. But she had a naturally calm and pleasant demeanor, an innate ability to make correct decisions on the fly, and great ability to prioritize. Her honesty and integrity just gave her such an air of authority that she rarely had to use the power of her position to get her people to get the job done. Needless to say, she was always the top-performing manager in her category.

Personally, I would much rather have this type of person than some hot-shot who thinks that he is the smartest guy in the room.

What to watch out for ...

[Anonymous Coward]

A good manager has good interpersonal skills and is usually gregarious. Unfortunately a psychopath often does a good job of imitating those characteristics. We hired one and it was a disaster. By the time we figured out what he was and got rid of him he had done a lot of damage to the organization.

The people who study managers are finding that psychopaths are good at getting management jobs but are very bad at running an organization.

My advice is to focus on achievements. How has the candidate done at team building? Really check their references. Ask for the names of some employees you can contact. A boss may miss the fact that someone is a psychopath but an employee never does.

link

Re:What level?

[Anonymous Brave Guy]

OK, I'll take a stab. For reference, so you know how much or how little my opinion is worth, I've steered my career towards being a senior technical person rather than management. I'm pretty much a sideways move from the level of manager you're looking to hire here.

With that disclaimer given, what would I want to see in such a manager? I think there are specific things involved with managing people, managing projects, and technical leadership. AFAICS, you haven't given a more detailed description of the balance of these for your specific post, so I'll outline my thoughts on each of these areas.

Managing people

It's been my experience that good managers of people tend to do three things well:

• Set realistic expectations.
• Provide adequate resources.
• Get out of the way.

Someone jokes elsewhere in this discussion that you can't just judge managers by how hands-off their approach is and who gives the most perks to their staff, but frankly, I think just doing that would be more successful than the current policy at many organisations!

So in terms of interviewing a potential manager, I would be tempted to go for a practical example to judge their people management skills: describe an imagined next project for their team, and ask them how they'd go about finding out enough about the people they've already got to divide up the work, how they'd deal with any gaps (going into recruitment and team-building ideas if it's relevant), maybe how they'd deal with any apparent surpluses or team conflicts as potential difficulties, how they'd go about briefing the team and getting them started on the work, and how they'd monitor and support their team once it was up and running on the project.

Project management

To me, this aspect has a lot to do with dealing with the people above the manager:

• How would your interviewee make sure they've understood what is required of their team?
• How would they expect themselves and their team to interact with more senior management during the course of the project?
• How would they deal with changing requirements?
• How do they go about planning a schedule, assessing risks and building in slack time, giving reasonable estimates, and so forth?

Again, I'd be tempted to set this in the context of a concrete example or two during the interview, starting with their first thoughts on an initial brief from senior management, perhaps switching to the people management work above next, and coming back later in the interview when some requirements now need to change halfway through the project to see how they'd deal with that.

Technical leadership

If this is relevant for the post in question, I'd be looking for:

• their ability to think about their software design in big picture terms
• whether they see how different areas would interact and how they might map development of related areas onto their team of developers
• how they would ensure adequate testing (Are all 10 staff under them developers, or are some of them testing people? Are there other testers available within your organisation, with whom this team will need to work? What sort of balance between coders and testers does your interviewee prefer to work with, and how would they go about getting it?)
• how they would balance getting the immediate requirements satisfied against long-term flexibility (including getting early prototype work up and running to avoid holding up other team members, while not unduly delaying completing the detailed work for each developer or sub-team)
• their ability to assess the overall merits of different tools, programming languages, etc. that might be used on a project, and how they would go about identifying sensible options and deciding between them at the start of a new project (which is not the same as having guru-level knowledge of multiple programming la