choroba, Athanasius, and anonymonk (it’s Perl not PERL; and the executable is perl) gave some good guidance. I would add 0.5 to Athanasius’s list -> scoping and datatypes. Seems simplistic but I’ve seen soooo much code in the wild written without understanding it and it makes cleaning up or extending complicated code much more difficult than it should be.

Really the question(s) you’re asking comes down more to experience, I think. Practical experience doing things with Perl is more useful and ramps you up faster than reading and tinkering. So here are some things that helped me go from n00b leaving disasters for the next dev to superfly MC picked first for all rounds of dodgePHP–

• Answer questions here. It’s easy to get things wrong. Trying and failing is a better experience than intellectually touring a problem. You probably won’t fail the next time. Trying to explain a problem is one of the best ways to understand it and have the answer materialize on its own: http://en.wikipedia.org/wiki/Rubber_duck_debugging.
• Read test suites on the CPAN; they are almost always in the /t dir of the source. Tests often exercise and unravel code better than the documents do. Seeing how another programmer minimally uses her own code can be revelatory. Writing tests will make you a better programmer and is a kind of good hygiene habit.
• Get a github account and fork and attempt to patch something. Volunteer for something like Take the 2015 CPAN Pull Request Challenge. The second you’ve had a pull request accepted you’re “in the club.” :P
• Then try wrapping up some of your own project/hobby/work-utility code in a module or a modulino. Try to make it a formal distribution; even if just for github and not the CPAN. The formality of process is part of what can make someone mediocre at CS but experienced in Perl a better bet than a CS MS new to Perl. The dues paying and understanding the ecosphere adapts you to do Perl well and easily.
• Have fun! When you are having fun, the time will fly and the experience and expertise will materialize before you realize it.

I think your actually question had little to do with getting hired but to that point I’ve found even minimal participation in FOSS is a big leg up in most technical hiring decisions; especially for junior level roles.