Perl Software Developer and Database programmer

This is exactly it, there are two reasons I would ask
technical questions at interview:
- to find out the depth of knowledge and experience of a
specific technology
- to find out how the person would go about filling holes in
their knowledge

So if someone doesn't know the difference between my/local
- but gave me an answer like below, I'd be more impressed
than if they explained the difference badly.

Demonstrating good problem resolution skills is more
important than specific technical skills. I'd say the same
for good interpersonal skills. If candidate can demonstrate
they are a competent and quick learner, that is a massive
plus.

On occasion, for some jobs, you do want specific technical
knowledge. Right now, someone with a good clear
understanding of Perl would be a lot more useful to me than
someone who hasn't. 

My original point was more about the apparent lack of good
developers, who are not just technical, but are more rounded
- maybe fat developers don't want to work in Slough though
;)

J

-----Original Message-----
From: bond.pm-bouncesbond.pm.org [mailto:bond.pm-bouncesbond.pm.org] On Behalf Of Simon Wistow
Sent: 22 February 2006 12:34
To: bond.pm Perl M[ou]ngers
Subject: Re: [JOB] Perl Software Developer and Database
programmer

On Wed, Feb 22, 2006 at 11:52:44AM +0000, Peter Corlett
said:
> Knowing the difference between local and my is kind of
important. I'd 
> say that somebody who didn't know this basic stuff was
not competent.

That's a hugely sweeping statement - as was pointed out
some people may just never have come across local() but may
know way more about, say, Formats than you. Or XS. Or
regexen. 

I think part of the problem is that there's only only so
much you can actually learn. What's more improtant to me is
not mastery of compiler internals but the ability to pick
new concepts up quickly and also the ability to know where
to look stuff up.

Even if I didn't now what the difference is was I *do* know
how to do

% perldoc -q local

which gives

  Found in /usr/local/perl580/lib/5.8.0/pod/perlfaq7.pod
       What's the difference between dynamic and lexical
(static) 
       scoping? Between local() and my()?


but by using my knowledge of perldoc -q I also know the
answer to how to parse HTML

  Found in /usr/local/perl580/lib/5.8.0/pod/perlfaq9.pod
        How do I remove HTML from a string?


Let's face it - most langauges within the same paradigm are
almost exactly the same. Sure there's some syntatic sugar
but the ability to program in the abstract and how to look
up this particular brand of syntatic is far more important
in general. And then on top of that you have what
environment you're programming in - doing Web stuff in C is
very different to doing, say, Embedded Mobile devices in C
or graphics hacking stuff in C.

Having said that I've given a programming test that
included the difference between my() and local(), HTML
parsing but also Templated linked list creation in C++,
reversing the order of some words in a string in C and the
difference between GET and POST.

The test was emailed to the candidates and the could return
it at their lesiure. What I was looking for wasn't
necessarily instant recall but more the ability to reason
and lookup. One candidate failed because he came up witha 
hideously complicated regex to strip the text from HTML. 
Far more complicated than I could write. Everytime in the
interview when I pressed him for problems he would think of
one and adapt the regex to deal with it. All very clever. He
didn't get the job.

Conversely, I once got asked what


	a = a++

or something similar would do  in C - my C-fu wasn't
stellar at the time but it was sufficient that recognised
there could be a problem (IIRC it's an undefined behaviour
- I'm a bit fuzzy at the moment, mild
concussion) 

Simon

Oops.  Sorry for the empty email 

--- "O'Shaughnessy, Jamie" <jamieoshamazon.co.uk> wrote:

> This is exactly it, there are two reasons I would ask
technical
> questions at interview:
> - to find out the depth of knowledge and experience of
a specific
> technology
> - to find out how the person would go about filling
holes in their
> knowledge

As a thoroughly depressing example, here's a sample
question I throw at
people who apply for Perl jobs:

  Imagine we're building an app and it turns out to be
slow.  We've
  profiled the code and reduced the problem down to this:

    foreach my $alpha ( alphas ) {
        foreach my $beta ( betas ) {
            if ( $alpha == $beta ) {
                push results, $beta;
            }
        }
    }

  1.  What is a likely reason for the performance problem?
  2.  How might we speed it up?

Even though the applicants are allowed to ask any questions
they want
I've been dismayed to discover that most applicants cannot
answer the
first questions and those who can are often stumped by the
second. 
Heck, if you've never used Perl, the problem itself should
be clear,
even if a "Perlish" solution is not (sort betas and
do a binary
search, anyone?)

Here's another one:

  Write a program that presents the following menu to a
user:

    1.  Display a text file
    2.  Add a timestamped line of text to the file
    3.  Exit

  For the first two options, return to the menu after
they're done.

  The text file can be anything you want.  Adding a line of
data 
  should prompt the user for some input (any input is
acceptable).

Now here's the kicker:  I would give them Perl books,
access to the
Internet, freedom to use perldoc at will and tell them that
any
reasonable interpretation of the program they come up with
is fine. 
I'm looking for general coding style and I'm not being
nitpicky.

