There’s been a lot written about interviewing programmers, and about good management, but I couldn’t find anything about how to interview managers. So I’ve been looking into it and thought I’d write up what I’ve learned so far.

First of all, some things not to do. While you might want to lead with a big, open ended question (“What’s your management philosophy?”), you don’t want most of your questions to be like that. That’s because while some people are reflecitve and think explicitly about what they do, there are others who are “naturals.” The naturals have good instincts about how to handle most situations, but they may never really have thought about what they’re doing or tried to put it into words. So instead, you want most of your questions to be scenarios.

Also, there are all kinds of managers and all kinds of companies, and all kinds of groups within a company. You really need to tailor your interview questions to your situation. Does the person need to be a technical lead as well as managing people and projects? Do they put a lot of emphasis on following standard procedure, or are they happy to short change them if they think it’s best for the project?

For example, the company I work for started 10 years ago with a single product, a search engine for airfares. It was started by a bunch of Ph.D.s from MIT’s AI lab, and they hired others like themselves: really good programmers, with a good understanding of algorithms, that worked independently. We’ve always had good tech leads, but they don’t like writing reports or dealing with various people’s personality quirks. As we get bigger, we’re looking for someone to help us communicate and coordinate better. More of a cat herder than a shop forman. We’ve got a culture that we like and are really proud of, and anyone we hire needs to understand that they can’t just change things by fiat.

And the same thing applies to the details too. The sorts of personalities that comprise the team, and the dynamics you get. How to deal with that one guy in another group who is supposed to make tools for you but is too busy to maintain them properly. So take a break from what you’re doing, get yourself a cup of tea and think about ongoing situations at work that you really wish a manager could deal with.

Still, it’s useful to have some examples in mind. Here are some good ones that should apply almost anywhere. You can ask them in isolation, but giving a scenario will get you more insights.

1. What’s your management philosophy?

If they don’t have much to say here, that’s ok, they may not be reflective. Just go on to the next question.

If they do have something to say, that’s great. Get them talking about it for a little while. For example, ask them if they’d recomend any good management books, to pick one and summarize it and say what they liked and didn’t like. You don’t want to spend too long on this, though, because this person might have MBA disease. It’s really an example of a wider phenomenon: having theoretical experience without practical experience.

Have you ever had the experience in school where you read through the chapter and everything made sense and you thought “ok, I understand this.” And then you looked at the first problem in the problem set and had no idea how to do it? People who have done a lot of reading and little doing can go on for hours saying great things about theory, but get confused when real world situations don’t map nicely onto what they know — which they never do.

The best is if you can get both: people who have good instincts, yet can talk about why. They’re more likely to learn from mistakes and adapt to changing times. But if the person only has one, the practical ability is far more important.

2. When a developer is working hard but not getting far, how do you notice?

The tricky thing here is knowing how long something should take. The manager could expect the technical leads to mention this to them, although that doesn’t help if the manager is also going to be a technical lead. The standard answer these days is, at the start of a project, have the developer create a schedule. Then you can see if there’s some task that is taking a lot longer than it should.

3. Once you notice, what do you do?

A common example is laying out a Swing GUI in Java. Most people, on their first attempt, get something that looks great — until you resize it. You can spend a long time tweaking it and not getting anywhere. So what do you do when someone eventually admits they don’t know how layout management works in Swing?

This gets at the issue of personal safety. If you somehow punish the developer, they’ll be less likely to admit problems in the future. And then you won’t find out about them until it’s waaaaaaaay too late. Good answers are to get them training, books, or a mentor. Bad answers are to give the project to someone else. That makes them feel like they failed. Bonus points for talking about how to match people to projects in the first place that minimizes the chance of this.

Some other good questions for personal safety are “What do you do when someone admits they’ve grossly underestimated how long a project will take, by more than 50%?” “What do you do when a developer says they’ve just recieved a tempting job offer?”

4. How do you get developers to produce more, that is, make them more productive?

As you might imagine, this is a big question. There are many things that affect programmer productivity, and the list varries from programmer to programmer. Surprisingly, people always seem to give a single answer: working on an interesting (or challenging) task.

