If you are interested in a job and want to pursue it, I think you should give it your best shot. People can mean an awful lot of things by such a statement and it is very hard to know in advance until you discuss the job with them.

As for me, if I were to say that in a job listing I would probably have in mind a job including some independent design work. I would want to have confidence that the person could design a viable object architecture.

I would feel especially comfortable if the person had done OO work in at least two different languages and could talk intelligently about how one implements different OOP concepts in each language. You can do OOP in almost any language, even C (the first C++ "compiler" was actually C preprocessor). Doing OOP in two different languages increases the likelihood that the person really understands OOP concepts and isn't confusing implementation structures with the underlying design theory. However, whether they knew OOP in one language or five, I'd be looking for how well the person knows how to manipulate each particular language to support OOP concepts.

If this is specifically a Perl project, I'd also like to see some background knowledge about the various ways Perl has historically approached OOP - everything from the OOP presentation in perltoot to inside-out objects(ugh) to Mouse and Moose. They wouldn't need to be expert in all of these approaches but they should understand their pros and cons and make a case for the particular approach they have to OOP implementation in general and also for specific kinds of applications. (e.g. Moose may be a good tool for some projects and a huge pile of not-so-useful dependencies for others).

Third, since reuse is an important part of OOP, I'd also be interested in how well the person knew the standard libraries for Perl and major Perl packages. That would include both functional and OOP packages because all play a role in reuse. It would be rather silly for someone to reinvent DBI or File::Spec or XML::Twig. unless they know the strengths and limitations well and could make a very good case for why our project couldn't just use those.

Fourth, I'd like to understand how they use design patterns in their OOP programming. Do they understand how those patterns affect program complexity? How do they assess maintainability of a design? How are they going to build in extensibility? OOP's can be a marvelous tool for managing complexity, but blind application of certain design patterns can also result in object architectures that look more like circuit boards than software.

Fifth, do they know where to stop when it comes to abstractions? There are strong arguments for not designing beyond requirements, but also strong arguments for taking the wider view. It takes wisdom and judgment to know where to draw the line. That often comes through experience applying OOP to a wide variety of problem domains and projects.

As for using existing CPAN code (other than well established modules), I'm not so sure I would consider that in itself a requirement. What I would be interested in is (a) how they would go about searching for pre-existing building blocks on CPAN and elsewhere (b) how they would go about assessing the fit between our requirements and a pre-existing component. Do they know the right right things to look for? The right questions to ask?

Update: added comments about design patterns and abstractions.