Certification alphabet soup
Published: 07/17/2010
Until relatively recently in my career, I never bothered with certifications. Sure, I read quite a few books over the years to improve my understanding of the technologies I use daily, but I didn't see the immediate benefit of passing all the tests and splashing acronyms on my business card like a lot of people do. In other words, I didn't want to end up being another paper-certified professional. We've all met them - a lot of talk, sometimes no walk. I've interviewed job candidates who had the alphabet soup all over their resume, and many of them didn't live up to the hype.
When I did occasionally entertain the idea of studying for a cert, I discovered that I would have to spend effort learning certain subject areas which weren't directly relevant to my job at the time (for example, Remote Installation Services in Microsoft networks). I was mostly interested in being able to apply the most immediately relevant solution. Practical preferred over theory.
But that said, over time I started realizing that as my job requires me to do a little bit of everything, my skill set has become diluted, I identified quite a few knowledge gaps, and my previous mindset was hindering my ability to improvise and devise creative solutions at work. It's uncomfortable to lack a clear picture of how things tie together. Over the course of my career, I've learned my craft mostly through self-study and hands-on trial-and-error. However, sometimes it's nice to go the formal route and take the official curriculum to pick up all the basics.
So lately after having studied for and taken a number of these exams to assess / qualify my knowledge, I've found the experience rewarding in its own way as I've discovered new things that I should have known long ago ... but my opinion of the certification world hasn't changed that much overall. Although I have certainly filled some gaps and gained more technical insight (some of which I feel were very worthwhile), I still believe that certifications != competency. Being awarded a four-letter acronym is a starting point to dig deeper from an elevated appetite, but that's all. There's a lot more in a production environment than what the textbook reveals.
Some exams are better than others, and some course material more practical, yet I still think the certification process(es) could be more stringent. For starters, I'm not a big fan of technical exams that are completely composed of multiple-choice questions. There's a place for a such system, but if it's a certification where you're supposed to know the actual commands, etc., it would seem to make sense that there would be a lot of simulations involved rather than mostly clicking on a few check boxes. At work, we set up hardware, configure the software, troubleshoot environments using tools, and make decisions based on a several variables in a given scenario. Multiple choice systems only test us so much in this regard.
One aspect of these exams is the skill of interpreting the questions correctly. Sometimes they're either ambiguous or misleading due to bad wording (as opposed intentionally misleading to ensure you can figure out the "best" answer). I've come across a few such questions which could be interpreted in more than one way. While we encounter situations in the real world which require extra thought for accurate interpretation, when you're being tested on it with only one possible answer, it's not always representative of what happens on the job.
So here's what I've learned so far in my pursuit of the alphabet soup:
1) The exams don't always measure up to the difficulty and / or broadness of the subject material. I've sat exams where I didn't feel well-prepared for, yet I passed easily. Perhaps I was just lucky because I could guess my way through multiple-choice questions. Or more likely I happened to get the easy questions out of the test pool. I really doubt it's because I'm smart.
2) Just because a vendor emphasizes their Kool Aid doesn't mean that's how it's really done in the real world where reality rears its head against the textbook statements of, "Best practices dictate..." Well, yeah, in that vendor's own little utopia, perhaps.
3) Regardless of what test you pass, if you don't use it, you'll probably lose it. I've learned material which isn't applicable for my environment at work. Some of those details are going to evaporate if I don't use it often enough.
4) These tests should be a lot harder. If you're not really familiar with the material, you should be sweating hard. If you've got it all down, it should feel like a hard day at work - stressful, but manageable. I would give higher respect to certifications (and thus certified professionals) who endure such examinations.
Egos and bragging rights aside, I know a lot of people out there have good reasons to achieve certification: meet the minimum baseline for perceived technical competency, have resumes that corporate HR can easily match against the job description, to qualify your employer for certain vendor requirements, meet quarterly bonus goals, and ultimately be more effective on the job.
But to me, being certified just means that the individual somehow managed to pass a test at some point in time. It provides a glimpse regarding the person's potential in a given position.
Let's keep things in perspective and just be careful to not give too much credit to the alphabet soup. There are some really sharp non-certified individuals out there who can get the job done ... and then some.
Go back to my list of rambles.