Date: Mon, 6 May 2002 15:59:06 -0400
Reply-To: "Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM>
Subject: Re: what is wrong with this picture -- comments on interviewingca
ndidates
Content-Type: text/plain; charset=iso-8859-1
Don,
A couple of comments ... on selected points.
> There are no obscure features. Anything documented and usable is as far as
I am
> concerned not obscure. The exact algorithm behind the SPEDIS function is
obscure to me,
> but not the use of documented features.
I am really glad to see that you share my, rather obscure, opinion! For
example, PEEK and POKE are documented functions and I like using them ...
where *I* deem it appropriate. However, I am not sure it is easy to find a
project manager, even on a site with oodles of superlative SAS programmers,
who would not think that the guy fails to "resist the urge to get clever"
:-). In fact, as I recall, one of the most well-argumented objections came
from Westat, where finding a programmer capable of penetrating into any code
regardless of the degree of its cleverness is just a matter of pointing in
some randomly chosen direction.
> I had 2 weeks to find 3-4 people to complete the project in
> 4 months. I interviewed 8. I needed to know almost immediately that I
could find a
> whizz bang coder who had knowledge of many advanced things that others
> didn't, and 2 solid programmers who could competently and quickly follow
instructions,
> and in particular, also do work on other areas, such as spend 3-4 weeks
documenting every
> aspect of the system we develop -- in other words do the boring chaff as
well as the
> exciting stuff. My mandate from the client was DO NOT find all whizz bang
propellor heads.
These are very clear requirements - incidentally indicating that coding
style, the tendency to select one or another method, overemphasis (or lack
of it thereof) on performance, etc. were more important for executing that
particular project successfully than all-around SAS knowledge at the "guru"
level. However, a set of specifically sharpened questions would better suit
(in addition to other information) exactly the opposite purpose, that is, to
reveal guru-level knowledge.
I have expressed this opinion before, and do not mind repeating it now. If I
had a piano bar, say, and wanted to hire a pianist, the idea of asking him
how to play piano would never enter my mind. Nor could I care less if he
needed sheet music or could play all by heart. I would simply ask him to
play the style of music, or maybe even some particular pieces, that to my
mind, could please my customers. Listening for a half and hour would give me
all the information I needed. Quite importantly, it would be a comprehensive
impression.
Does there exist *any* set of questions, no matter how cleverly concocted,
that I could ask the pianist instead and achieve the same result with the
same success?
Hence, in those (luckily, quite rare) cases when, at one site, I was charged
with selecting folks for a project work, I simply would let the candidate
sit in front of a tube in a cube with shelves stuffed with SAS manuals (as
they usually are in the real life), with online help available, and ask to
write (that is, design, code, debug, validate the results, etc.) a real
program similar to, or with key elements of, programs he would be taking
care of if hired. Then I would show the guy my location, tell him he could
ask me any questions any time and leave him the heck alone for a period of
time about twice as long as I thought would be sufficient to accomplish the
task. After him having finished, I would look at the program and we would
discuss it.
With the exception of one rather bizarre occurrence, when the interviewee
refused to be interviewed in this fashion, told me that "normal interviewers
just ask questions", promised to complain and slammed the door (later he
did, indeed, concoct a long letter to the upper management about "unfair
interviewing practices"), this method has consistently led to acceptable
results. In fact, even the above-mentioned pathological case proved to be
positive in the sense that not only the person was not hired (I guess we
would be sorry if he were), but the very necessity to apprise him about the
decision was eliminated. I cannot take credit for having invented this
methodology, for I learned about it while being interviewed at a different
site myself. It impressed me as quite fair, even though I also had to show
some code written in the past and explain the stuff, just like another
poster in the thread has suggested.
The latter strikes me, in terms of the analogy used above, as asking the
pianist to show his past recordings. As a bar owner, I would probably want
to do that if I did not mind him sitting by the piano pretending to play
while a built-in CD player would be doing the job.
> (5) the candidate who "scored" highest was not taken on. He couldn't
> resist the urge to get clever. He freely admitted after doing the test
> that he actively looked for complex clever ways to do things.
Was there any indication (other than the high score) from the test itself
that he could not "resist the urge to get clever"? Or if he had not admitted
he was into funny coding and not mundane stuff, would you still have been
able to see him for what he was? I guess you might have just gotten lucky on
this one. A similar person under different circumstances (most trivially, in
want of money) could easily conceal his wicked cleverness and sneak in the
project. However, even in such a case it might not be as bad as it seems.
Often times, the need to win bread has a taming effect on a too clever a
sashole, making him not only write un-clever code, but sometimes - even
technical documentation! A very close friend of mine has witnessed this kind
of transformation himself... Of course, the propensity to get clever back
rises as the monetary considerations become less compelling; yet the
prolonged period of plain vanilla coding causes the brain to lose the
get-too-smart ability: ike they say, if you don't use it, you lose it. Thus,
as a result of this non-invasive SAS lobotomy, the danger is usually
eliminated.
In good sooth, I did not like your questions, but then I have never not seen
a set of interviewing questions I would like, anyway. To me, *no* set of
questions can objectively manifest the desired level of SAS proficiency.
That is why I will resort to the 'write-a-program' approach if need be.
Good luck!
Kind regards,
=================
Paul M. Dorfman
Jacksonville, FL
=================
Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross Blue Shield of Florida, Inc.
| 
