in reply to Perl Exam?

Let me translate what you said into what I heard.
I want to hire cheap talent. I don't want skilled people, just peons who can do as I say and not cost a bundle.

I want to put little energy into finding these peons. Is there some test I can give to do my work for me?

Suggestions? Perhaps Brainbench?

That may be unfair, but it is what I heard. And if the shoe doesn't fit, then please rest assured that there are many employers for whom it does.

Here is my answer.

A classic problem that management has is underestimating how much they are wasting in the long run by making short-term decisions. While a cheap programmer can get the job done, it won't be done as reliably or as fast as a good programmer would do, and having been done shoddily, further modifications will be likely to cost you more down the road. (Although to be fair, it is hard for most employers to tell good programmers from bad ones...)

But if you want to take this path, then brainbench probably is what you are looking for. I took their Perl test a few years ago on a lark. Based on that I would say that someone who manages to pass that test without cheating probably does know Perl. However a lot of what is tested is probably going to be irrelevant to you. If you have far more candidates than you need, and are willing to weed them down to technically capable ones on a somewhat arbitrary criteria, that will likely do it.

It won't tell you anything about that person's work habits, what they know of good software practice, or how you will get along with them. You know that. My experience is that it doesn't take much looking through code that a person wrote to tell a good programmer pretty quickly that person's general skill level, and also something about what that person knows of good software practice. Of course that requires a good programmer, which is kind of a chicken and egg problem.

Replies are listed 'Best First'.
Re: Re: Perl Exam?
by rsmah (Scribe) on Oct 21, 2003 at 07:22 UTC
    While I understand your perspective Tilly, my own experience in hiring programmers leads to me to believe that tests are *required*.

    Too often, education and experience show a very small part of the picture. When giving simple tests, I've seen people with impressive resumes fall *way* short. To the point that I am truely frightened.

    This is not true of just finding developers who know perl, but also Java (perhaps more so), C++, and even sysadmins.

    The sad fact is that the majority of people currently employed doing technical work simply walk through work in a deep dark haze. They try this, that and the other thing, until it sort of works, not knowing why. They copy and crib (not that that's always bad) without understanding what they're copying (that's bad, IMO). I don't believe this is isolated to technical professions, it is true of here too.

    You have to realize that most management types simply do not have the skills and knowledge base to make reasonable assessements of a programmers skill level. For those people, tests are the only way they can assess how well a person knows a given skill.

    Should a perl interview test be hard? Of course not. It should stupid simple. The kind of test where if someone misses a few questions you have to seriouslly consider that they either a) lied or b) have brain damage. The kind of test you could pass by skimming an intro book to perl the day before the exam.

    Sad fact is that I'll bet more than half of the people you interview won't pass such a stupid simple test. Such is life.

[reply]
      Indeed.

      I'll bet that the failure rate is closer to 2/3 than 1/2.

      Question 1 at (OT) Interview questions -- your response? is based on a conversation that Ovid and I had where I described an interview question that I actually use. (Ovid translated it into pseudocode, and omitted the statement that each array can be assumed to only have unique elements.) I generally ask that question in Perl, and stand ready to explain any language construct that the other person doesn't understand. I further walk them through a 3-part question, first is to describe what it does, second is to figure out the performance, and then third is to come up with an approach (code not required) to solve the scalability problem.

      About 2/3 of people I have interviewed (all purportedly experienced programmers, etc, etc) fail that test. No halfway competent programmer of my experience (tested on friends, co-workers, etc) has found it hard. (Several have been puzzled about where the challenge is supposed to be.) Knowledge of Perl does not appear to make much of a difference, even though I give the question in Perl.

      And here we come to what I consider a critical point. I think that Perl experience only really matters if you want someone to hit the ground running in a very Perl-specific environment. If you use a mix of languages, then while you might like Perl, you don't necessarily want to insist on it. Looking for that is somewhat harder.

      Incidentally for perspective on why companies find hiring the right person so hard, read Anne Learns To Recruit. :-)

[reply]

In Section Meditations