I really doubt this is unique for Perl though.
Unit-testing is a bit less forgiveable.
edit: also it depends on what type of programming you're supposed to do. This particular case was for web development, and in that world I would say OO is quite a fundamental concept.
Of course, the answer is "by utilizing experience of others" or "comparing my efforts to others' efforts".
That's how progress works, I was told.
Sorry, I was not very clear in my first post. The job was advertised clearly being on a web system, looking for experienced developers. I don't have a copy of the ad any more, but I'm quite sure it specifically stated OO as wanted experience.
My main point with the first post was to highlight the disconnect between the level they graded themselves at, and the level at which they actually were. If I'm talking with someone claiming to be an experienced Perl web developer, I'd expect, among several things, they would have OO experience.
(If anyone's interested in the end of the story -- we gave up on trying to find a senior person, and instead went with a guy who did not have much experience at all, but came across as very keen to learn. It worked out very well).
edit: oh, now I have a "reply" link under Nicks post. oh well, too late.
Formlets: http://hackage.haskell.org/package/formlets and then http://groups.inf.ed.ac.uk/links/formlets/
Does he still need to be proficient in OO?
What if your candidate knows much about your current problem domain? Do you still prefer someone who doesn't know a bit but proficient in OO?
Actually, I specifically searched for a language that wasn't OO but provide all the benefits of OO when I found Haskell. The standard library back then was about twenty or less modules.
I don't really match against most of my colleagues right now, they done much more OO than me.
So, until recently I was really competent programmer with Haskell experience in useful programs that hadn't done OO. ;)
Good knowledge in some other area would have made it a lesser issue that they didn't have OO experience, but they were generally lacking knowledge across the board.
Your proposed salary was low, your offering uninteresting, etc.
Myself, I crossed Perl and Python (and Ruby, and Smalltalk, and Lisp and many others) from list of languages to discriminate good programmer from not so good one a long time ago. They just did not get used in anything I consider interesting or important (but I still prefer domain knowledge - so lisper with relevant past is still interesting).
Right now I would use Haskell (or even stronger typed language like Coq or Agda) as a requirement, and my proposal would include DSeL for problem domain with Perl backend (if Perl is that necessary).
I will get much less resumes initially, those resumes will be of higher quality and my employee will produce a tool that allow me (us as a team, actually) to retarget our product to another backend quickly if we need to do so.
Well given the current landscape of programming, yes, it does make them very bad programmers. If you haven't explored the most common programming paradigm, you're a bad programmer, or a 1st year student.
Would you say that someone who has been coding embedded systems for 30 years in assembly and minimalist C is a bad programmer just because they've never done OO? Despite the fact that for what they're doing it might be a bad choice, and they've specialised into an area that is vastly different from what you might expect as the norm?
If all that's been doing for 30 years, then probably, yeah. They might be good at their job, but an overall good programmer? Maybe they were great 30 years ago, but if they haven't raised their head to look around at the evolution in the industry and kept up with newer trends and developments, the level of skill atrophy would be quite large.