I do like the idea of having the candidate just write on the whiteboard and explain. With a suitable problem (yours feels like the right level of complexity), I could possibly convince the powers that be to dispense with formal, written test.

You also mention usage of strict several times in your post. Don't stare yourself blind on that. "use strict" is an aid, but a defensive one.

Yes and no. I don't think anyone expects one-offs, especially of the perl -pi -e... variety, to be strict, and there are definitely good reasons be unstrict sometimes. But IHMO there should be a reason -- symbolic refs are useful when constructing accessor methods, or doing some kinds of dispatch; barewords have their place occasionally; I can't think off the top of my head why you wouldn't want strict vars in code you intend to maintain, but I'm sure there is a justification sometimes. Regardless, it seems to me that the programmer should make a concsious decision to relax those restrictions, because by default restrictions support other properties, e.g., modularity, loose coupling, separation of concerns, etc., that promote maintainability. And that's a big part of what I care about.

Like safety belts. You wouldn't judge the quality of a driver on whether he wears safety belts or not (and while you may demand that a driver wears a safety belt if you hire him, his driving won't improve).

Actually, I would judge a driver on that, depending on what I was judging him for. If I wanted him to drive my race car, perhaps not, but if I wanted him to drive me around, definitely. Because seat belts are a massive safety improvement, and these days, deciding not to wear one is tantamount to admitting you aren't concerned with safety.

You also might miss out on great coders like Damian, who seldomly uses strict.

Certainly, Damian is infinitely more skillful than I, and yeah, he'd be great to have! There are plenty of other Perl gods and demi-gods who can manage without it on a regular basis. I wouldn't turn any of them away either. But these folks have the experience, and the skills, to write code with whatever properties are desired, whether that's clarity and maintainability, efficiency, compactness, or finished-by-yesterday-ness. But not everyone can pull it off without some external help; using strict, using warnings, various coding conventions, -- that's what they're really good for, is providing that help.

<rant>You've got to be kidding me. If a potential employer handed me a test and said "You have 2.5 hours to complete this", I would walk out the door if I thought it would take me more than an hour. I have no qualms being verbally grilled and taking short written tests, but I would never take a 2.5 hour test.</rant>

I have performed several interviews and after talking with the person for 30-60 minutes I know what they know. My style of interviewing is a verbal test and discussion. It is very informal and allows for the answer to be presented in any way they feel comfortable (verbally, written, long explanation, or short answer).

I would walk out the door if I thought it would take me more than an hour.

Can't say I blame you. We hope/expect people to finish in an hour or less (when the first test was developed, I understand that the consultant who was the first to take it got done in about 40 minutes). But you can have 2.5 hours, in case you're having a bad brain day, or it's been a while since you've written Perl, or whatever. I wouldn't want to give (or take) a test that took that much effort, either; at that point it's not a test, it's consulting!

My style of interviewing is a verbal test and discussion. It is very informal and allows for the answer to be presented in any way they feel comfortable (verbally, written, long explanation, or short answer).

This is all I've ever done at past jobs, and I thought it worked well enough. And any candidate who comes in for an interview will have this sort of opportunity, as well.

I can't think off the top of my head why you wouldn't want strict vars in code you intend to maintain, but I'm sure there is a justification sometimes.

I would care about proper scoping of variables (which also implies using lexicals where lexicals ought to be used). "use strict" doesn't enforce scoping. It's not a magical wand. It's not a requirement to have proper scoping either. A program doesn't become bad (or harder to maintain) if you remove the "use strict" line for a good maintainable program, neither does a bad program become good by the introduction if a "use strict" line.

"use strict" is an aid but it's neither necessary nor sufficient to write good programs. I'd be hestitant to work for anyone who focusses on details, forgetting the overall picture.

Abigail

Good points. I think I haven't expressed myself very well. As I mentioned before, among the problems with our existing codebase is the fact that most of the data is stored and passed around via (undeclared) globals. This obviously makes the code very hard to understand and maintain. When I try to refactor a chunk of this, the way I start is a search and replace, driven by slapping a "use strict" at the top of one sub at a time, then on the top of the file, and I watch the compiler barf. Getting a clean compile after that doesn't mean the program is now perfect, but at that point at least I can get a better sense of the flow of data, which makes it possible to do more interesting refactorings.

"use strict" is an aid but it's neither necessary nor sufficient to write good programs.

In general, yes. Although there is a back-burner project to move a big chunk of the system into mod_perl, and IIRC from the last time I did that, any program that won't compile strict will have some problems when it is moved to a persistent environment.

I'd be hestitant to work for anyone who focusses on details, forgetting the overall picture.

Fair enough. In reality, there has to be a major subjective (Is it subjective? It's holistic, at least -- how much do my teeth itch when I read the code? How happy would I be if I had to maintain it? Would I want to rewrite or seriously refactor it first?) component to the evaluation of any hiring candidate. I don't see myself rejecting anyone because of any single, specific thing they wrote, or failed to write.

Thanks for your comments. You're helping clarify my thoughts on this.

"use strict" is an aid but it's neither necessary nor sufficient to write good programs. I'd be hestitant to work for anyone who focusses on details, forgetting the overall picture.

I was once "fired" from a short online web programming job for not using strict.

The guy who'd hired me was himself a Perl programmer, subcontracting this job to me because he had more work than time. I took a day or two to code up a prototype solution for him, and (due to the thinness of his original requirements IMHO) fired it off to him with a "how's this, is it something like what you need?"

He responded with an expression of horror that my code was missing use strict and use warnings. I was clearly unsuitable to perform Perl programming, for him or anyone else, if I didn't understand this basic principle.

I guess I would advise fellow Monks to use strict until and unless you know the boss feels otherwise, or trusts you to make the call.

Or, like Abigail, be prepared to NOT work for them.

--
Jeff Boes Database Engineer Nexcerpt, Inc.	vox 269.226.9550 ext 24 fax 269.349.9076  http://www.nexcerpt.com
...Nexcerpt...Connecting People With Expertise

If you feel like not being hired, here's one way :)

#!/usr/bin/perl -w
use strict;

print join("\n",
   grep{-f&&/\.foo\z/}map{<$_/*>}grep{-d}'.',map{"./$_"}<*>
), "\n";
[download]

GOLF?

`ls *.foo */*.foo`
[download]

Might wanna check $^O there first. :)