So once they reply, ask them for others. You can find lots of possibilities in the Mythical Man-Month and Peopleware. Writing quality code, higher quality than the market demands. Working with top-notch people. Offices rather than cubes. Fast computers with dual monitors. Free reign to buy whatever technical books they need. Freedom to play with new languages, tools or “technologies.” Training to learn cool new things and keep their skill set up to date. Free soda and snacks. Forty hour work weeks. Praise them. Talk to them about what they’re interested in, what parts of their previous tasks excite them or bore them. (Believe me, it’s not the parts you thought.)

Job ads ignore all this stuff too, which is surprising. In the recruiting I’ve done, people listen politely when I talk about our clever search engine, but they’re faces light up when I say:

And our founders really understands what motivates programmers. They give people offices, not cubes. We try to match people to projects they’re interested in, within business constraints. We have some leeway in what features we implement, so if someone’s interested in a particular project, we can sometimes have them do that when we wouldn’t have implemented it at all. We put a lot of emphasis on hiring and set a high bar, then give people good salaries and benefits. So you’ll be working with really good people who will appreciate your clever ideas rather than feel threatened by them. The company was founded by 3 people with Ph.D.’s in AI from MIT, and understand that some academic ideas are worth trying even if they don’t work out. There are always people who can answer your questions. We don’t push people to work crazy hours. Once a week we have someone talk on some topic of general interest to programmers, either from within the company or from a local university (and there are a lot of those in Boston.)

After that, the only thing people want to know is where they can sign up.

I don’t know why jobs ads don’t mention this stuff. I occasionally browse job ads when I’m bored, and some of them even look interesting. But I have no idea whether my coworkers idea of a difficult problem is reversing a string in place, or whether the boss will think spending $700 on a profiler is a waste of money. The chance that these places will be better than where I am now is so small, it’s not worth even talking to them on the phone.

Bad ways to (try to) increase productivity are are to set “challenging” deadlines, telling people they need to do better no matter how well they do, and giving pep talks. If the candidate says to give them a “challenging” task, ask a little more. What makes it challenging? If the technical aspects are near the edge of your ability, that’s good, that’s a condition of flow. But if its simply an “aggressive” deadline, that’s bad.

5.What’s your take on giving feedback to your developers? On performance reviews? If done poorly, they can really demotivate a developer. What should you do, and what should you avoid?

I was once worked with a developer would tend to come in a little late and leave a little early. One day he came out of a meeting with the boss looking angry and frustrated, almost livid. Before long he started talking to us other developers. There was an HR representative at the meeting, and the boss spent the whole time scolding him about his hours, including a formal warning. Later, at lunch, he said he hadn’t been able to get any work done since the meeting, that all he’d been able to do was mull it over in his mind. The boss hadn’t said anything about not getting enough done. The developer concluded, among other things, that the boss cared more about how many hours he worked than what he got done.

Later that night the boss and I were watching The Matrix, and at the scene where Neo’s boss chews him out for being late, he turns to me and says “Oh my God, I’m the bad guy!” This is a guy who normally doesn’t talk during films, but an hour later, as soon as the credits started to roll, he turned to me again and said “Oh my God, I’m the bad guy!” I tried to calm him down, but I think he realized that he’d made a big mistake.

Psychologists have studied how people have a higher opinion of their own abilities than others do. When they do something well, they tend to attribute it to an inherent trait. “I figured out how to write this tricky bit of code; I’m smart”. When they do something wrong, they tend to think it’s a fleeting condition “I forgot to check in that file. Silly me, I’ll remember next time.” Bringing their perception in line with reality will deal them an emotional blow. This is especially true of those whose self-worth is wrapped up in their programming availity, something’s that pretty common among those driven to become the best programmers. Don’t be surprised if they spend the rest of the afternoon staring at their screen in shock, feeling as if all their hard work and cleverness is unappreciated — even if you spent most of the review pointing it out and praising it.

There are certainly those who think performance reviews should be scrapped. Perhaps there are ways to do performance reviews appropriately, but what you’re looking for is awareness of these issues. Answers focusing on communicating an accurate picture, even diplomatically, are bad.

Follow up questions: “What’s the purpose of performance reviews? How do they affect morale? Have you or someone you know ever had a bad performance review? How did it affect your productivity? Your motivation?”

Well, that’s enough questions to get started. Even some of these won’t apply to your organization. And if you can think of any better ones, please let me know!