CXO

Certifications: Make the best hire by asking questions

As a hiring manager, you're no doubt seeing more and more certifications on resumes these days. This article shows the most effective way to evaluate certifications.


Developers and other IT pros—faced with a flood of technologies, products, platforms, and application environments—are turning to certification as a strategy for learning and validating skill sets. Gaining hands-on experience in a diverse array of technologies is difficult, so many developers are pursuing certification to gain knowledge and expertise.

As a result, you are probably seeing more certifications listed on the resumes of job candidates you are interviewing. A resume that includes, for instance, certification in .NET alongside implementation experience in EDI is going to be attractive to a hiring manager. A Microsoft Certified Professional has a bit of an edge over a noncertified colleague of similar training and experience.

But should those certifications really give the candidate an edge? Asking the right questions during the interview process is the key, particularly when you get to the part of the resume on certifications.

How do you respond to certification?
I was well into my career before certification was really prevalent in the IT community. In those days, I had little sense of what certification really meant, and I initially took it for granted.

The first time certification became an issue occurred when I interviewed a young network guy who had recently been Novell-certified (which gives you some idea of how long ago this was). I noted the certification (he made sure I noted the certification) and we moved on. He ended up getting the job.

I mentioned the candidate's certification in the interview, but I didn't go deep enough. I assumed the certification signified that the candidate had adequate knowledge of the product and application process, and that he had a minimum of hands-on experience. You may be making a mistake if you assume that the needed skills are there.

This candidate had the skills to design, configure, implement, and test a standard LAN with a central server from scratch. But our job required more. We needed someone who could handle a peer-to-peer configuration with somewhat unorthodox customizations demanded by our need to mix and match exotic hardware. To the credit of the prep course he took, our new hire had read about such things—but that was it. He was basically starting from scratch.

The cost of the mistake was largely realized in a blown schedule. But I could have avoided the problem by asking specific questions about the certification and the candidate's real-world application of the knowledge.

Ask questions to reveal true expertise
Think about the other qualifications on a resume that prompt you to ask questions. When you note a candidate’s alma mater and the candidate is a recent graduate, you would probably ask about the computer science program at the school. You might ask: Did it have an applied business emphasis or a science-and-technology emphasis? What did they teach you about design? What were your lab projects like?

You ask these things, not because you don’t believe that a college degree reflects some minimum level of competence, but because you want to understand more about the distribution of that competence in your candidate. Was the candidate's education heavy on languages and light on analysis and design? Did the candidates do programming projects that were technology-oriented or application-oriented? Were the application problems bona fide business problems? These questions can make all the difference in characterizing exactly the type of training your candidate received during school.

Similarly, IT professionals receive certification from a number of sources, and test preparation from even more sources. The preparatory courses encompass a wide and varied range of topics, emphasizing or de-emphasizing various aspects of the product or technology in question. This range encompasses the obvious (concepts vs. application) and the not so obvious (standard implementations vs. special cases). So your candidate may or may not have had meaningful exposure to applied scenarios that served as adequate preparation for your particular environment. And there’s no way to determine this from the fact of certification alone; to truly know, you must ask.

How much do you need to know?
How important is the certified skill your candidate offers? Is it something that’s nice to have in-house or something you just can’t live without? Is the certified skill already on-site with some other team member, or will you rely primarily on the new hire? The answers to these questions will lead you to know how deeply you might want to probe into the details of the candidate’s knowledge and skill.

Details about the product or technology are not worth your time. It serves little purpose to give a pop quiz. What you want to ask about are the comprehensive things, such as what the candidate learned about troubleshooting the product or technology. Can the person describe some problem he or she was presented with in training? How was it solved? What strategy would the person use to solve problem X?

Consider also that many IT professionals seek certification well after they have achieved proficiency through real-world experience, rather than a training course. Their competence in a product or technology may not be so much a question of having taken courses and passed tests, but a matter of accumulated hands-on expertise authenticated by the certification process. Here, too, there’s no way to know but to push beyond the fact of certification and ask some focused, specific questions: What have you actually done? Tell me about it.

You should ask the types of probing questions you would ask if certifications were not listed on the resume. The surest way of knowing what a candidate can do is to know what the candidate has done. Certification doesn’t change that.

See the person through the training
Although you should respond to certification with focused inquiry, it is important to remember that eliciting detail about the candidate’s knowledge and experience is not an end in itself but a path to more important information. You want to know how much the person knows, certainly, but what you’re really after is to know what kind of thinker or problem-solver the person seems to be. Remember that, in this part of the interview, you’re interested in the details because they help you paint a picture of the candidate's potential.

 

About Scott Robinson

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

Editor's Picks

Free Newsletters, In your Inbox