Date: Tue, 7 May 2002 14:30:00 -0400
Reply-To: Sigurd Hermansen <HERMANS1@WESTAT.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Sigurd Hermansen <HERMANS1@WESTAT.COM>
Subject: Re: what is wrong with this picture -- comments on intervie
Content-Type: text/plain; charset="iso-8859-1"
Can't I get anything past you guys!
I was thinking 'syntax and control structures' instead of 'syntax and
logical
structures'. Sorry for the contradiction.
Sig
-----Original Message-----
From: Mike Harris [mailto:mikeh@amgen.com]
Sent: Tuesday, May 07, 2002 11:56 AM
To: Sigurd Hermansen
Subject: Re: what is wrong with this picture -- comments on
interviewingcandidates
You say you now ask fewer questions about logical constructs and more about
logical constructs. I and perhaps other readers would appreciate some
clarification.
Mike Harris
Sigurd Hermansen wrote:
> I find myself making a big distinction between a cleverly written
procedure
> or function that the author bases on an established method (hashing or
array
> sorts), or theorems in mathematics or logic (or in the best cases, both
> method and proof) vs. a hundred lines of dense references to nested
> macrovariable definitions and loops through arrays that challenge anyone's
> patience. Simply put, good SAS programmers are good programmers. After
> conducting several hundred interviews of programmers at all levels, I now
> ask fewer questions about syntax and logical constructs and more about
> relations among data sources, logical constructs, and a person's
interests.
> Few of us have the intellectual range and honed skill that the SAS-L
masters
> bring to this forum, but it doesn't take genius to appreciate proveable
and
> efficient programs. I would guess that when Don looks unfavorably on
clever
> programming, he suspects a desire on the part of the programmer to impress
> him with how he or she has found clever ways to circumvent problems that
he
> or she has created in the first place. I would also guess that Don would
> appreciate clever solutions that make programming easier and more precise.
> Sig
>
> -----Original Message-----
> From: Dorfman, Paul [mailto:Paul.Dorfman@BCBSFL.COM]
> Sent: Monday, May 06, 2002 3:59 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: what is wrong with this picture -- comments on
> interviewingca ndidates
>
> 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.
| 
