Most people here are polyglots and we generally let you code in what you know and evaluate you based on that. For a perl heavy person, I'd demur and get someone else to do the coding bits and I'd throw algorithm problems. OTOH, I'm all over the nooks and crannies if you claim to know Java or C++ (or HTML or CSS for that matter).
As for OO, mostly we're talking theory and I usually ask for a model of a domain that may or may not have inheritance in it (your call). I also tailor the OO questions to the language you know best. So I don't ask J-heads about virtual functions or virtual inheritance, but I'm all over that if you say you know C++.
Perl is a big (and key) language - it would be a plus but polylinguist are much preferred over single language people for obvious reasons (one trick ponies only know one trick is pretty true I've found).
As for drew's assertion about the database being key - there is very little database work and the average developer doesn't work with one. The architecture is unique and for practical purposes, for most developers there is no DB and CRUD means nothing in this environment.
"And if you need to think hard about how much memory you're using, then Perl was really the wrong language to use.)"
Oh, I don't know. A well used pattern is big chunk of rigid machinery (C/C++ libraries) controlled flexibly from little scripts that are easy to modify (Perl in this case). But again, you can't get by knowing only one language.
I came into programming similarly. I got my OO sense from being a stack head (Hypercard) before moving on to "real" languages like F77, then C, and C++. I'm pretty much a petroleum engineer with awful career timing.