You can go into a SAS interview with more confidence if you know that you are prepared to respond to the kind of technical questions that an interviewer might ask you. I do not provide the specific answers here, both because these questions can be asked in a variety of ways and because it is not my objective to help those who have little actual interest in SAS to bluff their way through a SAS technical interview. The discussion here, though, may give you an idea of whether you have fully considered the implications contained in the questions.
A SAS technical interview typically starts with a few of the key concepts that are essential in SAS programming. These questions are intended to separate those who have actual substantive experience with SAS from those who have used in only a very limited or superficial way. If you have spent more than a hundred hours reading and writing SAS programs, it is safe to assume that you are familiar with topics such as these:
After the interviewer is satisfied that you have used SAS to do a variety of things, you are likely to get some more substantial questions about SAS processing. These questions typically focus on some of the trickier aspects of the way SAS works, not because the interviewer is trying to trick you, but to give you a chance to demonstrate your knowledge of the details of SAS processing. At the same time, you can show how you approach technical questions and issues, and that is ultimately more important than your knowledge of any specific feature in SAS.
The processing of the STOP statement itself is ludicrously simple. However, when you explain the how and why of a STOP statement, you show that you understand:
The output of a program may be different based on whether a RUN statement comes before or after a global statement such as an OPTIONS or TITLE statement. If you are aware of this issue, it shows that you have written SAS programs that have more than the simplest of objectives. At the same time, your comments on this subject can also show that you know:
Adding numbers with the SUM function
provides the same result that you get with
the + numeric operator.
For example,
SUM(8, 4, 3)
provides the same result as
8 + 4 + 3.
Sometimes, though, you prefer to use the
SUM function, and at other times, the
+ operator. As you explain this
distinction, you can show that you
understand:
Computing a statistic with a function, such as the MEAN function, is not exactly the same as computing the same statistic with a procedure, such as the UNIVARIATE procedure. As you explain this distinction, you show that you understand:
Many SAS programmers never have occasion to use the REPLACE= dataset option or system option, but if you are familiar with it, then you have to be aware of:
A question on this topic may also give you the opportunity to mention syntax check mode and issues of debugging SAS programs.
Sometimes, it makes no difference whether you use a WHERE statement or a subsetting IF statement. Sometimes it makes a big difference. In explaining this distinction, you have the opportunity to discuss:
Compressing a SAS dataset is easy to to, so questions about it have more to do with determining when it is a good idea. You can weigh efficient use of storage space against efficient use of processing power, for example. Explain how you use representative data and performance measurements from SAS to test efficiency techniques, and you establish yourself as a SAS programmer who is ready to deal with large volumes of data. If you can explain why compression is effective in SAS datasets and observations larger than a certain minimum size and why binary compression works better than character compression for some kinds of data, then it shows you take software engineering seriously.
Almost the only reason interviewers ask about macros is to determine whether you appreciate the distinction between preprocessing and processing. Most SAS programmers are somewhat fuzzy about this, so if you have it perfectly clear in your mind, that makes you a cut about the rest — and if not, at least you should know that this is a topic you have to be careful about. There are endless technical issues with SAS macros, such as the system options that determine how much shows up in the log; your experience with this is especially important if the job involves maintaining SAS code written with macros.
SAS macro language is somewhat controversial, so be careful what you say of your opinion of it. To some managers, macro use is what distinguishes real SAS programmers from the pretenders, but to others, relying on macros all the time is a sure sign of a lazy, fuzzy-headed programmer. If you are pressed on this, it is probably safe to say that you are happy to work with macros or without them, depending on what the situation calls for.
The question, “What is the difference between a procedure and a macro?” can catch you off guard if it has never occurred to you to think of them as having anything in common. It can mystify you in a completely different way if you have thought of procedures and macros as interchangeable parts. You might mention:
If the interviewer asks a question about the scope of macro variables or the significance of the difference between local and global macro variables, the programming concept of scope is being used to see how you handle the new ways of thinking that programming requires. The possibility that the same name could be used for different things at different times is one of the more basic philosophical conundrums in computer programming. If you can appreciate the difference between a name and the object that the name refers to, then you can probably handle all the other philosophical challenges of programming.
Run-group procedures are not a big part of base SAS, so a question about run-group processing and the difference between the RUN and QUIT statements probably has more to do with:
Questions about SAS date values have less to do with whether you have memorized the reference point of January 1, 1960, than with whether you understand the implications of time data treated as numeric values, such as:
With today’s bigger, faster computers, efficiency is a major concern only for the very largest SAS projects. If you get a series of technical questions about efficiency, it could mean one of the following:
On the other hand, the interviewer may just be trying to gauge how well you understand the way SAS statements correspond to the actions the computer takes or how seriously you take the testing process for a program you write.
Most SAS programmers never use the data step debugger, so questions about it are probably intended to determine how you feel about debugging — does the debugging process bug you, or is debugging one of the most essential things you do as a programmer?
If you appreciate the distinction between informats and formats, it shows that:
The TRANSPOSE procedure has a few important uses, but questions about it usually don’t have that much to do with the procedure itself. The intriguing characteristic of the TRANSPOSE procedure is that input data values determine the names of output variables. The implication of this is that if the data values are incorrect, the program could end up with the wrong output variables. In what other ways does a program depend on having valid or correct data values as a starting point? What does it take to write a program that will run no matter what input data values are supplied?
Questions about the automatic variable _N_ (this might be pronounced “underscore N underscore” or just “N”) are meant to get at your understanding of the automatic actions of the data step, especially the automatic data step loop, also known as the observation loop.
A possible follow-up question asks how you can store the value of _N_ in the output SAS dataset. If you can answer this, it may show that you know the properties of automatic variables and know how to create a variable in the data step.
A question about the PUT function might seem to be a trick question, but it is not meant to be. Beyond showing that you aren’t confused by two things as different as a statement and a function having the same name, your discussion of the PUT function can show:
Some SAS trivia may be important to know in a technical interview, even though it may never come up in your actual SAS programming work.