Showing posts with label Joel Spolsky. Show all posts
Showing posts with label Joel Spolsky. Show all posts

Thursday, 23 February 2017

Agile Coach Interview And Selection Questions

Years ago I was hiring agile coaches, and working closely with a hiring partner who was really really (!) good at finding talent. I had no time, he had some time and was keen to help me in any way we could figure out how. I knew agile, he knew recruitment. I knew coaching, he knew people.

The first round questions that I designed then still hold true today. I was inspired by Joel Spolsky's 12 questions candidates should ask their potential employer before deciding to join back in 2000. It may be a little old in some circles by today's standards, but it is still insightful imho:

The Joel Test:
  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?
The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. And that's what I needed from my first round interview questions that anyone, even a non-agile-skilled or non-agile-knowledgeable person could use. So I came up with 24 quick questions, and we got some truly great candidates making it through the face-to-face screenings.
One of the most (perhaps THE MOST) important things about an agile coach is their experience. Money can't buy experience. Reading about other people's experiences, or attending courses based on other people's experiences is not the same as having the direct hands-on "did the best I could with the information and knowledge I had at the time, and nothing worked...until...after much persistence and many failures something worked!"

All experience is relevant. I am wincing at how arrogant I was when I was younger thinking that attitude mattered more than experience. They are equally important - it all depends on the problem space and time! The thing about people without experience in a particular space, is that they don't know what they don't know. My 24 questions highlighted things that were relevant for the different openings we had going at various times. A quick 10 minute Yes/No followed by a few initial typical HR availability, package suitability, location, role etc matching minutes and wallah - 1x effective initial screening for very cheap!

The very few who made it to face-to-face interviews which were experiential and enjoyable for both the coaches and the candidates highlighted the right candidates each time! Happy daze! (especially compared to traditional candidate screening processes and pains)

Rob's Agile Team Member or Agile Coach 24 Question Assessment:
  1. Do/did you use source control?
  2. Do/did you not use source control?
  3. Can/could you make a build in one step?
  4. Can/could you not make a build in one step?
  5. Do/did you make daily builds?
  6. Do/did you not make daily builds?
  7. Do/did you have a bug database?
  8. Do/did you not have a bug database?
  9. Do/did you fix bugs before writing new code?
  10. Do/did you not fix bugs before writing new code?
  11. Do/did you have an up-to-date schedule?
  12. Do/did you not have an up-to-date schedule?
  13. Do/did you have a spec?
  14. Do/did you not have a spec?
  15. Do/did programmers have quiet working conditions?
  16. Do/did programmes not have quiet working conditions?
  17. Do/did you use the best tools money can/could buy?
  18. Do/did you not have the best tools money can/could
  19. Do/did you have testers?
  20. Do/did you not have testers?
  21. Do/did new candidates write code during their interview?
  22. Do/did new candidates not write code during their interview?
  23. Do/did you do hallway usability testing?
  24. Do/did you not do hallway usability testing?
After you have all the "yes" and "no" responses to these, you will know the level of "modern" and "old" styles of developing and delivering software. Now you get to decide how to direct the rest of the experiential based interview if you decide to let the candidate through to face-to-face more investment round(s).

I advise experiential interviewing during the face-to-face as it is a case of "under stress, we regress", and a lot of coaching can be quite stressful as very little is under the control of the coach who is at best influencing the situation! And any coach who has not mastered conflict management and resolution skills, personal attacks, helping people overcome their own anxieties etc can be quite damaging to your organisation.

f you're more focused on a coach who's technical background is less interesting, you could take a look at the coaching levels and the types of coaching and design similar Yes/No questions to try and understand the tangible hands-on experiences a personal, executive, soft skills, etc coach has.

I suggest at the beginning of the face-to-faces to do some spot-checks to check that whatever Yes/No questions you screened with were correctly interpreted, and that the candidate's response was accurate before proceeding into the simulation(s). Some people, you know, will say anything to get a role! :O

After the simulation assessment(s), ensure you and your assessment team form and document your own, subjective, fact-based, Delphi-style, assessments of each candidate.

My final question for the candidates: Ask each candidate face-to-face what their opinion is of the other candidates. You'll be or not surprised how many candidates know, or know of, the other candidates, and their face-to-face opinions can be quite informative! Also insightful is how they react to those coaches they don't know or know of.

So hopefully by now you have collected all the minimal data points to make a more informed decision about finding the right candidate - a round peg for a round hole / a square peg for a square hole - for your people's (!!) needs. Remember, past performance is no guarantee about future performance. But also remember this is a critical role to match the right person to - as any change agent will by the nature of the role be disrupting people's comfort zone(s). Including your own often.

Good luck with your search and selection process!

Lastly, please let me know how it all works out for you and your organisation. Remember the most important (top) line of the Agile Manifesto reframed is a bit like "we're doing it, and by doing it we discover new and better ways of doing it, and we share with others what we have learned so that we all benefit". That's "agile"!

Thankyou for supporting!

A smarter SMART for even better collaborative Objectives (including OKRs)

My favourite coaching tools: SMART Acronym Another Update