Certification

{

Jeff Atwood posted recently about certification, coming to the following conclusion:

"I don't believe in certifications. The certification alphabet is no substitute
for a solid portfolio; you should be spending your time building stuff, not
studying for multiple choice tests. But that doesn't mean they're worthless,
either. I don't think certifications get in the way, as long as you can
demonstrate an impressive body of work along with them. "

Many of the comments are the predictable reactions to certifications: they suck, people who obtain them don't know anything, they are self taught without certification, those who can't code obtain certifications and so on.

Reading a lot of the comments makes me want to add my own perspective to the fray, as cluttered as it is, because I'm the product of certifications. My own conclusion on certifications doesn't fall far from Atwood's, but because I was and am tied to that world, I reach it by a different means.

My background is what led me to certifications. My degree was in Accounting, and the only company that took a serious look at me in the technology world as I frantically tried to leave the public accounting firm I worked at required them. In fact, during my interview, my interviewer told me that I was one of several candidates who they were considering, and the first of us to obtain a certification would probably get the job. I didn't really know where to start - I had some sparse computer experience from building web pages and working in my university computer lab, but I was limited in doing practical things with computers. I went to my neighborhood bookstore and inspected the shelves, settling upon the biggest book I could find (assuming it had the most content) to study for the Microsoft Networking Essentials exam. I spent my lunch breaks at the accounting firm memorizing differnent network topographies, cables, and protocols.

I failed the exam on my first try, but this was not because I missed anything in the book. I was a fairly good student, and I literally memorized large portions of the book. Rather, I failed because I didn't know how the test would relate to the material I had learned. Once in the "certification game" I understood how people study for the exams (practice exams, looking at exam objectives) and how to look for "keywords" - things that give away the answer to the question.

For that basic networking exam, relating Novel any time I saw IPX/SPX was half the hard work in finding an answer to the question. For example:

Q. You have connected several Novel print servers to your Network but users complain that they do not work. What should you do?
A. Verify that IPX/SPX protocol or client is enabled.

I never failed another certification exam. Well, alright, I failed a VB 6 Enterprise Application Development exam because I'd had a wisdom tooth pulled the day before and was under the influence of painkillers, but I'll pretend that didn't happen.

As the exams got more elaborate, I learned it was very important to know how questions were asked (use practice exams) and where I was weak (exam objectives). The exam objectives would tell you which part of a product you were weak on. For example, I was never very good at answering deployment questions when taking developer exams. Not only was this somewhat difficult (and boring) to simulate, it wasn't something I needed to do very often living primarily in the world of web application development.

Now that I've had some distance in the certification world, my conclusion for people - especially developers - is that people who certify are responsible for learning how to answer questions. Although these questions may be related to their experiences, experience and knowledge are not a sure way of passing an exam. One needs to know how the questions work. Even on exams that involve simulations, understanding what will be needed is critical.

I certified on SQL Server many years ago - I don't remember the exact year - but it was during the SQL Server 7 days. I will probably take the new SQL Server exams but much of this is based on simulations - I know this because a coworker recently passed on of the exams and told me about it. The interesting thing is that I've used SQL Server every day for at least 5 years and prefer to live in TSQL for most of what I do. I'd have to spend some time getting comfortable with the GUI in order to take this exam, but it would not be related to my experience. Even more frustrating - my time looking at the GUI would just be learning to do things I already do.

In this sense I share the frustration that many people have about certifications: ability to answer quiz questions doesn't translate directly into the workings of day to day development. Many of the typical questions even if unknown would be about a 1 minute trip to Google or the documentation.

Here is my "but:" certifications force exposure for the people taking them. I know a lot more about deployment than I would have if I based what I knew on what I was inclined to learn on the job. I know a lot more about networking than most of the people I work with simply because I did have to learn it to be "certified." I'm sure some of my time without certifications would have been spent on personal projects or readings of personal interest, but without discipline some of that reading is of only general benefit. And because certification objectives are very practical (if not boring) they usually result in knowledge that is more focused.

I had a friend who was largely self taught and extremely intelligent. His personal study took him into the world of C++ where he excelled, preferring to spend his time studying Open GL libraries. It's interesting stuff, to be sure, but it's not MFC or the Win32 API. As a result he could make a lot of cool demos, but he wasn't the type of person to write a banking application. He wasn't particularly interested in that but as a thought experiment what if he'd decided to endure some of the boredome and learn how to write MFC with database connectivity? Certification would have forced that exposure which, combined with his aptitude, would have made him quite a developer.

One final note before I give my own conclusion - similar to Atwood's but different enough that I felt compelled to write this. Atwood posts a comment from an older article on certifiction:

I suggest that we have a perfectly fine selection mechanism at work today;
it's called the market. Some people get hired as software developers and some
people don't. It is a lot more competent than any appointed elite would be and a
lot more ethical.

I recently realized that there is a little bit more economic activity in certification, not necessarily on the side of the big companies that sponsor them. Many people who have certification use it as a tool to restrict supply and drive up their own "value." For example, many Microsoft trainers are eager to have Microsoft require a "premier certification" in order to teach their coursework. The argument they use officially is that it will ensure that the trainer delivering content is knowledgable but the intersting facet of this argument is that obtaining and maintaining "premier certifications" (many of which have multiple exams) requires considerable effort (and massive opportunity cost - instead of learning the new GUI of SQL Server 2005 a person could be writing, say, a stored procedure generator using SMO). It leads me to believe that most of them know that increasing the amount of time and effort for certification is in the interests of their pockets as much as it keeps people "knowledgeable." I also observe this pattern in my own certification life: when I'm doing project work, which is usually intense and requires a lot of my off hours, I'm never certifying. When I'm between jobs, or if I'm asked to teach a class or do something that requires certification, I sit down and do what's necessary.

So my big conculsion? Everyone has a story of the MCSE who never installed Windows or the "certified" guy who had no practical experience. A lot of the time it's people like me - not disciplined in the work of computers and trying to put something on a resume. In that sense I don't disagree that a certification all by itself is meaningful. I defer to Atwood's comments about showing work that's been done and a track record of personal effort.

But.

Certifications in addition to a person's track record are a good thing to take into consideration. Not only do they show a person putting in some effort beyond work related requirements, it also means they've got some exposure (knowledge-wise) to areas of a technology outside of the context of immediate use.

In the end my apology is biased because I do have certifications. But there's a value to them that most people miss because they have had bad experiences with people that abuse them or try to compensate real experience and/or projects with them.

I'll continue to get certifications as a part of work related requests but I'll never get them again in the context I started with: a guy who loved computers and was trying to get a job and demonstrate to people effort and a little bit of knowledge. As I interview people and present myself I'll present my certifications as that original effort, not necessarily where I am now. I've got projects (day and night) to try to assert my credibility.

}