A couple weeks ago, a colleague of mine asked if I had any good questions I used when interviewing someone to lead a development team.
I came up with this list of questions and “things to listen for” in the responses.
Anyone else have any humdingers they ask interviewees?
Question #1:
A lot of software projects fail. Building software is really complex. If we determine success as: coming in on time, on budget, with a rock-solid product, what would you say your success rate has looked like over the years?
Things to listen for:
Anyone that says they’ve succeeded all the time either:
- Is lying to you
- Has never been in a challenging enough environment
- Isn’t confidence enough to admit to past failures
- Is kidding themselves
- Doesn’t recognize failure when they see it
It’s ok to fail. The ideal evidence you’re looking for, even better than someone that says they’ve almost never failed, is someone that started off average in the beginning (remember, 70% of software projects fail), but who turned it around and ended up with a consistently successful track record after that. That tells you several things: the person is honest, confident in his/her abilities, willing to admit mistakes, learned over time and adapted.
Question #2:
What are the top factors that keep slamming software projects in particular?
Things to listen for:
Look for domain knowledge of the software space. General purpose project management experience may not be enough for complex software environments. Look for tangible factors that can be measured and managed – that’s what good managers look for. Saying that “communication is important” is useless. You can’t manage what you can’t measure.
Some examples of software killer factors that can be measured, and therefore managed:
- Requirements management (creep, churn, lack of documentation, etc.)
- Estimating time
- Estimating distractions
- Knowing when the schedule is solid enough to start making commitments based on it, and when to hold back and not promise anything yet
Question #3:
How do you manage these risks in a software project?
Things to listen for:
Most people will telling you they manage them “internally” (with their gut, or in their head). Um, sure.
Ask for tangible examples or evidence that they do this. Otherwise, they’re probably just telling you what you want to hear and don’t actually behave that way.
Managing all of those things starts with keeping a lot of notes and records. Really good ones will even model them in a spreadsheet. There are so many fiddly-bits that go into software projects that if you can’t go back and look at the record for what happened, then it didn’t actually happen (people will forget and there is no proof of any problem).
Question #4:
Software managers usually come in two flavors: those that come up through the ranks from a technical background, or those that are professional managers (never been a developer). Which would you say you are?
Things to listen for:
Beware of “manager-only” managers. Coming back to the domain experience thing, “professional” (read: jack-of-all-trades-master-of-none) managers struggle with software projects.
There is far more complexity and risk in these types of projects than in others. It’s easier to teach a super programmer how to manage than it is to take an otherwise very organized person (the professional manager) and teach them what they need to know about the software life cycle, the unique challenges and risks, and what to do about them.
Above all, look for people who are really passionate about great software. Someone who’s solely going to tick items off a to-do list until they can say they’re “done” isn’t going to produce great software. And, producing mediocre software on-time isn’t as good as producing great software a little later.
