Bruce Eckel has a nice post, What Questions Would You Ask?, especially for developers. I really like the question about books :-)Here’s how I would expand on that for project managers and testers:
How do we you make project decisions? Can you give me an example?
What happens at the end of the project? or Do you ever have crunch time at the end of the project? What do you do?
When was the last time you had a one-on-one with any of your staff (for a manager or project manager)?
Last week at SD, I met up with Brian Robertson of Ternary Software, a small consulting company in the Philadelphia area. They have a different approach for their first contact with a candidate: they ask candidates to fill out essays (scroll down to see the essay questions).These essay questions reflect the culture of the company. So the people who are likely to write the answers are already self-selecting the company’s culture.Not every organization can use essay questions such as these, or any essays at all. And if you do, talk to your lawyers to make sure the questions don’t discriminate against people. But I do like the idea of looking at people first, not resumes.
I hope that when you read these posts, you came to the same conclusion I did. It’s almost impossible to detect from a resume whether or not a candidate is accustomed to an agile project, or could work on an agile project successfully. Keywords, especially, are useless when it comes to reviewing resumes. So what’s a recruiter or hiring manager to do? Look at domain expertise, glean what you can about the kinds of team the candidate has worked on, and develop a phone screen or an audition that you can use before the interview.
Phone screens don’t have to take a lot of time. Sure they’re inconvenient. One technique I saw at SD last week was the essay as a pre-interview assessment. Sure you’ll still have to read the essays, but fewer candidates will write them, so you’ll have fewer people to screen.Phone screens and essays are time consuming and possibly inconvenient. But a bad hire is more than inconvenient–it’s much expensive than any time you spend phone-screening or reading resumes.
So, if you were looking for a developer or a tester or a business analyst (or a whatever role) for your agile team, what qualities, preferences, and non-technical skills might that person have? And, is there a way to recognize those characteristics in a resume?Here’s a potential list of qualities, preferences, and non-technical skills. This can only be a potential list because every team is different and the characteristics they’re looking for are likely different. On the other hand, many agile team members share these qualities, preferences, and non-technical skills: (If you have more characteristics, please comment.)
A desire to finish things. (This helps the team accomplish the goal of working software.)
A spirit of collaboration. (This is partly working across the team, and the ability to contribute to work product review.)
(There’s a word here I want. Is it the idea of egoless work? Help!): The ability to ask for help, to seek out review.
The ability to take initiative. (To take tasks off the list, to see where there are problems in the code or tests and to refactor.)
Enjoy working in an intense environment. (The shorter the iteration, the more intense the daily work is. The pace may be sustainable, but the work is intense.)
Ability to develop and maintain collegial relationships across the team.
So, are you going to see a resume with these characteristics on it? Not in keywords. You might see a statement like this: “Worked with the team to release in pieces, to obtain feedback on already-completed features.” That might mean the person had a whip. Or, it could mean that with a collaborative style, the person helped others see how to implement by feature and continually test as they used continuous integration to see where they were day after day. You can’t tell from this sentence.When I review resumes, I let the person’s resume guide my thinking. I look at all the statements, and try to picture what would be true for this person to have accomplished that. And of course, I have my own filters for how I perceive the statements (as you do).
There are lots of ways to do all these things — and sometimes teams do all the “practices” but still don’t meet the principles.
Exactly. And it’s very hard to see the principles under the project when you’re reviewing a resume.Here’s a statement I’ve seen on lots of resumes: “Led the development of some-feature-or-system.” Does that mean the candidate architected the whole thing and handed it off to coders? Does it mean that the person used some set of collaborative techniques, but did all the architecture at the beginning of the project? Does it mean that the person was a technical lead who collaborated on several prototypes with other developers? Maybe the candidate helped the product owner decide which features were architecturally risky, and suggested the team implement those features first, to see how to evolve the architecture. And if you’re seeing a person who’s collaborative, is that enough for your project?I don’t know how to see the underlying principles on a resume in keywords. I do know how to look for principles as I read the whole resume. And if you see enough principles, then it’s worth a phone screen for the candidate.