Certification Caveats

There's lots of organizations and company's that offer "certification"–either on their own products/processes or someone else's. They'll all try to tell you the virtues of their certification. But, despite their claims, certification isn't a panacea. Let's look at some caveats of certification.

The biggest area I've seen is what "certification" means. "Certified" as what, or able to do what? Really, certification only certifies that the person can and has taken an exam. Let's look at software development for a moment. I'm never going to hire someone whose sole purpose will be to take that exam. There's the possibility that they used their knowledge and experience to pass the exam; but the exam itself cannot gauge that. There's a certain amount of faith that needs to be put into that certification.

This leads to the next biggest problem of "certifications": the people who either memorized the answers or only studied exam questions. These people, at worst, posses only enough knowledge on the technology under certification to pass the test. It's highly unlikely that anyone with just that knowledge is going to be any use to me. All joking aside, I have seen people pass certification exams doing only this. I've worked with "certified" peers, "engineers", "PhD's", etc. that were effectively dysfunctional and ended up being more a burden than a benefit to the team and the project.

This raises the question, what should I be expecting from certifications? Certification alone tells you nothing. In conjunction with experience and empirical evidence that you yourself have verified about a candidate, certifications can be information that can tell you something more about a candidate; but, rarely should be a mandatory requirement for hire.

Okay, so if certifications are not a panacea, then how do i make them useful? Well, for one, make them a "nice to have". At face value they alone can't tell you a candidate meets your criteria. This assumes, of course, you have criteria and it's more than just "passed certification exam". So, to get value from whether or not someone is certified, you need to know what this candidate will be doing for you and how to judge her work. If you cannot answer either of those two questions, whether or not someone is certified does you no good. Okay, so you do know what you need this candidate to do and come up with some valid business-driven criteria to judge their work once hired… Is there anything about the certification that would help you verify the candidates work once hired? e.g. I need to hire someone to write a Windows Phone 7 application. There isn't a huge pool of resources with loads of experience developing for WP7. Certification in Windows Phone 7 and experience developing Silverlight or WPF applications would give me the qualitative criteria to make a judgement call over another candidate.

There are circumstances where the certification itself can be the only criteria. I would argue that it's fairly rare; but, when new technologies come out and there are simply no one with any quantifiable experience with a technology, certifications can be useful. It's rare in the software industry you want someone simply for their knowledge in one particular technology. Most of the time you're looking more for someone who has other more general attributes like problem solving, ability to learn, works well under pressure, team player, bleah, bleah, bleah. My point is, that if they posses none of those other qualities, whether they passed a certification exam is meaningless to you–the candidate is simply unacceptable before even getting to the fact they're certified. I would also argue that you need to perform some sort of due diligence and either learn about the technology you hope to hire someone for or get cheat sheet—expecting a certification to be a replacement for that is only going to cause you disappointment.