I ran a workshop recently about hiring for an agile team, and one of the people learning to interview said, “I want a candidate who can take criticism.” I replied, “Don’t you mean feedback?” He asked, “What’s the difference?”
Oh, boy. Plenty. Criticism is when you you’re looking at a piece of code and you say, “This seems brain dead.” But if you say, “I’m confused by this piece of code,” you’ve provided me some feedback. I guarantee you, you want candidates who can take feedback.
So, if you want to know if a candidate can take feedback, here are some possible interview questions:
“Have you recently been in a position where someone reviewed your work?” (wait for a yes answer.) “What happened?”
Offer to work with the candidate in an audition (possibly pairing) and review as you go.
Ask for feedback on some of you work as part of an audition and see how the candidate provides feedback.
“How do you know your work is good?” Wait and see where the question goes. You might be able to follow up with a question such as, “Is there a way you prefer feedback on your work?”
Asking candidates about their ability to take feedback is useful. Asking about criticism is not.
I spoke with a couple of recruiters this week. They’ve been specializing in finding test people for the last 10-15 years. (I used one of them 15 years ago, the last time I was hiring testers.) They both asked a question like this, “With all this Agile stuff, where am I going to find the testers I need?”
Agile breaks the some of the barriers between developers and testers. Both developers and testers need to write code (or scripts). The developers write small internally-facing tests. The testers write small and sometimes larger externally-facing tests. The difference is that the developers write some code that ships. All the testers’ code stays on-site.
If you’re a hiring manager, make sure you train the testers who are interested in writing code and scripts. If you’re a tester, learn to write some scripts, in some programming language, not a test tool’s proprietary scripting language. If you’re a recruiter, have a talk-to-talk with your hiring managers and tell them the testers they want to hire are worth what developers are worth–because they are developers.
Over the past few weeks, I’ve been updating my web pages, which includes (finally) updating my workshops. One of the workshop you might be interested in is Hiring for an Agile Team. Hiring for an agile team can be a bit trickier than for more traditional project teams. The issues of culture, and personal qualities, preferences, and no-technical skills are much more important than in a non-agile team. This workshop is a full day. If you took one of my 1/2 day hiring tutorials at any of the agile conferences, this workshop goes into more depth and explores the combination of questions and auditions that will help make your interviewing and selection successful.
If you want to try this workshop, I’ll be facilitating the half-day version at Agile development Practices in December.
On my recent trip to NZ and AU (to speak about project management), I had some informal conversations with people who could not find enough people for their projects.From my non-scientific survey, it appears that we have started a technical hiring crunch (not enough candidates for positions). Consider people you might not have considered before:
Part-time workers
People over 40. Yes, we can still see and hear. Development is not just a young person’s job.
People over 65. Not everyone enjoys retirement.
People who may not have a degree, but have an avocation for software.
I’ll be thinking about this for a while, because if we really are headed for a hiring crunch, it will be global this time.
Last week, I was working with a client in the Netherlands, talking about how to hire for an agile team. We started discussing how the management team reviews resumes. One of the managers said he looked for people under 40, because otherwise the candidate was “too old.”Well, I past 40 a long time ago, so I asked him how old he thought I was. (Yes, it was unfair and a trick question, because no man ever answers either “does this make my hips look fat” or “how old am I?” honestly.) However, the question did help him rethink his assumptions.I explained that when I started working 30 years ago, we had to test as we went along–we had no testers. If we didn’t want to manually run tests, we built regression test suites. We obtained review on every work product. We made sure our work didn’t break what was already there–every day. We had to. The costs of making defects were too high to not use the preventative ideas that the agile community has adopted.When you’re hiring for an agile team, the real question is: Can the candidate work in an agile way–the way your team works? It doesn’t matter how old the candidate is. It only matters if the candidate is willing to create chunks of working product, or is willing to learn how.
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.
