This has been asked many times before.

Do a Super Search for "interview" and you'll come out with many nodes like the following:

• Perl interview questions?
• Technical Interview
• Interview questions
• Perl Interviews

Dead End Questions

A little concern.

Would you consider it mandatory to have explaination for the items that you use to be a good programmer for 'this' need? For example what if the candidate doesn't know exactly what is the purpose of 'use strict' but always uses it in the program to avoid any messages.

Would you hire a programmer 1. having good practices ie.. using knowledge for programming advantage, or 2. expert in theory to which programmer may not be capable of converting it into practice.

In my opinion many of the 'know how' is not readily transferable to information. But for human being it can be easily seen by someone having similar or better knowledge.

artist
===================================================
Perl is fast.. So I spend more time doing fast things

How many Perl books do you own?

Does this really matter? I own no Perl book, but I'm not Perl-ignorant.

There is a lot of free on-line Perl documentation, and it is more than enough to become a good Perl coder. If owning a book means anything, then IMHO, it means that you don't like screen reading. And that's not positive: you better get used to reading the stuff on the screen, because that is where your code is going to be.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

How many Perl books do you own?

Does this really matter? I own no Perl book, but I'm not Perl-ignorant.

Ignoring the issue of hardcopy versus onscreen(for now), I would ask this question as an indicator of professional commitment. However, in retrospect, I might not ask it on the hypothetical test because it's far too easy to lie about it, and judges historically have turned me down for the search warrant.

ptkdb-

Yes, this is like what I had in mind. But I want to make it a written, multiple choice exam, so I don't have to sit there asking the questions or reading code.

I'd rather assess other issues than technical ones when we are face-to-face.

--lnl

It's certainly possible to write such an exam, perhaps even put it into some HTML or even CGI format to check results and mail them somewhere, or just something that prints out well.

If such a thing already exists on line, such as 'brainbench.com' it's probably going to cost some money to take it. Who's going pay?

Any of the monks here could probably write a half decent test in probably under an hour, and then spend the next two weeks debating the merits of various questions.

I don't need hot-shots, just sufficiently capable Perl programmers.

But I can imagine for many jobs, not knowing Web basics doesn't classify one as "sufficiently capable".

Abigail

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?

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.

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.

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. :-)

• They work magic
• Or, alternatively, they're dumb kids who just happen to know a little bit about how computer works
• Computers are hard for some people and not others
• The younger generation is good at computers
• Computer people are all interchangeable
• If you're not happy with how things are going, you can just work them harder

• Find someone who is serious about their profession
• Takes a stand on technical and management issues and keeps the project on track even when you're confused - personality is important