It’s now a hiring manager’s market. That means hiring managers can be picky and try to find just the right person for the open req. But, it also means that many applicants exist for each open req, and all of those people are applying for your job. How does a hiring manager find the right person?
First, realize there are any number of “right” people, and the first thing is to eliminate the wrong people. That means it’s even more important to do a job analysis. Once you have an analysis, you can see what’s essential for this job and what’s merely desirable.
Now, as you review resumes, you can say no to these people:
People who don’t follow your rules for how you want to see the resume. If you want a doc file or a pdf or a text or in email, be specific about what you want. Anyone who doesn’t send you what you want is someone you don’t need to look at.
Anyone who doesn’t fulfill all of your essential qualities, preferences, non-technical skills.
Anyone who doesn’t have a minimum technical skill set that makes sense for your job
Anyone who doesn’t have experience working the way you do. If you’re agile, you don’t have to look at someone whose projects for the last 10 years were serial lifecycle and were late.
As I review resumes, I have three piles: yes, no, maybe. If you have a lot of resumes, many of them should now be in your “yes” and “maybe” piles. Now it’s time for phone screens. I’ll talk more about that tomorrow.
P.S. the job analysis link link was broken and is now ficed. If you’d like to see all the templates, click here for the templates page.
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.
Once you’ve seen some evidence of a lifecycle, look for the practices the candidate has used on projects. To be honest, I can imagine seeing one or two of these on a resume; certainly not all.
Test-driven development (likely to be on a resume)
Unit testing (likely to be on a resume)
Pair programming (likely to be on a resume)
Continuous integration
Rolling wave planning
Frequent refactoring
Frequent customer interaction
Minimizing up-front planning and design
Being honest about where things are
Short iterations
I would be wary of what I do see on resumes. Here’s a true story. I met a project manager recently who said he was managing an agile project. I asked what lifecycle he used. “Agile” was the answer. So I asked how long the iterations were. “Oh, as long as we need.” I asked if the team was following Scrum or FDD or some specific lifecycle, and he said again, “Just Agile.”Ok. I must not be asking the question correctly. So I asked which practices the team used. “Continuous integration, standup meetings.” I asked about TDD or pairing or rolling wave planning. Nope, none of those. When I asked more questions, it turned out their “standup” meeting took an hour and everyone sat down in a conference room.His project was being disbanded because the project team didn’t deliver. (What a surprise–NOT!) These people are all putting “agile” kinds of things on their resumes, and that project sure wasn’t.
So even if you see the practices listed (or if you don’t), make sure you ask behavior-description questions to see what the person actually did. I’ll give examples of those questions in my next blog post.
I spoke with a recruiter yesterday about how to hire people for an agile team. Her client had suggested she look for people with XP experience, and that candidates have “stand-up meetings” on their resume. Oh no. Looking for agile people is much more than keywords.If you’re recruiting for an agile team member, first, decide what’s most important to you. Do you care about the lifecycle or the practices? Which ones? Or, do you care more about the cultural fit of the person into the team and the ability to work with a team? There’s no right or wrong answer, but it’s worth knowing.Here are some lifecycles you may encounter:
XP (eXtreme Programming): 1- (or 2-)week iterations. See Ron Jeffries’ site.
FDD (Feature Driven Development): iterations can be as long as 6 weeks (I’ve never been a part of an FDD project, so I may be wrong on this). See Feature Driven Development.
Crystal: Alistair Cockburn has a whole variety of lifecycle adaptations based on Crystal. Although it’s implementation by feature, I don’t believe there is a particular length timebox for an iteration.
DSDM (Dynamic Systems Development Method: See DSDM Lifecycle (free registration required). DSDM does have implementation by feature, but it’s not clear to me the timeboxes are of fixed length.
I’m most familiar with and comfortable with Scrum and XP (I’m a Certifed Scrum Master). If I’ve made any mistakes in this list, please let me know.So, when reviewing a resume for an agile, look for the lifecycle names in this list. If you don’t see any, don’t give up hope. Look for an iterative lifecycle, such as RUP, UP, Evo, or an incremental lifecycle such as staged delivery or design to schedule.Reviewing resumes is important. But don’t throw people out because they don’t have exactly the keyword you’re looking for. You’ll throw out a lot of qualified people that way. See Tips for Reviewing Resumes for more info. My next blog posting will be about agile practices that you might see on a resume.
P.S. Thank you to Jason Yip who updated my iteration time for XP.
A colleague asked today “What keywords should I look for on a resume?” I wish there was a list and you could just scan resumes looking for keywords. (Yes, there are software packages that do that. I’m not talking about tools and technology keywords. Don’t get me started on ruling out people because they’re missing a language or something else learnable.) Here’s what I look for in a resume:
The summary and objective. Not everyone has a summary or objective, but if the resume has one, I look to see how similar it is to the open position.
Some description of the value the person provided at each previous position. I love it when candidates quantify their value (“saved $10 in every meeting”), but I’ll take something like “improved build process.” (Candidates, if you did, talk about how much time you saved. Remember, senior managers care about time, money and customer experience. Any time you can relate your work to saving time or money, or improving customer experience, you’ve described useful value.
The context in which the candidate has worked. Small or big projects, which kind of industry, long projects, canceled projects, releases every 10 minutes, whatever. You want to look to see how well the context the candidate has worked in translates to your context.
Action verbs. Savvy candidates know that the best resumes have action verbs to describe work. “Worked on” is weak. Any of: led, designed, developed, improved are great, the more action-y the better.
Here’s what I don’t look for, unless it’s somehow relevant to the job: classes, education, hobbies, any personal things at all. There’s no guarantee the person learned anything applicable in those classes or in that degree. Hobbies might satisfy my personal curiosity, but aren’t relevant, and personal things aren’t relevant. (If a candidate writes down anything, it’s always something like “excellent general health” — why would someone say otherwise??
)So, I can’t offer you keywords, but if you read with some discernment, you’ll be able to read resumes quickly.
Some hiring managers use certifications to filter resumes. I specifically caution against that practice in the book. I’m not a fan of certifications. Michael Schrage’s column Hiding Behind Certification is another article about why certifications are not a good predictor of job success. Here are two quotes I particularly liked:
“The truth — as we all so bitterly know — is that the IT world is filled with certified, credentialed and accredited idiots.”“…the real value of credentials and certifications like CMMs and MBAs is not that they indicate greater skill, but they signal to the market that these individuals and organizations will jump through hoops to demonstrate how much they care about being seen as top-notch. … the willingness to procure credentials can reveal more about attitude than aptitude.
Although Schrage is talking about IT, his observations aren’t limited to IT. Unless you’re talking about licenses which require some sort of an apprenticeship, certifications are no way to screen resumes or make a hiring decision.
