I’ve led and been part of agile development teams for over a decade – and have been hiring developers for even longer. Through both types of experiences I’ve been able to apply agile development ideas to IT recruiting, interviewing and screening high quality tech candidates. And now, I’d like to pass that experience along.
Let’s talk about agile programming
My introduction to agile programming was from Kent Beck’s eXtreme Programming books. If you haven’t read them, his core idea was that software development needs to embrace change, and he suggests that there are certain practices that are so helpful in the face of change, that they should be used in the extreme. Beck based his work on best practices, but many readers saw the ideas of pair-programming, unit-testing, simple designs, refactoring and continuous integration for the first time in his books.
Creating an agile IT recruiting process
Just like in programming, it’s important to be agile throughout the recruitment process. So, to follow Beck’s lead, I took a look at what was working in my personal recruiting process and tried to figure out how to increase its effectiveness by doing more of it.
In programming, the point of being agile is to react to change, but in recruiting, the point of being agile is to see more candidates. Rather than rushing towards filtering and only deeply interviewing a few candidates, I tried to figure out a quick way to get to know as many candidates as possible.
I looked at how to get better at understanding resumes, tech interviewing and assessing both and hard skills.
The resume
Years ago, I noticed that resume screening was completely broken, and that I had a much better chance of judging an application with a short conversation. Eventually, I took this to the extreme, and I now try to talk to as many candidates as I can. I set the expectation that the conversations are meant to be short and we spend the time clarifying their resume so that I make sure I understand their application. Doing this gives me a much better chance of picking the right candidates to move forward with.
The interview
Another thing I noticed was that candidates that knew what to expect in the technical interview were much less nervous and more likely to do their best. So, in the spirit of extreme transparency, during that initial conversation I tell candidates exactly what my technical interview is like (the format, not the questions). We talk about how much programming they are doing right now, and I caution them that it’s hard to tell the difference between a rusty programmer and one that doesn’t know the answer.
I have two goals when I do this:
- There are some developers that apply to programming jobs they aren’t ready for. If that’s the case, they might realize it and withdraw their application or talk to me about it.
- There are a lot of good developers that might not be programming every day right now, but could and want to. I recommend that they take a week to get back up to speed. I know that they can’t learn how to program in this time, but they can make sure that nervousness isn’t a factor.
I’ve even offered to do a no-stakes practice question so that they could see what the interview would be like. In the end, I don’t want to reject a candidate because of the interview process. I think of an applicant failing the technical interview as a failure on me to prepare them properly.
Have they done their research?
My last extreme practice relates to my belief that being able to do research is one of the most important skills a developer can have. So, I have posted, under my real name in many places, the kinds of questions I ask on interviews. I fully expect and hope that candidates will either Google me or the companies I have worked for. If they do, they’ll learn a lot, and they may even land the job.
Comments are closed.