mmm interviewing project managers
A big part of my job has lately been project management. While I've found to be generally competent in this field, it is not something I want to do the long-term, as it tends to be incredibly draining (I have a newfound respect for good project managers).
So lately I've been busy looking for project management hires. Surprisingly, LinkedIn is an excellent source of hiring for business-oriented people. (It was, however, a GINORMOUS bust for engineering hires... hello, Dice.com!)
As soon as I posted, I got flooded with resumes. I spent a couple of days filtering through 43 resumes. (Even today, I continue to get tens of PjMs resumes ... but I've decided not to even try to keep up with them anymore) I whittled this list down to 13 for a first-level phone screen. I tried to get a good cross-section of resumes for phone screens: ranging all the way from really technical experienced PjMs to completely green PjMs.
I will wrap up my last phone screen tomorrow, and BOY is it tiring to do phone screens. Each one of them took roughly 45 minutes ... that's like 10 solid hours of talking on the phone! It's hard for an anti-social geek like me to remain so lively, interested, and charming (I gotta sell MindTouch as much as these people sell themselves!)
From this list, I think I've found maybe four viable candidates (two realistically, and one I'm really rooting for).
Now I can't lay claim to any type of hiring victory yet - that'll be determined months after the hiring - but I will say that hiring a PjM has been much easier than the search for developers. (I've always found it incredibly hard to judge the quality of developers when hiring.)
For this process, I got roughly 14 questions about project management together and went through most of the questions with all the hires. I scored each answer roughly by the following metric: 70% - knew less than me on the question; 80% - knew about the same as me; 90% - knew about the same as me, but provided some new insight; 100% - blew the question out of the water.
Surprisingly, when using this method, the range of scores I got ranged from 70% - 88% (the range was a lot more than I expected). Apparently I value my own skills too much, or I'm apparently a decent project manager (I could probably do a lot better if I didn't have to focus on running product/engineering, too).
In any case, having a structured format for phone screening interviews seems like something that's pretty obvious, but surprisingly, this is the first time I created a format and stuck with it. I'll be looking to do the same with hiring developers...
For anybody who wants the following project manager questions, here are the ones I used (I feel safe posting these now since I'm done):
- Describe the key concepts of waterfall and agile and their tradeoffs
- What is a project baseline, and why is it used?
- What's a scrum master, and what is their role? (I rarely asked this question)
- What is scope creep, and how is it handled differently within waterfall and agile?
- How do you motivate team members:
- who are burned out?
- who are underqualified?
- who are disgruntled?
- who are burned out?
- How do you earn the respect of engineers and other team members?
- How do you ensure quality in the project you're working on?
- How often do you generally ask for status reports from your team members? How do you like to receive statuses?
- How do you present status reports to your management team?
- Assume you're two weeks away from a project deadline/release and you've learned that the client thinks a major feature was missed in the dev cycle? What do you do?
- What tools do you use to manage your:
- project lifecycle?
- project documentation?
- Assume a client or an engineer (or both!) are working on what you know from experience to be a really bad idea. How do you approach this situation and resolve it?
My one regret with this list is that it mostly contains things I already know how to answer - are there more "advanced" project management questions to even ask? (Or is it like poker, where knowing what to do is obvious, but doing it well is nearly impossible?)
Comment with Facebook
Want to comment with Tabulas?. Please login.
jinshil
roy
hapy
roy
hapy
roy
good answers:
* talk to them, understand where they're coming from
* rotate them to a position where they can try something new (sometimes engineers benefit from talking directly with clients and understanding what they're doing is valuable)
* give them some time off, or give them some small benefits (work from home is a big boon, and oftentimes helps)
* put together a plan to address their concerns and show that mgmt is making progress to improve the situation
but honestly? my first answer is the best.
jinshil
roy
* train them
* give them a "plan" to succeed
the most honest answer is also:
* let them go if they just don't make the cut
the last answer is tough, but people who gave me that answer got a lot of bonus points for honesty.