SPUG: Why aren't they hiring?

[Jason Lamport]

At 12:15 PM -0800 11/16/01, James Moore wrote:
>  > The fact is, when I started doing web dev, there *was*
>>  no CGI.pm -- or at least it wasn't part of the standard Perl
>>  distribution -- so I had to roll my own solutions, solutions which I
>>  still use in lieu of CGI.pm (whose API I really dislike, but that's
>>  another thread).
>>
>
>Interesting - that's exactly the kind of thing that I would love to have
>come up in an interview.  Unfortunately, I'd put it in the "case of
>not-invented-here syndrome" category.  In any case, though, talking about it
>would certainly give both of us a fair amount of information, and would
>hopefully let us decide if we could work together effectively.  It's the
>kind of thing where a decision to hire or not to hire may be based more on
>differences in technical philosophy than in coding competence.  That's not a
>bad thing, though - interviews are mostly about deciding whether or not you
>can work with this group of people, from both sides.  You may not be happy
>in a situation where people would haul you out into a dark alley if you
>won't use CGI.pm :-).

Note: I only said that I disliked the API, not that I'd refuse to use 
it.  And I should have clarified: "...solutions which I still use in 
lieu of CGI.pm *when working on my own solo projects.*"  The few 
times that I've collaborated with another developer on a CGI script, 
we *have* used CGI.pm.  I'm not the sort who's going to try to impose 
my preferences on other members of a development team.

(Ironically, perhaps, I think this is one case where a bit of 
cockiness on my part actually makes me more agreeable to work with: 
while I would never state this so bluntly to my co-workers, I 
personally consider myself a better programmer than 98% of the other 
programmers out there.  Because of this, I just assume that it will 
be much easier for me to adapt my coding style to accommodate other 
developers than for other developers to adapt their coding style to 
accommodate me.  Again, I would never state this so bluntly in a work 
situation: I think my colleagues are likely to perceive only that I'm 
very willing to do whatever I can to make their jobs easier.  They 
don't need to know that that willingness comes from my secret belief 
that they need all the help they can get...  ;)

>
>   I'm also likely to
>cut you a huge amount of slack for things like routine names - writing
>"routine_to_get_the_next_directory_entry" is fine, since I'm going to assume
>you can read perl doc if you forget about opendir/readdir.

But I think you should make that explicit at the beginning, otherwise 
the interviewee is likely to waste a lot of brain cycles worrying 
about their ignorance of the syntax for opendir/readdir, rather than 
focusing on the real problem and giving you the information that 
you're actually looking for.

Remember that the good candidates are the ones who honestly believe 
that they are the best candidate for the position, and so are going 
to be *eager* to give you the information that you need to make a 
good decision.  Whatever you can do to *help* those candidates 
provide you with that information (without giving the bullshitters 
too much fodder for bluffing their way through) is going to help you 
as well.

(And personally, I wouldn't just assume that someone can read 
perldoc.  It's far more important to me that a candidate know how to 
find and then use information that they don't already have than that 
they know everything already.  I might ask them some extremely arcane 
question about Perl syntax just to see how they go about finding the 
answer... but again, I would try to make it clear that that was what 
I was doing.)

>
>And as for reducing the stress level in interviews, maybe I'm too harsh, but
>I'm not sure I'm concerned about that.  You're going to be dealing with
>stress on the job sometimes, and if you're a basket case in an interview I'm
>probably going to think the same thing's going to happen in other
>situations.

The problem with that attitude is that the sorts of stresses one 
encounters during a tough interview are *completely* different from 
the sorts of stresses one encounters in an actual work situation. 
How often in an actual work situation do you have a supervisor 
looking over your shoulder, examining every single line of code you 
write *as you write it*; and all the while you know that your 
continued employment at that company is largely contingent on whether 
that supervisor likes what they see, based on some set of criteria of 
which you are only vaguely cognizant?  It sounds more like a 
Dilbert-esque nightmare than a normal work day -- yet that's 
approximately the situation into which the average job interview puts 
the candidate.  Just because a candidate performs poorly in that sort 
of an interview situation does not mean that they will perform poorly 
on the job.

I'm all for "stress-testing" a candidate, provided that the stresses 
are *realistic*, i.e. that they are significantly similar to the 
sorts of stresses that the person will be facing on the job.  But I 
think that, the way interviews are usually conducted, they rarely are.

-jason

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/