Interviewing Your Next Boss: Putting the Programming Lead on the Hot Seat

Should developers interview the tech leads to whom they'll report?

Developers have an advantage over most professions in hiring: You can audition prospective team members. You might do so in a casual quiz format ("How would you solve this programming problem?"), or you might arrange for a full day of pair programming. But at the end of the day, the development team and the candidate both have some sense of the other's actual skill set. The "real work" probably breaks through the chest-beating "My Accomplishments" recital and the uncomfortable silences.

But here's a variant: what if it's a manager being brought in? Should that candidate, too, meet with everyone who'll report to her?

For some reason, the traditional interview process has job candidates meet only with the people to whom they'll report, such as senior management. If the proto-manager's would-be bosses are impressed, the candidate gets the job. But surely managing "up" is a different skill from managing "down," and I'm not certain that HR departments grok this distinction. At my most cynical: Do you want the company to hire someone who's a corporate suck-up, but hasn't a clue about what her direct reports do all day? I doubt you do.

Yet, it seems rare (is it?) for candidate-managers to be quizzed by the people who'll work with them every day... and who, I like to think, are far better at spotting the candidates' weaknesses. ("He says he knows all about code optimization, but he couldn't answer my question about...") Besides, the developers are the people who are stopped by an incompetent manager or tech lead, who can't get their work done because there's an idiot in between the worker-bees and senior management.

I see major advantages from a purely "teamwork" point of view, too. First, everyone likes to imagine that the Powers That Be care about the worker-bees' opinions, especially since said worker-bees have to report to the new manager. Even the illusion that one may have a choice in the participants for Monday morning status meetings gives a developer a measure of control over his own life.

That's certainly true when the last manager was less-than-ideal, but equally important when the new manager replaces a manager of godlike abilities. You might have chosen your current position because you wanted to work for an inspiring leader (and I've been lucky enough to do so, on more than one occasion). When that manager leaves, the company needs to recognize the social contract it had with the team members—and enable them to participate in figuing out who can help them get the job done next.

It helps the candidates, too. The winning candidate starts out with a better sense of the team's culture, its attitude about existing projects, and the personality of the team members. Your prospective manager can also select herself out, by seeing that this company isn't a good skill fit or by recognizing that your team puts the fun in "disfunctional."

I'm not saying that setting up job interviews with the lead candidates is always easy to pull off—at least for the other people in the room. If you're a tech lead at another company who is quietly exploring alternatives, you might not want to let 5 or 10 additional people know that you're job-shopping. It adds time to the process. HR may not want to tell the team that the candidate everyone adored asked for a salary twice that of the next-most-acceptable proto-manager. If one team member hates hates hates the winning candidate (even if everyone else loved her), what political fallout might there be?

Plus, as a member of the Extreme Programming group pointed out, you can't always expect a positive result. The development team at one employer interviewed somebody for whom all of "us peons" had great distaste, explained one programmer. "They hired the candidate anyway," he said. "At least it made our proper place in that company crystal clear; it was simply more fuel for us to want to leave."

Then there's the whole can-o-worms of how to interview the person who's apt to be your new boss. For example, a techie might grill the manager on technical trick questions appropriate for asking another programmer but unsuitable for the person whose job it is to get him to write the code. But "how to interview" is another issue entirely.

Despite the downside, I think that letting the developers interview their new managers—and developers insisting on it—sure beats the alternative: springing a new boss on the team without any input whatsoever.

How often have you gotten to interview someone to whom you might report? In enlightened companies or elsewhere?

This story, "Interviewing Your Next Boss: Putting the Programming Lead on the Hot Seat" was originally published by JavaWorld.


Copyright © 2009 IDG Communications, Inc.