The Employee View of Agile Interviews

I found two interesting blog posts via Twitter, http://blog.thirstybear.co.uk/2010/02/don-just-interview-new-developers_03.html and http://www.davenicolette.net/agile/index.blog/1947137/the-new-interview/ both covering a new and perhaps more agile (hey! buzzword!) way of doing interviews. The key point is to audition the candidate rather than to just ask questions. Doing actual pair programming and seeing how people how actually work to solve a concrete programming tasks is much more valuable than to give them a random task, ask if they remember some obscure part of a spec everybody looks up anyway or not least, see what certifications they have. Would you like to work for a company that put more faith in your certifications than your current abilities?

Both posts cover this from the viewpoint of the potential employer but I can see just as much value for the employee. When interviewing for a new job you rarely get an accurate view of how the company really is through the interview. The reality really dawns on you a couple of months into the job. My (somewhat limited) experience with interviews is that they are very rarely used to dig deep enough, both from the standpoint of the employer and the employee. But we should! Hiring the wrong people is expensive for the company and choosing to work for the wrong company is just waste of time for an employee. Or worse.

The Questions to Ask

If I where to look for a new job I would milk the interview for all it's worth and use it to see what kind of company I'm dealing with.

• If they're not doing pair programming in the interview, will they do it in real life?
• How serious are they about their agility?
• Do they check what I remember or do they make an effort to find out how I work?
• Are they interested in the buzzwords I know or the process I use to develop software and solve problems?
• Are they interested in finding out about the real me?
• If at all possible: pair program with the people I'm going to be working with

I would perhaps even go as far as asking them why they're are hiring they way they are, regardless of how, and use the answer to decipher their way of thinking about people and the craft of software development. I mean: would you choose to work for a company which isn't really interested in finding out the real you but rather just hire the résumé you?

Some other questions I would consider asking to find out more about the company:

• What kind of computer hardware and software are developers using (this can seem like useless geek obsessions, but it tells me something about how they value the productivity of their developers. Best answer: you get to choose :-))
• How does the company (top to bottom) ensure continuous improvement?
• How does the company measure the productivity of their developers? (trick question).
• How far up the management chain does the agile principles really go? Think Toyota Production System-like environment.
• For a consulting firm: how much/often do you spend time inside the mother ship opposed to on-site at clients?

The Time it Takes

Doing interviews in this fashion takes time and I have heard stories (at Hashrocket I think) of week long pair programming sessions with the entire team and one "no" from one team member is all it takes to turn down the candidate. This probably works better in the US with their system of two weeks notice, but not so well in Norway with (normally) three months mutual notice. But for sure: one hour of questions doesn't tell you enough. Practice trumps talking, talking trumps résumés - to paraphrase the kanban saying.