I wrote the program in a couple of minutes just to make sure
I didn't
miss something silly.  I gave candidates an HOUR and most
could not
finish it.  Yeah, I'd like an OO god who has no problem
using closures
and always writes tests, but that's a dirt-simple
procedural program. 
Maybe Portland just has a bunch of really, really awful
programmers.

Cheers,
Ovid

-- 
If this message is a response to a question on a mailing
list, please send follow up questions to the list.

Web Programming with Perl -- http://u
sers.easystreet.com/ovid/cgi_course/

Just ask "What is wrong with Perl?" Then listen
very carefully.

--- "O'Shaughnessy, Jamie" <jamieoshamazon.co.uk> wrote:
 
> This is exactly it, there are two reasons I would ask
technical
> questions at interview:
> - to find out the depth of knowledge and experience of
a specific
> technology
> - to find out how the person would go about filling
holes in their
> knowledge



-- 
If this message is a response to a question on a mailing
list, please send follow up questions to the list.

Web Programming with Perl -- http://u
sers.easystreet.com/ovid/cgi_course/

Peter Hickman wrote:
> Just ask "What is wrong with Perl?" Then
listen very carefully.

Yes. I find this is the best way to find out how well
someone knows a 
language. If they can talk intelligently about its
weaknesses.

   n

On 22 Feb 2006, at 16:17, Nigel Rantor wrote:
> Yes. I find this is the best way to find out how well
someone knows  
> a language. If they can talk intelligently about its
weaknesses.

And in general demonstrates healthy scepticism. Fanboys (and
girls)  
who can't see the drawbacks of a given technology,
technique or  
philosophy are invariably hard to work with.

-- 
Andy Armstrong, hexten.net

On Wed, Feb 22, 2006 at 08:10:58AM -0800, Ovid wrote:
> --- "O'Shaughnessy, Jamie"
<jamieoshamazon.co.uk> wrote:
> > This is exactly it, there are two reasons I would
ask technical
> > questions at interview:
> > - to find out the depth of knowledge and
experience of a specific
> > technology
> > - to find out how the person would go about
filling holes in their
> > knowledge
> 
> As a thoroughly depressing example, here's a sample
question I throw at
> people who apply for Perl jobs:  [...]

It's depressing, it's always been this way, and it's not
unique to Perl.

I remember an interview *mumble* years ago for a job as a C
programmer,
and the entire technical portion of the interview hinged on
a single
question:

	Write strstr().

Everything else was just chit-chat.  

Take dozens of resumes, cherry pick the ones that actually
look like
they have the necessary skills, and maybe one applicant in a
hundred
could answer that question.  I found a similar state of
affairs when I
was interviewing Perl programmers a few years later.

And it's not limited to programming, either.  I heard an
interview with
someone who had Richard Feynman attending his dissertation
defense.
Feynman asked two questions at the beginning, which
effectively bracketed 
the candidate's knowledge of physics.  The first
established a lower bound, 
and the second established an upper bound.

The difference between Feynman evaluating a PhD candidate
and hiring a
programmer is that hiring managers don't really care about
the upper
bound -- finding someone whose skills are above the minimum
lower bound
is enough.  Sadly, asking a single, simple technical
question, with no
strings attached, is often sufficient.

Z.

On 22 Feb 2006, at 16:10, Ovid wrote:
> (sort betas and do a binary
> search, anyone?)

You don't need no steenking binary search 

Sort both lists and then merge sort the two lists discarding
non- 
equal items.

-- 
Andy Armstrong, hexten.net

On Wed, 2006-02-22 at 08:10 -0800, Ovid wrote:
> As a thoroughly depressing example, here's a sample
question I throw at
> people who apply for Perl jobs:
> 
>   Imagine we're building an app and it turns out to be
slow.  We've
>   profiled the code and reduced the problem down to
this:
> 
>     foreach my $alpha ( alphas ) {
>         foreach my $beta ( betas ) {
>             if ( $alpha == $beta ) {
>                 push results, $beta;
>             }
>         }
>     }
> 
>   1.  What is a likely reason for the performance
problem?
>   2.  How might we speed it up?

> Heck, if you've never used Perl, the problem itself
should be clear,
> even if a "Perlish" solution is not (sort
betas and do a binary
> search, anyone?)
> 

Ok I'll bite (I'm bored waiting for Airwave to sort their
network out).

How about:

my beta = (1,3,5,6,7,9);
my alpha = (2,3,4,8,9,10);

my %beta;

beta{beta} = ();
my results = grep {exists $beta{$_}} alpha;

print join(',', results), "\n";


Dirk

Andy Armstrong wrote:
> On 22 Feb 2006, at 16:10, Ovid wrote:
>> (sort betas and do a binary
>> search, anyone?)
>
> You don't need no steenking binary search 
>
> Sort both lists and then merge sort the two lists
discarding non-equal 
> items.
>
> --Andy Armstrong, hexten.net
>
>
What about duplicate entries in, say, the alpha, list?