Contibuted by Brenda Kalt, Development Tester, Publications Product Testing

I work in Publications, and I'm looking at “PROC CERTIFY;” from the other side of the mountain. In September I took the exam and passed it comfortably. I reviewed three nights before taking it (generally missing what I should have read and reading what wasn't on the test). I studied so little because I took the practice exam four months earlier and passed it comfortably. Cold. No review at all.

What happened?

I've been using SAS since 1980. In 1982 I was hired as a technical writer and quickly specialized in the DATA step and the SAS macro facility. (I also documented procedures when Publications was tiny.) Between 1987 and 1994, I wrote or peer-reviewed almost every word that came out of the Publications Base group regarding the DATA step and the macro facility. I was the DATA step guru in Pubs.

When I left technical writing in 1997 (to be an applications developer and then a tester), I knew that I knew base SAS. But time passes, and when I told people in recent years “Yes, I know the DATA step,” I wondered what they thought. Passing a public exam gave me a credential to back up the assertion.

What about the exam itself? Previous comments have implied that the exam was hard. Or easy. From my perspective, if I had taken a V6 certification exam in 1994, I probably would have thought it was easy. When I was using my knowledge daily I could have looked at a multiple-choice question and known the right answer. In 2009 I said “Probably D,” but I confirmed it by saying “It can't be A because of such-and-such; it can't be B because of something else; it can't be C because of another thing; so it's D.” That strategy took much more mental effort and more time than knowing the answers off the top of my head. I rechecked one answer and ended the exam with two minutes to spare.

(FYI, my weakest areas were the procedures and engines. I didn't work with them much either as a technical writer or as an applications developer. When I reviewed, I looked for the latest developments in the areas I knew and didn't realize I had blind spots.)

At a detailed level, the questions were well designed. I strongly compliment the people in the Education Division who created them. Each one required knowing several different facets of Base SAS. The wrong answers were plausible--something I understand is hard for experts to create because they've forgotten beginners' thought processes. Instructors in the Education Division hear beginners' mistakes every week.

The practice question that Stacey Hamilton posted about YEARCUTOFF= is realistic. Here's another sample (not an actual exam question, of course):

The setup showed a DATA step that contained various forms of KEEP and DROP plus some basic programming statements. The question was “How many variables will be in the output data set? A. 10 B. 11 C. 14 D. The step does not execute due to a syntax error.”

Hmm. A person who didn't understand the effect of placement on KEEP and DROP would count 14 variables. A person who thoroughly understood them would count 10. A person who read the code closely would also notice that one programming statement contained a misspelled variable name. The person would have to know how SAS creates variables to judge the effect of that error. If the misspelling didn't create a syntax error, were there syntax errors in any of the other programming statements?

When I first saw questions like this, I thought “Unfair! A trick question.” Then I realized, “No. People get jobs on the basis of the knowledge implied by Base SAS certification. A person who advertises him/herself as an expert in SAS programming has to work at this level.” SAS users, think of every irritating mistake you've ever made in using Base SAS, and know that you're responsible for spotting it in advance. You will be tested.

For me, having actively worked with Base SAS was the key to success. I personally could not have translated study into answering the questions in the time given. Those who can, I admire.

As an experiment, here's an exam-style exercise (without the multiple-choice answers).

Make a text file on your C: drive containing these book titles:

The Executioner's Song
A Short History of a Small Place
Angela's Ashes

Write a SAS program that puts them into a SAS data set and displays them in alphabetical order (the exam used PROC PRINT for display when it wasn't testing procedure knowledge). Run it. Look at the output. Are all the words in each title there? Are the titles in alphabetical order? So far so good, except that looking for The Executioner's Song under T isn't helpful. Now change the SAS program to print the complete titles in order by the first significant word.

There are several ways to do this, from brute-force to slick. All of them require reading from an external file, choosing the correct style of input, identifying the first significant word in the title, alphabetizing by it, and displaying the result--multiple elements of Base SAS software, as in a certification question. Running the example translates what you're studying into practical SAS programming. It also gives you feedback as to whether your code is correct. When you can do this without looking at the documentation, you are climbing PROC (no, MOUNT) CERTIFY.