A few posts ago I talked about competency versus capability and recently I've seen a few posts supporting my assertion that the "tick in the box" approach to hiring isn't going to guarantee you get capable people.
Dan Creswell posted a great article in response to the job ad for a Senior Research Engineer at Amazon.
So often I see companies create job specs for engineers where the key requirement is to hire someone who can hit the deck coding like mad using whatever tools have been selected. To that end they load the specs up with endless tech hubris and at interview ask the details of this or that bit of syntax or API call.
Frank Wiles continued the theme in his post on "A Guide to Hiring Programmers" where he identified
You don't need to hire an expert in language X, you can and should look for expert programmers that are willing to learn language X. An expert can easily cross over from being a novice in any language in a matter of a few weeks.
If you are hiring solely on technical skills then, as Dan Creswell asks, "what about the next project within the company where the tech is different?". This is where capability wins over competence for me.
Having ways to judge the capability of potential hires in the interview process is crucial to successfully hiring people who can grow and evolve with your business. Ideally you don't want to have to hire a complete set of new developers if you change technology. The current ones know your business and will appreciate the opportunity to develop new skills, thus adding to company loyalty and retention.
At Ephox, as part of our recruitment process, we have people undertake a coding exercise. This is a very simple program that the candidate can do at their leisure to allow them to fit it into their current commitments. Most importantly we allow them to develop it in their preferred language and tools. Once it's submitted back to us and reviewed by senior engineers, we invited the candidate back for a frank discussion on their thinking during the development process.
What are we trying to achieve? We are looking for how they approach problems and how they interact in a technical discussion. Basically all the things that indicate their capability for the role versus their proficiency with a particular technology stack.
We've already seen this approach work with our last hire. Suneth had only basic Java skills prior to joining us but when we evaluated his ability we could see the potential and an eagerness to learn more. In the 12 months since Suneth joined us his skills in Java have increased immensely.
How do others evaluate the capabilities of their candidates during the interview process?
