I would have put this in the comments to Ethan’s post –but responding post to post is much more fun.
To begin, I must say I’m generally in agreement with Ethan’s main points on certifications and their ills –yes, you do have to maintain the cert. Yes, certifications tend to be one mechanism to drive market acceptance. And yes, you do need to learn about things you won’t ever use, or you won’t use on a regular basis.
But I wanted to spend a few moments thinking through this last concept a little. Now, let’s begin here: it’s easier to write a certification based on arcane bits of stuff that no-one really uses than to write a certification that counts. The E bit in type 1′s is always a fun and profitable topic to think about, right? But let’s be honest on the other side –there are two things that drive certifications into the arms of the arcane. The first of these is laziness, pure and simple, and for laziness there is no excuse. The second of these is cheating. Cheaters force you to refresh your question pool more regularly than you might otherwise, which leaves less time to write questions, and forces you into the arcane in the name of finding material to work from. But I don’t really want to focus on the reasons for arcane questions being on certification exams –I don’t really agree with being arcane for the sake of being arcane, although I understand the real world drivers behind building questions around bits of knowledge this way.
What I really want to talk about is another way of looking at one of Ethan’s specific complaints:
Well, sort of. In every certification track I’ve ever followed, I’ve found that you’ll learn stuff you won’t use. … Yes, it’s always great to be exposed to new information; that makes you a well-rounded network engineer. But in the context of certification, you’ve got to keep a handle on that information to keep the cert, and it’s tough if you’re not using it in real life.
Now, to give Ethan a break, he does talk about how important it is to exposed to new information –and that’s true!
But there’s another way to look at testing candidates on technologies that aren’t in common use (at least if the testing is done right). Let me start here: working in the networking industry always has been, is, and likely always will be, a matter of sipping from a fire hose. When I worked in TAC, in fact, our manager (Jeff Zirker) bought a huge crossword puzzle to hang on the wall in the area where we took cases. Along with that crossword was a book labeled, “the world’s largest book of clues.” Boy were we thankful for that book of clues — because I was often as clueless as the next person when working on something Cisco had released and hadn’t even bothered to tell us poor folks in the TAC about.
But the fire hose, being a reality, is something we need to learn to deal with. One question the writer of a certification exam needs to be able to ask is, “how does this candidate deal with the fire hose?” Yes, it’s too much information. No, you might not ever use it.
But you can use the skills you learn in dealing with the fire hose of a certification exam in your real life as a network engineer. You can learn to abstract, to dig under the bits and bytes to learn the theory, to learn how to infer and pick things up. You can learn to recognize that ATM LANE and LISP have many of the same characteristics, how many of the problems we struggled with in Frame Relay are going to apply to MPLS, that cloud is much like mainframes –and by making these associations (and understanding their limitations), you can learn to know the right questions to ask to address any new technology quickly and effectively.
In short, you can prove that you’ve learned to manage the fire hose, so you won’t be caught off guard by every new technology that comes along.
So no, certifications shouldn’t rely on arcane stuff “just to be hard.” At the same time, breadth is a good thing in more ways than one.