Posts filed under 'reviewing resume'

Stickyminds Column About Reviewing Resumes for an Agile Team

Based on my Reviewing Resumes for an Agile Team posts, I wrote a column for Stickyminds, Recognizing Agile Candidates. You can leave comments there or here.

Add comment October 10th, 2006

Using Essays Instead of Resumes

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.

2 comments September 21st, 2006

Reviewing Resumes for an Agile Team: Summary

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.

The other posts in this series:

1 comment September 21st, 2006

Reviewing Resumes for an Agile Team: Qualities, Preferences, Non-Technical Skills

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).

3 comments September 7th, 2006

Reviewing Resumes for an Agile Team: What are the Principles Underlying the Projects?

As Esther says in her fine comment,

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.

1 comment September 5th, 2006

Reviewing Resumes for an Agile Team: Look for Practices

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.

1 comment August 31st, 2006

Reviewing Resumes for an Agile Team: Start with Lifecycles

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:

  • Scrum: 4-week iterations. See Ken Schwaber’s site.
  • 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.

2 comments August 30th, 2006

Hiring technical people and being hired can be difficult, no matter what the economy is doing. Use the tips here to hire better, or find a new job.


Search