Interviewing Your Future Boss?

crimethinker asks: "I am an embedded systems engineer for a small division of a large company. Up to now, we have managed to get by with little more than a 'team lead' position, but as our division grows, they are looking to hire a full-on engineering manager. I was one of the candidates, with my current boss's favorable recommendation, but I withdrew my resume when they told me the job was all paper and schedules; I'd never touch code or hardware again. Now the VP has a 'short list' of candidates, and has invited me to be one of the interviewers. Yes, you read that correctly: I will be interviewing the person who will become my boss. So, I put the question to you, Slashdot: what questions should I ask my prospective boss?"

Comments

Ask more about Life, less about Tech.

[frostman]

You should ask your prospective boss about things that will affect your happiness with their "boss-ing."

Since you were a candidate yourself and withdrew, you have probably already figured out that your new boss is unlikely to be your equal in engineering.

But that's not her job anyway.

You should ask things about leadership philosophy, their personal goals in management, their ideas about telecommuting,
about how they balance their work and "real" lives.

Remember that if you are a good engineer, your boss works for you as much as the other way around (unless your boss is the Big Boss of course).

Try to figure out how much you would enjoy having this person around, and how helpful they are likely to be in clearing the way
for you to do your best work.

Use no buzzwords.

Thats my style, and it's worked well so far. I've interviewed about half my bosses and haven't had a bad one in 8 years.

Ask him about his life outside work

[Anonymous Coward]

Seriously, see what he/she likes to do outside of work. You don't want someone who is a total workaholic who will expect you to put in 80+ hrs/wk if that's not your bag.

Mmmmm. Donuts.

[thinmac]

"What is your position on the free coffee and donuts issue?"

On the other hand, if you want to ask *good* questions, think about what topics you and your current boss deal with, and ask about those questions. If it's a management job, then think about what managers can be bad at. Ask about their previous management history (are they a good leader?), ask about how well they understand the technology (are they the quentessential pointy hair?), and ask about how they view the postion from the point of view of being the interface between the techs and the upper management (are they there to keep you down, or to make things go smoothly?).

Also, think about what might happen a year or five down the line that will piss you off, and ask questions relating to that.

Management Style

[n6mod]

You, no doubt, have an idea what constitutes a good manager. If you don't, here's my opinion:

A good manager:
1. Fights for her people with upper mgmt.
2. Gets her people the resources they need to do their job.
3. Gets the hell out of the way.

Put another way:
1. You know he will be there when you need something.
2. Otherwise, you'd never know he was there.

These are the traits you're looking for.

Re:from a I/O psychology point of view...

[Moofie]

If I'm a manager, and I can't manage people who are smarter and more capable than I am, that I am the organizational bottleneck. It is imperative to be able to work with people who are smarter than you are.

So, I'm glad you're not my manager, because I think you'd suck at it.

There's a difference between a team leader and a manager.

Re:Hawaiian Shirt Friday?

[Flamingcheeze]

Ask him this question: What is a supervisor's duty to his subordinates?

His answer will reveal much about his leadership ability.

Institutional memory.

[isaac]

You should ask him how he feels about institutional memory.

I'm not sure how old you are, but if you're approaching 50, you should be worried about being shitcanned and replaced by 2 jr. engineers fresh out of school, each making half your salary.

Whether such a replacement is a good idea or not is dependent upon the circumstances, but repeated purging of senior engineers for junior ones leads to engineering departments that repeatedly blunder into the mistakes of the past.

Ironically, if you're in that 45+ age range, you've probably just given up your best chance both to save your paycheck and to propagate institutional memory. Once you pass 50, you'll probably never get another engineering job should you lose your current one - you'll be too expensive to hire compared to someone a few years out of school (not to mention less attractive - physical appearance has been shown to be a major factor in hiring decisions).

The sad truth about engineering is that you can't do it forever. At some point, you have to step up to management or else you'll find yourself jettisoned at some point with no hope of finding another good-paying job. I've watched my father's career arc and seen a lot of his colleagues fall by the wayside (and through the cracks) because they didn't understand this reality. He's now on the cusp of retirement and is one of the last survivors from his generation of engineers at his company because he was willing to make that move to management.

Having removed yourself from consideration for this managerial role, it's in your interest for whoever's coming in to have an understanding of the importance of striking a balance between cost efficiency in terms of dollars-per-head and the importance of retaining experienced people (e.g. you) who are capable of larnin' them youngsters who will be coming in as your division grows.

Just my $0.02

-Isaac

First question "Why a manager"

[Alan Cox]

Seriously - when was the last time a footballer got promoted from the team to do the paperwork, how many CEO's secretaries outrank the CEO.

If you are the natural team leader then its unlikely the team will listen ot the manager anyway, they'll listen to you. So don't hire yourself a manager, hire yourself an assistant. Someone who goes to meetings for you, plans schedules for you and lets you get on with the real job. That doesn't have to be someone who is in charge of or controlling what you do but someone who enjoys doing the bits you don't and you can work alongside.

So many IT companies seem to screw this up. Good project managers are great people to have but they don't have to be in charge.

Manager as assistant

[solprovider]

If you are the natural team leader then its unlikely the team will listen ot the manager anyway, they'll listen to you. So don't hire yourself a manager, hire yourself an assistant. Someone who goes to meetings for you, plans schedules for you and lets you get on with the real job. That doesn't have to be someone who is in charge of or controlling what you do but someone who enjoys doing the bits you don't and you can work alongside.

I lived this experience.

I was the "lead developer" for many projects at a consulting company. We had several customers that required much personal attention that had no impact on the projects, so I asked my boss (the VP) to hire someone to take the phone calls, make appearances at "strategic" meetings, and handle the paperwork I hated. We gave this person the title "Project Manager" (PM), but the development team still expected my leadership.

We introduced the PM to our customers. He said some silly buzzword filled comments ("Joint Application Development") that added even more meetings, but that was fine as long as none of the techies (including me) had to go to them.

Everything was great until we started a new project. Everybody had the same titles, but the PM decided that as "manager", he should be the top of the chain-of-command. The first time he tried to give me orders, I explained his purpose. The second time, I had the VP explain his purpose. The third time, we transferred him to the Microsoft group.

I have had several great managers (and just hired one of them to work for my new company.) A great manager acts as a filter between the techies and the customers. He protects the time of the techies. He stays out of design and development, but can offer a non-techie perspective when asked.

This only applies if you have a great lead developer. I know of one group that fires programmers with leadership skills. The manager is a non-techie, but knows how to coordinate development with mediocre developers. Adding a hotshot guru programmer would disrupt his system. (He works for a large bureaucratic company where speed is not a priority.)