[JOB] Perl Software Developer and Database programmer

[Lusercop]

On Tue, Feb 21, 2006 at 02:38:12PM -0000, O'Shaughnessy, Jamie wrote:
> You seem to get a lot of people that have done what may be some
> interesting web work, but it's very small scale and they only have
> experience of working in very small teams and often have very limited
> software engineering experience. I've found it only too common that
> their perl knowledge is "user level" at best - ask them to explain
> the difference between my and local and they may just muddle through,
> start talking about stashes, closures, etc and they're totally lost.

Perhaps if you're asking people to be competent software engineers, you
could start by asking questions more in line with software engineering
principles than (computer-)linguistic intricacies. While I appreciate that
understanding something as subtle as the difference between my and local is
important in gauging depth of understanding of the perl language, the use
of local at all tends to indicate bad software engineering to me... I can
imagine a very good software engineer who doesn't understand the difference
between the two, because he's never had to use local, all his/her code is
reentrant and doesn't use globals which need localising.

Why conflate the two things? To be honest, if someone mentions "stashes" at
all, then their knowledge is obviously beyond "user level".

I've found that more often the problem is developers not understanding
anything at at least one level below. I'd rather you explained things about
the UNIX syscall interface to me, and how you might go about writing a
routine to open and read a file in the most efficient way possible for
web serving - understanding what assumptions you're making and why you
think you can make them, then how you'd change it if your underlying
assumptions change. I think I'd rather someone who had a detailed knowledge
of UNIX system programming than the intricacies of the perl language.

On a related note, someone who has an idea of the relevant standards for
the work that they interact with. Eg. if they've written a communication
daemon as part of their work, have they read some RFCs and seen IETF
protocols, have they taken hints from these, if they've rejected them, then
why? If they're writing a piece of software to generate mails, have they at
least read RFC2822 (or RFC822, which is still the standard) to understand
what headers they should be generating and what format they should take.
If they're writing software to autogen XML or HTML have they at least had
a cursory glance at the W3C site.

As someone whose email client emits long lines, without a Content-Type
parameter of 'format="flowed"', you probably haven't, or at least didn't
know that it existed. (I'll ignore the top-posting for the moment).

> And if they get through the technical side, where are the communication
> and people skills? You spend far less time actually coding than you do
> dealing with other people and so this is a real key skill for good devs.

Agreed, though one thing I find is that forcing your developers to be
communicative is also unhelpful. They should be isolatable in some sense
so that they can get on with their work. Especially for those doing tricky
stuff, allowing them an environment where concentration is possible is very
imortant.

> My final test is always - do I want to sit next to this person for most
> of my working day, can I get on with them, have a laugh, etc. (and will
> they feel the same way about me!).

A very good test.

My feeling, from my limited experiences of recruiting is that you have one
person on the interviewing side who will concentrate on the technical side
and one concentrating on the personal side.

The corollary to this is of course that you should probably feel that a good
candidate is interviewing you...

YMMV

-- 
Lusercop.net - LARTing Lusers everywhere since 2002