Why I Support Certifications

I’m betting that I could take my certifications off my resume and still have a fair chance at finding a job. It’s a guess, of course, and I’ve never tried any sort of an experiment towards finding out, but the point is this: at some point in your career, certifications should become just one more thing on an excellent resume, rather than the focal point of your resume. Given this, why do I still support certifications? To answer this question, I need to back up into the certification development process a bit.

One of the strangest “mind trips” I’ve ever encountered was working with the “psycho’s” (psychometricians, really, but you know how engineers are with long words) through the entire CCDE/CCAr process. The two things we were challenged constantly were:

• What does the minimally qualified candidate look like?
• How do you intend to test for that skill?

Both of these are hard questions.

The first question we turned into a simpler one (again, you know how engineers are): Why do I care? When someone would suggest a particular question or skill, they were immediately met with the counter — Do I care? If I were a designer working on a project, and someone handed me that piece of information, would I care? If the answer was “no,” the question was canned, and we moved on.

The second question is even harder. Think through the fundamental skills a designer needs in the real world — things like the ability to abstract, to ask questions, to consider the alternatives, to manage information overload, and to find relationships between different data points. Now think about how you could test each one. There’s no easy answer for any of these. In fact, I’ve been told that you can’t test for design because these skills are too hard to test for.

But you can test for some of them.

You can’t (really) test a soldier in boot camp for bravery, and you can’t (really) test a doctor in medical school for compassion. That doesn’t mean you don’t test soldiers and doctors, it just means you need to learn the limits of what you can and can’t test — and focus on the things you can test.

To return to the example of the CCDE, one thing it is possible to test is the candidate’s ability to make connections between information scattered in different documents and presented for different reasons. You can break the information needed to answer a single question apart into multiple pieces — like cutting a picture into a jigsaw puzzle — and then putting each piece in a different context. Then you ask the original question and see if the candidate can figure out the answer. To make things harder — to make certain they’ve really grocked the answer, rather than just sniffing out based on best common practices, or they’re just lucky — you can ask them why they gave the answer they did.

This is precisely what the two part “branching” question type in the CCDE was designed to do. First ask “what,” which makes certain the candidate has a clue about what technology or solution fits a particular situation. The situation isn’t always presented “cleanly,” but is often broken apart like the pieces of a jigsaw puzzle, scattered throughout the documentation. Once they have the “what,” right, then you ask them “why.” This is actually the harder part of the two part question, because it’s effectively asking the candidate to show they’ve integrated the information that drove them to the correct “what.” This type of series is what makes the CCDE so difficult.

Given this background, let’s return to the question. Why do I support certifications?

It’s not because I believe they are the ultimate measure of engineering skills — any certification is only going to test to the minimally qualified candidate. It’s not because I believe they encompass the total skill set needed to be a good engineer — there are clear limits on what you can test.

It’s actually because I believe the certification process gives people a motivation to learn, process, and practice at least some of skills they need to be a good engineer.

For engineers without twenty years of experience on their resume, a certification is “good practice for the world.” It’s not the real world, even though one of the differentiators of expert level certifications is they often try to make it as close as possible to the real world. But practice is still good.

For engineers with some level of experience in a single environment, it’s good to broaden skills to a baseline across a wider range of technologies and ideas. Almost every engineer works in a particular environment where specific skills are used over and over again, and other skills atrophy. Certification is a chance to exercise a broad set of skills a team of people with a lot more exposure have decided is a “minimal set.”

The bottom line is this, then — I support certifications because I think they’re good for the industry at large and good for individual engineers. They’re not the end all/be all of knowledge, they will not guarantee you a job, they will not guarantee a “good hire.” But they are a useful part of the industry at large, giving people a broader target than they might experience on a day-to-day basis, and adding some measure of professionalism to the process.

In other words, I see certifications as a way for engineers with deeper knowledge and experience (that’s a nice way of saying “old fogies”) to help mentor and guide younger engineers on a mass scale.

This is the first of a two part series; next week I will talk about the ugly side of certifications.