Hiring for an Agile Team
Agile development model has spawned a lot of interest, conferences and books across the entire software development community. The paradigm of effective software development has taken a shift in the right direction. One area which still seems to need some refactoring is the best way to hire for an Agile team.
The traditional interviewing methods, with the traditional résumé and interview process, failed to take into account a developer's aptitude to work in a highly collaborative workspace.
The extreme interviewing technique applied by Menlo is structured more like an audition. Here programmers applying for the job are paired together and observed. The outcome of the interview is not dependent on the solution of the problem but their communication, teamwork, discussions, problem solving capability and other soft skills along with the technical skills. The details of the process are shared as a white-paper.
James Shore suggested a hiring approach with five stages. The earlier stages take the least effort and filter out the greatest number of candidates. The later stages take more effort and evaluate specific qualifications of the candidate.
- Candidate Self Filtering - Creates a barrier to entry that filters out people who aren't willing to make an effort e.g. including five essay questions with a job posting.
- Pre-Interview Filtering – Team reviews the candidate submissions to the essay questions as soon as they come in. A thumbs down by any team member means that the next stage is not required.
- Behavioral Interview (morning) - Allows the team to learn more about the candidate's personality and experience.
- Pairing Sessions (afternoon) - Provides a detailed look at the candidate's real-world abilities and behavior. Candidates pair on real world tasks for the ongoing iteration. The following morning the interview team gets together for a debrief using the ORID format.
- Offer - is the last stage where the hiring manager is involved and a job offer is released.
Darren Hale also suggested a similar multi-stage interview process to assess the technical, process and personal attributes of the candidate. According to Darren
Interview is broken up into three segments: technical, process, personal. For each segment, we assign at least two team members so that a majority of the team gets to interact with the candidate. The technical portion of the interview focuses on raw technical ability and includes a hands-on programming exercise. The process portion gets into philosophies on testing, problem solving, and pair programming, among other topics. The personal section looks at conflict resolution, personal motivation, and general mental stability. We've found that this process works very well.
Johanna Rothman mentioned some of the questions that she gathered from an Agile workshop on “Hiring for an Agile Team”.
- Tell me about a time when you participated in a debate on differences of opinion
- Tell me about a time when you went along with a team decision you disagreed with
- Tell me about a time you needed info from elsewhere but were initially unable to get it
- Tell me about a time when you were successful at getting/having the team take a different approach
- Tell me about a time when you challenged the team’s direction.
These questions specifically help the teams evaluate how the candidate manages the day-to-day interactions with others, including the issue of initiative and getting along with a team.
Thus, hiring technical people for an Agile team and being hired can be difficult, no matter what the economy is doing. The key lies in identifying a sound process to get the most compatible people on board. People should be hired for talent rather than specific skills that they possess at that particular time.
As Sheridan put it
My advice is to hire for talents rather than skills, build an environment where skills can be learned and reinforce the culture you are trying to build in the interview process itself. Too often, our industry hires for exact skill matches. I often counsel new college graduates to avoid these kinds of employers, as the message is clear: "We are unwilling to invest in you."
+100 regarding the "audition" approach
I also wonder about pairing two candidates together. It seems to me you would not find out how either candidate would work with the actual team. Since both participants are candidates, their interaction is largely random; the team cannot include elements in the pairing session that are designed to draw out particular responses from the candidates.
I prefer to pair one candidate at a time with two or more members of the team the candidate would be joining, in the team room so that the working context is real and so that other team members can see/hear what's going on without crowding around and making the candidate uncomfortable. What we're looking for is an opportunity for the candidate to function in a realistic situation, to give both the team and the candidate a clear idea of what they would be getting into. When the candidate pairs with a team member, the team member can deliberately use different pairing styles, make suggestions about design or TDD approach designed to elicit reactions from the candidate, and explore the candidate's willingness and ability to question bad ideas and suggest better alternatives.
Jim Shore's five stage filtering process sounds pretty good, but still stikes me as depending heavily on talking. It also sounds as if it has an inherent risk of discounting good candidates before they've had a chance to prove themselves properly.
Steps 1 and 2: Essay questions. I think this will tend to favor people who are good writers (including fiction writers). Essay-writing skills are orthogonal to technical skills and to personal interaction styles. The hiring company will deny itself access to people with personality types or cognitive styles that aren't characterized by good writing skills. It sounds as if the team spends a lot of time preparing the questions and then reviewing the submissions, when this activity probably contributes little to the ultimate decision.
Step 3: Behavioral interview. I think this is necessary, but should be brief. A whole morning is way too long, IMHO. You can't learn much about a candidate by talking, except in cases when they shoot themselves in the foot. When that happens, it usually happens very early in the conversation. In those cases, you need less time, not more time, to complete the interview.
Step 4. Pairing sessions. This is where we finally get to the "meat" of the audition. Everything else is prelude. People tend to become very good at whatever they practice the most. Many people are very good at interviewing. Often, it's because they get a lot of practice in interviews. And why would they need such practice...?
Darren Hale describes an interview process that includes a "hands-on programming exercise." Separately from the programming exercise, "[t]he process portion gets into philosophies on testing, problem solving, and pair programming, among other topics." I don't know Darren, and I might be mis-reading this, but it sounds as if there's still a heavy reliance on talking. Words can be misunderstood, but actions speak clearly. When a candidate pairs with team members on real work, their "philosophies" become apparent immediately. By doing a bit of role-playing while pairing with a candidate, team members can tease out the person's conflict resolution style and other details very quickly and directly.
It's quite easy (and often fun) to include elements that draw out the candidate's instinctive reactions to various situations. For example, mid-way through a pairing session, we can have two other team members go to a whiteboard to brainstorm design alternatives, and pretend to get into a circular debate. Then we can see what the candidate does. (It's important that the candidate not know the debate was staged. It has to be something that seems to happen organically in the team room environment.) Does he say something to his partner? Does he stand up and offer to mediate the discussion? Does he just keep his head down and continue working on the programming problem? Which would you prefer he do, when this sort of thing happens for real? (Not that developers ever get into circular design debates, of course.)
There are a lot of things we can do that are less elaborate than that, too. The coding exercise itself can have questionable design. Does the candidate discuss it? When his/her partner pushes back and argues in favor of the questionable design, what does the candidate do? What alternatives, if any, does the candidate suggest? How well does he/she defend those suggestions? You can get to the deep information faster and more accurately this way than by spending hours and hours asking clever interview questions. Auditions work well for programmers, testers, business analysts, and technical specialists such as DBAs and network engineers, and they don't intrude excessively on the team's time.
In my experience there's just no substitute for an audition. After pre-screening, which can be a 30 minute phone call, the "interview" portion of the filtering process can be as brief as, "Nice to meet you. Want some coffee or tea or something? OK. Here's the team room. Let me introduce you to a couple of the team members..."
Re: +100 regarding the
Re: +100 regarding the
Its about how your identity fits into the cumulative "identity" of the group.
Re: +100 regarding the "audition" approach
And yes, I agree that a multi-stage with "audition" is better that no audition, but I still fail to see what kind of audition would you have prepared for an outsider that may not be able to have any domain knowledge of the problem or may not even be able to legally have a peek into the codebase.
Besides, from the point of view of the prospect employee I would find very hard to commit the time for such long interviews while still working in another company.
Any experiences from the employee point of view?