Over the years I’ve been primary a skills interviewer. In theory I know what skills are needed and in theory I want to hire someone that can do a hundred percent of those on day one. The other technique is aptitude hiring – asking questions that can reveal the interest and ability to learn new skills quickly. Typically this is used when you can’t find the find the match you want on the skills, but it’s also common when you want to move someone within the organization into a new role, or if you just want to ‘build your own’ from scratch – perhaps an intern or recent college graduate.
Aptitude is often the most frustrating part for the candidate. They know they can learn almost anything, why can’t you hire them? In a lot of cases you will agree with the aptitude, but you need someone that can provide some value on day one. It’s the ‘how do I become a DBA’ conversation (or how to become most anything else) that we struggle with as an industry.
If you think about it some, most hires are rarely all of one method or the other. Maybe you need someone that can do SSIS and clustering, but you find candidates that have only one of the two skills. You think about the candidates, think about the ‘real’ daily work, think about which skill is harder to learn, and then you hire for skills plus aptitude.
Looking back I think I’ve long understand the value of looking for a subset of skills plus aptitude. In general I start with skills to try to find a perfect match, if I can’t find perfect then I start factoring in aptitude, all the way own to hiring someone with zero skill and what I think is 100% aptitude. I think I probably try too hard to match skills, yet I struggle to think why that is bad. Why wouldn’t I go for the perfect match to start with, all things being equal? I need to think on that.
Over the years I’ve seen aptitude hires do well. I hired a Java developer to do .Net work and in months he was as good or better than anyone I had on the team – he just had to map the concepts and libraries in his head. I’ve trained Oracle DBA’s to do SQL Server and it’s the same, mapping concepts (to be fair, it’s easier to go from Oracle to SQL than vice versa due to the great tools we have). I’ve also lived it, being hired for aptitude over skills more than once, including my very first job as a SQL Server DBA.
Some questions you might ask/think about:
- What is the most recent skill they learned on their own? How did they learn it? How long did it take?
- Do they seem experienced and confident enough to survive not being 100% capable on day one?
- Of the skills they don’t have which are most important and how long would you expect it to take someone to learn them?
- Are you willing to invest money in training for them? Willing to live with the less than full productivity for some amount of time (probably months or more)?
- Will your boss support an aptitude hire? Will your team? Your customers?
- Can you structure the hire in such a way that you don’t end up with someone that never quite gets to where you need them to be? Contract to hire is a good option. Reduced salary with a raise/promotion based on some list of learning might be an option too.
Interviewing and hiring is never easy, but evaluating candidates on skills and experience as you interview may give you better options when you get to the point of making a decision.
One thought on “Interview Candidates for Skills, Aptitude, Maybe Both”
I read your article on Sql Server Central and it is a good one. One thing you might want to fix:
“Looking back I think I’ve long understand the value of looking for a subset of skills plus aptitude.”
I think you want “understood” in this sentence.
Thanks for posting it. As a manager who occasionally gets the opportunity to hire new staff, this is a well-rounded bit of advice.
Comments are closed.