o****o
发帖数: 8077 | 1 ZT from :
http://www.globalstatements.com/sas/jobs/technicalinterview.htm
*****************************************
SAS Technical Interview Questions
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.
Key concepts
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:
* SORT procedure
* Data step logic
* KEEP=, DROP= dataset options
* Missing values
* Reset to missing, or the RETAIN statement
* Log
* Data types
* FORMAT procedure for creating value formats
* IN= dataset option
Tricky Stuff
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.
STOP statement
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:
* How a SAS program is divided into steps, and the difference between a
data step and a proc step
* The automatic loop in the data step
* Conditions that cause the automatic loop to terminate, or to fail to
terminate
RUN statement placement
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:
* The distinction between data step statements, proc step statements,
and global statements
* How SAS finds step boundaries
* The importance of programming style
SUM or +
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:
* Missing values
* Propagation of missing values
* Treatment of missing values in statistical calculations in SAS
* Why it matters to handle missing values correctly in analytic
processing
* The use of 0 as an argument in the SUM function to ensure that the
result is not a missing value
* The performance differences between functions and operators
* Essential ideas of data cleaning
Statistics: functions vs. proc steps
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:
* The difference between summarizing across variables and summarizing
across observations
* The statistical concept of degrees of freedom as it relates to the
difference between sample statistics and population statistics, and the way
this is implemented in some SAS procedures with the VARDEF= option
REPLACE= option
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:
* The distinction between the input dataset and the output dataset in a
step that makes changes in a set of data
* The general concept of name conflicts in programming theory
* Issues of programming style related to name conflicts
* How the system option compares to the corresponding dataset option
A question on this topic may also give you the opportunity to mention syntax
check mode and issues of debugging SAS programs.
WHERE vs. IF
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:
* The distinction between data steps and proc steps
* The difference between declaration (declarative) statements and
executable (action) statements
* The significance of the sequence of executable statements in a data
step
* Some of the finer points of merging SAS datasets
* A few points of efficiency theory (although tests do not seem to bear
the theory out in this case)
* The origin of the WHERE clause in SQL (of course, bring this up only
if you’re good at SQL)
* WHERE operators that are not available in the IF statement or other
data step statements
Compression
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.
Macro processing
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.
Procedure vs. macro
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:
* The difference between generating SAS code, as a macro usually does,
and taking action directly on SAS data, as a procedure usually does
* What it means, in terms of efficiency, for a procedure to be a
compiled program
* The drastic differences in syntax between a proc step and a macro call
* The IMPORT and EXPORT procedures, which with some options generate SAS
statements much like a macro
* The %SYSFUNC macro function and %SYSCALL macro statement that allow a
macro to take action directly on SAS data, much like a procedure
Scope of macro variables
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 groups
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:
* What a procedure is
* What a step is
* All the work SAS has to go through as it alternately acquires a part
of the SAS program from the execution queue, then executes that part of the
program
* Connecting the program and the log messages
SAS date values
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:
* Using a date format to display the date variable in a meaningful way
* Computing a length of time by subtracting SAS date values
Efficiency techniques
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:
* The employer is undertaking a project with an especially large volume
of data
* The designated computer is not one of today’s bigger, faster
computers
* The project is weighed down with horrendously inefficient code, and
they are hoping you will be able to clean it all up
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.
Debugger
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?
Informats vs. formats
If you appreciate the distinction between informats and formats, it shows
that:
* You can focus on details
* It doesn’t confuse you that two routines have the same name
* You have some idea of what is going on when a SAS program runs
TRANSPOSE procedure
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?
_N_
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.
PUT function
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:
* An understanding of what formats are
* Your experience in creating variables in data step statements
* A few of the finer points of SQL query optimization
Important SAS trivia
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.
* MERGE is a data step statement only. There is no MERGE procedure. “
PROC MERGE” is a mythical construction created years ago by Rhena Seidman,
and if you are asked about it in a job interview, it is meant as a trick
question.
* It is possible to use the MERGE statement without a BY statement, but
this usually occurs by mistake.
* SAS does not provide an easy way to create a procedure in a SAS
program. However, it is easy to define informats and formats and use them in
the same program. Beginning with SAS 9.2, the same is true of functions.
* The MEANS and SUMMARY procedures are identical except for the defaults
for the PRINT option and VAR statement.
* Much of the syntax of the TABULATE procedure is essentially the same
of that of the SUMMARY procedure.
* CARDS is another name for DATALINES (or vice versa).
* “DATA _NULL_” is commonly used as a code word to refer to data step
programming that creates print output or text data files.
* The program data vector (PDV) is a logical block of data that contains
the variables used in a data step or proc step. Variables are added to the
program data vector in order of appearance, and this is what determines
their position (or variable number) attribute. | C******y
发帖数: 2007 | 2 this is for sas programmer | o****o
发帖数: 8077 | 3 yes it is because the title says SAS technical....
【在 C******y 的大作中提到】
: this is for sas programmer
| a********i
发帖数: 205 | | l*********s
发帖数: 5409 | |
|
