Social Hacking [was: "Strong Scripting Skills" - a definition?]

[jimd at starshine.org]

On Wed, Jan 28, 2004 at 12:20:43PM -0800, vraptor at employees.org wrote:
> This may be too "job-seeker" oriented for the general BayLISA list,
> but I think it's generally applicable in the abstract.  And I'm using
> "hack" in the classic sense, not the media-misappropriated sense.
 
> On Tue, 27 Jan 2004, Robert Hajime Lanning wrote:
 
>> I think we are defining new depths of what a "rabbit hole" is. :)
 
> I'm never surprises me when geeks take a question that's really about
> a social issue--"How can I represent myself as a competent scripter
> without over-inflating expectations of my skill set?" and turn it into
> a syntax or technical semantics festival.  (Particularly ironic in
> this case, since I recall one respondent's mantra as a boss: "don't
> use technology to solve a social problem."  You know who you are. ;-)

 Yes!
 
> To my mind, a good example was Jim's story of turning the
> interviewer's ps pipeline question onto it's head, thus demonstrating
> Jim's understanding of the depth of the system rather than his memory
> of syntactical minutae.
 
 I intended my story to focus on the interview dynamic rather than
 the technical details.  I tried, in that interview, to gauge the
 level of detail that would:

   * answer the question
   * demonstrate a degree of technical expertise
   * be professionally appropriate to the situation and percieved
     requirements of the why in which such a command or script would
	 probably be used.

 That last point was, in many ways, the most important.  If I'd launched
 into a two hour lecture demonstrating all the potential portability
 issues, exploring obscure corner cases, expounding on structured
 exception handling and "code re-use" issues --- if I'd "geeked out"
 (as we've been doing on this list, for recreational purposes) ---
 then I suspect I wouldn't have gotten the job.

 By the same token I would hesitate to recommend or hire someone who
 did "geek out" in an interview.  (Luckily I don't do much hiring nor
 interviewing).  I'm not bashing anyone on this list.  This discussion
 is fine for *this* context.

 When you're in an interview and you're asked technical questions,
 keep the answer reasonably brief.  You're not there to teach,  You're
 not there to solve their technical problems nor to write production
 quality scripts for them.  You're definitely NOT there to prove your
 technical superiority over the interviewer.  You're there to assure
 the interviewer that you are the best person for the job.

 (If you inadvertantly do prove to have more domain expertise than
 the interviewer, it can be a bonus; so long as it was done in a 
 professional way and also demonstrated the ability to prioritize
 and suit your answer to the context.  Just remember that it's not
 the goal).

 Incidently I didn't mean for my anecdote to sound like bragging.
 I've met people who are much better with shell scripting than
 I am.  I still read through Tom Christianson's "csh Scripting 
 Considered Harmful" with awe!  I've still never gotten the knack
 of capturing *just* the stderr into a variable while discarding
 or redirecting stdout elsewhere doing tricks with 4>& this other
 weird redirection hacks.

-- 
Jim Dennis