"Strong Scripting Skills" - a definition?

Sun Jan 25 05:36:40 PST 2004

On Sat, Jan 24, 2004 at 09:14:09PM -0800, richard childers / kg6hac wrote:

>> how will I know
>> when I can say with confidence that I have "strong" scripting skills?

 The phrase is clearly ambiguous and subjective.  I've taught classes in
 shell scripting.

 I once had an interviewer put up a wretched fragment of shell code like:

 	kill `ps wax | grep "foo" | grep -v "grep" | awk '{print $11}'`

 ... and ask me to explain what was "wrong with it.  I pointed out that
 I wasn't sure which field number the PID was in in that ps output
 format, and I always check with 'ps -$FLAGS | head' before code
 anything like that.  (That was the answer he was looking for).  Then
 I went on to explain the UUoG (useless use of grep, squared by the
 extra one with the -v), the non-portability of the ps flags (in any
 scripting), the risk that some unintended matches might occur from
 the unanchored regex (i.e. "foo" might occur in the arguments list of
 some process that was not actually a "foo" process, other than the
 aforementioned useless grep), and even that the use of command
 substitution can usually be eliminated with a pipeline into xargs or
 a while loop.

 I then wrote a fragment of about the same length that addressed most
 of those issues using only bash/Korn built-ins (other than the ps
 command):

 	ps wax | while read pid x x x cmd args; do [ $cmd = foo ] && \
		kill $pid; done 

 (He picked his jaw up off the table and declared that I knew much more
 about shell scripting than he did and recommended me for the position).

 (Nitpick: in ancient versions of Bourne shell the [ and kill commands
 would also be externals).

 Personally I don't think this displays much expertise in shell
 scripting.  To me this example is trivial.

 I agree with Richard on the point that some interviewers can be
 outrageously arrogant (dripping with geeky testosterone) about
 "scripting" (and programming skills in general).  It's one of those
 areas where *some* interviewers might engage in a sort of pissing
 contest to show how clever they are.

 Another area where this is likely is when you see phrases like:
 "strong security skills."

 My suggestions:

 Try to be reasonable objective about your skill level, but err on the
 daring side.  Feel free to describe your skills as "strong" (or at
 least "solid") if you honestly believe they'll be "good enough" for
 the job at hand.

 Be modest and understated about it.  Any appearance of bragging is
 likely to work against you.  If you're relatively modest about it, then
 you're less likely to pull the trigger on any hidden testerone squirt
 gun; and you can gracefully defer to his (or her) superior expertise if
 "shots" are fired.  Often grace under this sort of pressure is a more
 valuable job skill then the technical expertise in any event.

 Obviously any stories you have about interesting scripts you've
 written, especially any that have been published or used in production
 are compelling.  (For instance: the first awk script I ever wrote, the
 one for which I taught myself the basics was about 70 lines long,
 written in a couple days and formed the core for regression testing
 and competitive analysis for the McAfee anti-virus products for a
 couple of years.  It was later ported to Visual BASIC by one of their
 programmers who said he retained the design "almost line for line").

 Don't let the discussion get too involved during an interview.  It's
 not you're job to give them a free programming session and the
 interview situation is not conducive to quality coding.  It's alright
 to gloss over the details.  In fact it's incumbent upon you to do so.
 However, don't try to conceal a lack of expertise with the glossing.

 (Typical glossing: you can point out where you'd practice defensive
 coding by checking return values without trying to code up the
 exception handling in your example; you can point out cases where you'd
 look up the exact arguments or output/parsing formats just using 
 psuedo-variables in your psuedo-code.  You should point out potential
 portability issues.  For example, I'm perfectly happy to say that I
 don't remember which field number the command string is going to appear
 in in a given 'ps' command.  It's a trivial detail that I can check as
 I'm typing --- and it can be different from one system to another anyway.
 It's even okay to say something like: I remember that there's an
 argument for GNU ps that controls the exact output format and strips
 the header line --- it's better for scripting like this and I'd have to
 read the man page and fuss with it interactively to use it).

 Be aware of the limitations of scripting.  Sometimes the best answer,
 in practice as well as for an interview, is to say: "that task is not
 appropriate for a shell script"  (though almost anything can be done in
 Perl :) ).  It's even reasonable, in some cases to say: "I'd look for
 something that already does this on Freshmeat, or CPAN or Google."

 Another example, perhaps facetious, is if they ask you to do a binary
 search of a sorted text file on a Linux system; it's quite reasonable
 to point out that mainstream Linux distribution commonly include the
 'look' command which already does this.  You can ask if they still want
 you to describe such a script as an academic exercise --- to
 demonstrate your understanding of how to perform a binary search.  I've
 seen cases where the proposed scripting assignment was a trick question
 and the desired answer was: use "foo"; I recall the old "autopasswd"
 expect script was one that came up a few times --- for setting a large
 number of new account passwords at once.  My solution has been
 something like:  

 	while read name pass; do 
		useradd -m $name; autopasswd $name $pass; 
 		done < newaccounts.txt

 (Which I routinely use when teaching LPI courses, to create a set of
 throwaway accounts on the class server for exercises).

 As for "which shell" I typically presume they want Bourne/Korn/bash
 and will happily refer to "csh Programming Considered Harmful" if asked
 to write a sample in csh.  (I'll also point out that I can struggle
 thorugh a csh script if pressed, but only with lots of experimentation
 and reference because I consider its syntax to be quirky).

 Last suggestion: avoid useless and flowery cleverness.  It's clever
 to use commands like: cc -o foo{,.c} ... but anything that makes the
 interviewer scratch his or her head to wonder *why* you did that when
 there was a more straightforward way -- will work against you.

> [1]   If you can teach your interviewer(s) something that they did not 
> know, you can say you have strong scripting skills. Note that this 
> definition is relative to your interviewer's skill level.

> [2]   If you have source code that you don't mind showing others, doing 
> something serious that they lack, and your readers can understand it, 
> you have strong scripting skills. Extra points if they did not know that 
> they needed it until you walked into the room and started talking. Extra 
> points if it runs on their computers without tweaking. Extra points if 
> it can be downloaded from the Internet and demo'd during the interview.

> [3]   If you have scripting skills that span several shells and can talk 
> knowledgably about past projects using them all, you probably have 
> strong scripting skills.

> [4] If you have scripting skills that span several scripting languages 
> and can talk knowledgeably about the differences between interpreted and 
> compiled code, know who Kernighan and Plauger are, and can quote from 
> The Element of Programming Style ... you probably have strong scripting 
> skills.

> All that having been said, you will occasionally run into anal 
> programming types who spent some time at college poring over shell 
> source code, and whom think they are better than you. They will be eager 
> to prove it to you; they might even be right. You probably won't want to 
> work with them, anyway, and they probably need to spend a few years 
> writing production shell scripts for a living to get that ivory tower 
> polish off them; keep moving and don't look back.

> (Live365 comes to mind ...)

> Remember that there are thousands of programmers out there who taught 
> themselves shell programming; don't feel bad about what you don't know, 
> but do feel sorry for the people you meet whose superiority does not 
> allow them to raise others to their level of education.

> I have heard of people whom represent themselves as adept at shell 
> programming, whose jaws drop when you ask them, 'Which shell?'. So care 
> is indicated.

> Regards,

-- 
Jim Dennis