Archive for August, 2006
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.
August 31st, 2006
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.
August 30th, 2006
A few weeks ago at the “Hiring for an Agile Team” session, the group generated a number of behavior-description questions. I promised I would post them, so here they are:
- “Tell me about a time you made a mistake.”
- Using the context of shipping/releasing a product late: “What did you change?” (Notice the past tense of “did.” When interviewing for an agile team, the group expected that the candidate would take some initiative for change. And, by using the word “did,” the candidate is less likely to take this as a hypothetical question.)
- “Tell me about a time you/your team changed course.”
- “Tell me about a time you performed another role on a project.” (looking for people who are comfortable roaming around a team, doing what needs to be done.)
- “Tell me about a time you worked with people on their projects.” (Looking for people who can coach.)
- “Tell me about a time you made a difference.”
- “Tell me about a time your daily priorities changed.”
There were tons of other great questions. If you participated in that session (or even if not!) and you have some questions you have found have helped you looking for people to fit into an Agile team, please leave a comment here.
August 14th, 2006
I received some great comments on Why Puzzles and Riddles Discriminate. Adam has a terrific list of the things he’s looking for when he uses “puzzles and/or brainteasers and/or random programs to test”:
- Do they give up right off the bat?
- Do they ask questions or sit silent pondering?
- Do they make different attempts or approaches?
- What areas (if any) do they get stuck on?
- Can they explain what they are thinking? If yes - great. If no - what’s the reason?
And, Craig and Eric disagree with my original post. I may not be able to convince Craig and Eric, but let me use Adam’s list and explain how the answers might be different when the interviewer uses a puzzle/riddle vs. using an audition.In the interview, the context is key to seeing how a person succeeds at work. If the context of the interview is congruent with the workplace, the interview can be a reasonable representative of how the person will interact with people at work. But if the context of the interview is different from the work, the kinds of questions and auditions are less likely to be useful.
I was working with a hiring manager and the interviewing team recently who liked giving what they called “technical puzzles” to candidates. But they’d had several problems recently: two recent hires quit, and one candidate walked out in the middle of the interview. I asked what they were doing for these technical puzzles, and was told they had several–and all of them were about developing a recursive algorithm. The problem was these folks didn’t do any recursion at all. In fact, they had a huge data transformation application, so the context of the interview didn’t match the context of the job. Once new hires realized they’d made a mistake, they reactivated their job search and left. And one candidate didn’t bother waiting until the end of the interview. He’d flipped the bozo bit on the interviewing team.
At another client, the interviewing team liked word riddles. The team traded off who got to ask the puzzle/riddle question during the interview. (That team had 5 people, each of whom had a different puzzle/riddle.) Because the interviewing team were not great at asking behavior-description questions or using real auditions, they missed bunch of people who were hired by other managers in the company (the new hires were successful). I was able to talk to the new hires and ask them questions to understand what the interviewing team was missing. Several of the new hires misunderstood the logic puzzle because English wasn’t their first language, and they didn’t hear the puzzle correctly. Two of the new hires decided that if that’s how the team evaluated potential candidates, they didn’t want to work with that team. And one of the new hires had attempted to explain why there was more than one solution to the riddle, but the interviewer couldn’t hear that.You might say that this interviewing team was able to hire into their culture, and you’d be partly right 
But in contrast to their interview questions, this team actually had a culture of looking into a problem several ways, debating how to do things, prototyping to see what solutions could look like–a much more collaborative way of working than their puzzle/riddle questions probed. The interviewing team shortchanged themselves by not asking questions/doing auditions that reflected the way they actually worked.
You’ve probably noted I haven’t addressed the discrimination issue here. No one would talk to me about that, because they were afraid (both the new employees and the interviewing teams) that I would be forced to go to a lawyer if I had data that said they were discriminating. But I did notice that in my clients’ large North American cities, those clients who rely heavily on puzzles and riddles have primarily-white, primarily male staffs (this is in contrast to other organizations who have much more diversity). I understand about the problem attracting women to the field in general (see MusingsonWomenandIt. But I could not understand the lack of Asians and other people who aren’t white.Our choices of questions that are not directly related to the job (and no matter how you slice it, puzzles and riddles are only indirectly related to the job) reflect our culture. It’s quite clear that the puzzles and riddles interviewers choose reflect their individual culture. And without meaning to, that culture primarily selects for people just like themselves.I do want to ask questions or observe behaviors similar to Aaron’s questions. But I want to see them in the context of what people do at work, specifically work in this organization. So I want to make all my questions and auditions as context-sensitive as I can. I want to know that candidates will succeed here, in this context.
August 9th, 2006
I’m very pleased to be speaking at another Kennedy Audio Conference. See information at Building a Hiring Strategy.You’ve noticed that I’ve been blogging about some of the hiring strategies. Well, there are 12 strategies that I’ve noticed, and I won’t blog about the rest until after the audio conference. I do hope you join me.
August 7th, 2006
I’ve been using Bloglet for email subscribers. Today, I decided it was time to move on to Feedblitz. If you subscribe via email, you should received this posting (and all other future postings).
August 7th, 2006
At last week’s Agile 2006 conference, I led a tutorial called “Hiring for an Agile Team.” I made a statement that some of the participants challenged:
Using puzzles and riddles discriminate against anyone who isn’t a (middle-upper class) white American suburban male.
(I’d forgotten the middle-upper class part when I was leading the session.) So, what everyone wants to know is: Where is my data?
First, let me explain why I said this. (This post is a bit of a rant.)
- Girls, for example, do not have access or the alone time to spend doing books of puzzles and riddles. It is socially unacceptable for even the geekiest girl you know to do this. A girl who spends time pursuing puzzles and riddles for her own pleasure runs the colossal risk of being ostracized from all the other girls. Boys tend to discover puzzles and riddles during middle school and continue to pursue them through high school. Middle and high school for girls is much more about social ability and social connections.
- The people who can afford to buy the puzzle and riddle books (to practice them and become better at them) are middle-to-upper economic class.
- Puzzles and riddles appeal to a limited number of personality types–types frequently found in high-tech jobs. In particular, they appeal most often to NTs, especially INTJ and INTP types. (NTs are visionaries in Do Your Interview Questions Discriminate For or Against Your Needs?
So, the people who practice with puzzles and riddles are the people who have the disposable income, time, and social acceptability to do so. I don’t know enough about middle class high school boys from other cultures, but I see this all the time in the US.If you’d like to see some other information, take a look at How Would You Move Mount Fuji?. There are some hints at the articles at Career Resource Center but no reference. I also wrote Brainteaser Interviews Showcase Lack of Interviewer Skill, not Candidate Expertise. And, take a look at Brainteasers Inappropriate for Job Interviews by John Kador, who literally wrote the book.
So, have I convinced you yet? Maybe not. Maybe you still think you need a way to know if this candidate is smart enough for you, or you don’t feel competent to start a conversation with something like a puzzle or a riddle to dissect.If you need to know whether a person is smart enough, use behavior-description questions and auditions. Don’t be afraid to ask the “What did you learn from that experience” question as a follow up from your behavior-description questions. If you need people who are smarter than the people we normally have in our field, use the job analysis to understand why. (I bet you don’t, but that’s another rant.)If you need a conversation starter, I have some ideas on building rapport already in this blog, but I’ll write another piece about building rapport. Tongue-in-cheek: Really, if you’d been socializing in high school instead of using puzzles and riddles to avoid social interactions, you might already know how to do this.
Joel discusses ways to really interview in The Guerrilla Guide to Interviewing and he discusses auditions in The Perils of JavaSchools. So, if you’re looking for real discrimination data, sorry, I don’t have it. I only have my common sense.
Remember, the goal of an interview is to evaluate how well a candidate will do at work, specifically in your workplace. Puzzles and riddles may evaluate a certain kind of personality, and possibly even raw IQ. But they won’t tell you how well a candidate can work with your group or on your products. And that’s the point of an interview.
August 2nd, 2006
Last week at the Agile conference, a participant in my “Hiring for an Agile Team” session asked how to know if the people she was interviewing–who had no experience as part of an agile team–might actually work in the team. As she said, “I can’t wait for the perfect person. I can train, but I need people who are capable of doing the work even if they haven’t done it before.”
Drum roll, please. This is exactly why auditions are a necessary part of your interviewing toolbox. I suggested that she first define the behaviors she needed to see. In this case, it’s the ability to do test-driven development. I suggested she explain test-driven development. I also suggested that during the phone screen or emails setting up the interview that she point candidates to articles she particularly likes about test-driven development. (I suggested she consider testdriven.com or Keith Ray’s blog.) Now the candidate knows to expect an audition, even if it’s something the candidate hasn’t done before.
During the interview, ask the candidate to design something–something similar to your product is best, but you can use an open source product, or even something like a factorial function. The key is to explain that you’ll check in every five minutes to see how the candidate is doing. When you check in, ask to see the tests and the code. Say, “Thank you, I’ll check back later” and walk away. As you check in, you can see if the just the code is growing, or if the tests and the code are growing together.
Not everyone can teach him or herself test-driven development. The key with this audition is to look for forward progress, not perfection. In my opinion, this audition is better than a hypothetical question.And, in case you’re wondering, no, I suggested a whole bunch of questions she could ask too, about ability to learn skills and adaptability. But I suspect that starting with this kind of an audition will help clarify whether the candidate could do the work at all. Always a useful thing to know.
August 1st, 2006