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.