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.

As someone who has done a bit of both 1 and 2, I am just curious at to what professionals and/or hiring managers are expecting when they ask for experience in OO(Perl or otherwise).

I wouldn't worry about such requirements in a job ad. If you want to apply and you think you've such knowledge, just apply. If they are interested in you, and want their proof, it'll come up in the process. They may discuss at an interview, they may ask for some code you've written, or perhaps they'll ask you to code something.

OTOH, prices and classroom grades are not the only instances of inflation. The need for bushel baskets of [insert dis-favored currency here] to buy a loaf of bread pales beside the qualifications poised by some job opening annoucements:

Junior Developer. Perl, C, mumps. Demonstrated competence in other languages a plus. Must be known world-wide for innovative OO solutions and familiar with HTML 5.0 and CSS 3. Prefer a candidate who has contributed at least 5 standard open source programs or modules. Full time (60 hours per week; we don't give a damn about wage and hour laws), on-site; competetive salary beginning at minimum wage. Respond with complete CV, evidence of TS security clearance (US), source code for at least 2 significant programs and the left thumb of your firstborn (alternate: blank, signed check).

Perhaps your "bit of" is overly modest; perhaps a potential employer will be well-satisfied by that and your skills & attitude. So the best I can suggest is -- go for it... but keep your investment on the low side until an employer demonstrates that it's offered a position worth having.

The short answer is that you really have no idea.   Certainly, the presence of Moose (and of the companion “MooseX” packages) makes this type of question very ambiguous.   It could mean any number of things.   Which means that you basically need to apply salesmanship, and to be well-prepared with considered responses for a variety of scenarios (as well as exploratory questions to help you gage what the term actually means to them).

The “least common denominator” definition is probably a good place to start, as described in perlmod and the very-many similar perldoc documents.   The notion, even in its most elementary and earliest implementations, of useing a package, instantiating a Perl object defined in that package, and of making method-calls to it.   Being able to “spew the technical guts of how” to do this, is likely to be much less important than “knowing why and when” it is advantageous to do this.   It is okay to speak in fairly abstract, conceptual terms during an initial interview.   It is also okay to say very frankly that you need to research a concept that they bring up ... much better than trying to bluff, which never works.   If they start hammering you with demands for technical-spew details regarding something that you truly are not prepared to answer, the best thing to do is to be very straightforward to the effect that “I don’t know, but I can find out, and here is something that I do know which might be relevant...” “I don’t right-now know exactly what you are referring to, but I do know that I do know what I’m doing, nonetheless.”   Don’t let anyone make you sweat or lose your cool, even if they attempt it, as they sometimes will.