Management positions have a greater emphasis on people skills than development positions (although it is important there, as well). I would suggest that you focus on those people skills. Here are some sample questions that you could ask and the rationale behind them.

• Describe a successful project - what role did you play? (watch for answers that inflate the ego rather than indicate a willingness to serve and support)
• How would you approach a project that is in danger of falling off track? (watch for answers that promote "authority" at the expense of "leadership")
• What is the most important thing a manager can do to improve morale? (Have they thought about morale? A good manager knows that it is all about letting good people find their groove rather than micro-managing).
• Can you quantify your strengths/weaknesses as a manager? (I would highly suggest that you get familiar with the "StrengthsFinder" ^[1] approach!)
• Describe a difficult employee from your last job. How did you handle them? (Again, this can help you avoid the authoritarian boss).

As you develop additional questions, start with the information you are really after and then craft questions that help reveal the answer without giving him obvious softballs. For example, you can't ask "are you an authoritarian boss who'll bulldoze people into doing things your way?" because the answer will be obvious. Instead, try to focus on real-life experiences that will reveal the real person behind the mask. The nice thing about this approach is that, if you do have references you can call, you can find out how well their description of a situation matches those of the reference. I've found out some very interesting information that way!

Interviewing your potential boss isn't easy but you are fortunate to have some say in the matter! As a boss, I'm acutely aware that I play a support role for my employees - NOT the other way around.

I see there are several answers already, which, while good, don't really get into issues related to programming -- so let me try to help, as I do have personal experience in this (interviewing candidates for Director positions -- one of those I interviewed actually became my boss for a while;-). The big thing to probe on, that's directly related to programming, is how the candidate's skills, attitudes and strengths on key issues of programming methodology match with where the organization is now... and where it wants to be in the mid-term future.

What does the candidate think about "waterfall", vs "iterative but highly structured", vs "agile" methodologies? A candidate who doesn't understand what you're talking about, or doesn't care about the issues (doesn't have a preference, or can't justify it with sound but brief reasons) is not going to be a strong Director. If the candidate does well in having and justifying a preference you must still check that the preference is compatible with where the organization "is [or is going to be shortly] and WANTS to be", or not. If the organization, for example, currently uses (nominally;-) "waterfall" but wants to move to "agile" (maybe that's why they're hiring a new Director...?-), and the Director defends waterfall in an able way, he may not be a match; if he ably defends "agile" (or some specific variant of it), then you may continue by checking how he would plan a gradual transition (if he argues for "big bang", or "agile for new stuff but all existing stuff stays waterfall until it dies a natural death", those are slightly worrying signs, so check if he's ever actually led a successful transition with some similarities), how he would spot and convince stragglers (if he thinks "top-down commandments" are all he needs to do, rather than direct involvement in such a big transition, that's a red flag), etc, etc.

Similar discussions apply to other choices, such as various technologies -- say, operating systems, programming languages, database engines, and the like. If the organization is currently stuck with "Cobol on mainframe operating systems with DB2" and desperately wants to transition to "Ruby on Linux with PostgreSQL", then you ideally want a Director who understands (at least a little;-) both poles on each of the three dimensions (language, OS, DB engine), prefers the one you want to move to, can articulate why, can sketch a plan and a strategy for the migration (and how to deal with stragglers), etc, etc. It doesn't really matter if the candidate can't recall details of Cobol and/or Ruby syntax -- it DOES matter, in this scenario, that he has a clear understanding of the strengths and issues of both, the migration problems, &c, and can articulate and evangelize and prod and cajole &c &c.

Maybe you guys aren't planning any big change -- then the key issue is with the level of skill and comfort the candidate shows about what you have and want to keep, on all kinds of methodology and technology choices. You don't want a Director who's a fierce OpenBSD fanatic if you are and plan to stay on Windows -- or vice versa!-)

Ah well -- this is probably my longest ever SO answer, and I still haven't touched on many issues... most of them fortunately fall into similar patterns. You don't have to have the candidate produce a single line of code (although a general familiarity with algorithms and architecture couldn't hurt...), but to be a strong fit he must be comfortable with discussing, debating and deciding on "big" technical issues like those I detailed above (which ones are really important depends on your org, but, one way or another, there WILL be plenty to fill an hour's interview;-). "Softer" / more "cultural" stuff you can mostly leave to other interviewers who may not be as technically strong as you are...

The actual duties of an engineering director can vary depending on your organization, but in general when interviewing someone who might become your boss, and where soft skills are probably going to be more important than just technical skills, I'd use behavioral interviewing techniques - you might draw from examples of difficult situations your organization currently faces. If you know the current organization well, try to assess whether this person will fit in. If this person might be your boss, get a feel for whether or not this person will make it easier for you to do your job and is interested in your growth. You should also assess if this person will be suitable for the future you envision for your company - chasing new adjacent markets, handling organizational growth (organic or otherwise).

Finally, if this is a lateral move for the candidate or a step up or down, or coming from a different industry, may also influence the type of questions you ask.

I would ask about these:

• Process (SDLC) experiences and opinions (i.e. Agile, Waterfall, etc.)
• Opinions on Source Control
• Opinions on production control (dev/qa/staging/prod environments, automated build & CI)
• Management philosophies and practices (coaching, feedback, professional development of direct reports)
• Description of a time they have gone to bat for the team or for a direct report
• Description of a time they have had to challenge senior leadership and have them rethink a decision

I would suggest asking a combination of technical and scenario questions. What you want from a technical director are the following properties:

• Technical
• Articulate
• Humility
• Encourager
• Respectful

You can get a lot from scenario questions about what a person's actions will be under certain circumstances.

What you want to know is whether your new director would be a good fit with the programming team. To me, the most important is to know whether they have too big of a head for their own good: heeding no advice from members of the team, having a "my way or the highway" attitude, etc.

Here are some other things I'm planning to ask:

• How have you dealt with feature / requirement creep?
• What release criteria have you set on projects?
• How have you dealt with people / teams who have missed deadlines?
• What software design principles have you followed in your career?
• In what ways do you stay current with emerging technologies?