Hello perloHolic(),

I am really looking for specifics such as a minimum amount of required knowledge in certain areas...

We may take it for granted that to be a professional Perl programmer you must, first and foremost, possess the attributes required of any professional programmer: an ability to identify, refine, and clarify a software specification; a basic grounding in data structures and algorithms; deductive/debugging skills; a capacity for self-directed learning; and an appreciation for that elusive quality we call “elegance.”

To be a professional Perl programmer, you should, of course, add fluency in Perl to your general skill set. This means being able to implement programming solutions in Perl, but that by itself is not enough. As Ed Post famously said, “The determined Real Programmer can write FORTRAN programs in any language.”¹ When I first learned Perl, I wrote “Perl” scripts that were really C scripts in disguise. And that, by the way, is one of Perl’s great strengths: its TIMTOWTDI philosophy encourages learners to program in ways that are already familiar to them. In this way the learner finds he can be productive in Perl while still absorbing the more Perlish idioms. But a professional Perl programmer should be fully-conversant with Perl’s strengths, and should demonstrate this by writing elegantly “Perlish” programs. At a minimum, I would expect a professional Perl programmer to demonstrate these Perl-specific skills:

1. use of statement modifiers together with the $_ variable to write concise code
2. facility with map, grep, split, substr, and splice
3. understanding of context
4. facility with regular expressions
5. dereferencing, construction of complex data structures, and understanding of autovivification
6. use of hashes to perform common list-related tasks²
7. facility with core pragmas and modules: autodie, Benchmark, bignum, Data::Dumper, Test::More, etc., etc.
8. familiarity with sources of online reference: perldoc, , MetaCPAN (and of course bonus points for using the Monastery’s Super Search!)

But...

Job interviews aren’t always what they’re cracked up to be. At a company where I worked, management interviewed, then hired, a programmer who described himself as one of the top half-dozen C++ programmers in the world. He was later observed reading C++ for Dummies, and when he was eventually fired (surprise!), it was found that none of the code he had written even compiled.

At that same company, an Irish backpacker applied for a casual job as a junior programmer. She was given a C programming test — and she got every question wrong. But she was young and attractive, and the interviewer was a red-blooded Aussie bloke, so she got the job anyway. And proved to be an effective programmer and an asset to the company.

Go figure.

Anyway, hope some of that helps,

¹ “Real Programmers Don’t Use Pascal” (1982. See wikiquote#Fortran.)
² See e.g. “How can I remove duplicate elements from a list or array?” and “How can I tell whether a certain element is contained in a list or array?” in perlfaq4.

The answer to your question is simple: it depends. It depends on the position, on the job you'll do there. For example, if you were hired to maintain legacy CGI scripts running in Perl 5.8.3, knowledge of modern OO frameworks would not only be useless, but almost even an obstacle (that's my experience, at least).

On the other hand, I'd expect a junior programmer to be able to answer any question solvable with Learning Perl, and probably to know some parts of Intermediate Perl, too. What's more important for me is the interest - does they read any blogs, participate in contests, open-source projects, etc. But again, YMMV.

Thank you, but beg your pardon, YMMV?

I agree with your summation that of course the specific knowledge relates more or less directly to the proposed job and it's responsibilities. You did however stumble into the grey area that is rather plagueing me regarding the subject that is 'I'd expect a junior programmer to be able to answer any question solvable with Learning Perl, and probably to know some parts of Intermediate Perl, too' - what exactly determines whether knowledge I have, or anyone else for that matter is of a beginner, intermediate or advanced nature? what I may find or define as 'simple' may not be to others perhaps, I don't know, I might just be speculating?

I added the second paragraph after some hesitation, because the first one seemed too short to me, and I had a feeling it didn't answer your question fully. In practice, the judgment on the "level" would probably be business dependent: how much time the other colleagues have to teach the newjoiner the stuff he doesn't know? How fast is he in understanding new stuff?
لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

Your Mileage May Vary.

--MidLifeXis

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.

Nowadays I am programming assembler allowing Perl to help me a great lot of deals.

Plus, I am using Perl while on the road - doing my own hobby tasks.

Welcome to the club :)

Thank you vkon

I too use perl 'professionaly' and my job is not related to perl either, i use it in much the same way as you, to make quick work of tasks both simple and complex. I do find perl lovely to use, hence why I seek to gain employment in a job geared toward it's use, for personal enjoyment and knowledge growth purposes

As I replied to choroba's fine comment, this is where i'm failing to understand where the definition lies between me using perl in my current job, and knowing sufficient knwoledge of Perl for an actual career in it.

Take my current employment for example, I had to take a test in order to get an interview, which looking back asked me to demonstrate the basic knowledge of OO programming, structure, polymorphism and algorithms. This I didn't find too challenging as I had recently graduated from University, and this sort of task was commonplace during my studies. So hypothetically, what would a test be aimed at for a junior Perl programmer would you think? Similar programming fundementals,regardless of language like my current positions test, or things more specific to Perl itself perhaps?

So hypothetically, what would a test be aimed at for a junior Perl programmer

I'd say so. Senior roles involve not only deeper understanding of the tools (i.e. Perl), but also the broader view: understanding of the business, leadership skills, etc. Participating in a project with 100+ developers, automatic builds, issue trackers etc. is quite different to writing super clever solutions to HackerRank problems.
لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

"...my current job as a C language software Engineer."

As i started relatively late with programming in general and with Perl (my second programming language) i feel qualified to put in my two cents.

Some bros gave some more detailed advice above - so i'd like to add some general hints:

You mention that you got some knowledge in C: that is IMHO a good background.

As you may have noticed there are three basic things that work in Perl as in any other imperative language:

• Assignment
• Conditional
• Control flow

You know this already, no need to worry about - Perl isn't so different ;-)

Some say one of the worst things one can do is writing Perl and thinking C (in your case).

I think this is only partly right. No one can live down his roots.

For example: a Java programmer writing Perl will have a Java accent for years a.s.o.

Compare this to learning a real language: it may take years to get rid of an accent. Most learners have one all their life.

There are some things you can do to get around this problem:

1. Write your own Perl code
2. Read other peoples Perl code
3. Start over with step one

There are some other perlish things to become accustomed with like magic, context, scoping, refs, the idea Perl has about data types a.s.o.

A source of wisdom is CPAN. Study code made for real problems, see how things are done perlish and try to get a feeling for the language.

The idea is: Try to understand some ideas and concepts of Perl instead of learning a kind of a "canon" of Perl basic skills or so called "required techniques".

And being able to answer as many as possible questions from some books doesn't IMHO help you in real life. This is just tab knowledge. You need ideas, creativity, some patience and the man pages for the modules you use.

Best regards, Karl

P.S.: And as you are not a beginner in programming, you should really read the Camel Book, best in parallel to your studies.

Thank you very much for your input Karl, and those thanks also extend to everyone else who has given input throught this meditation. It always helps to talk these things out, and as I have no one else to discuss these kinds of issues with, I really appreciate everyone being here and giving there honest opinions and experiences

There are points here made especially by Athanasius, Your Mother, Chroba and karlgoethebier that have added real value toward my enlightenment, as well as other honourable mentions of which I cannot upvote I'm afraid as I am only allowed two votes. Of course this does not solve my problem by any means and any more comments are of course welcome!!

In a short and intermediate conclsuion - It would appear that many suggestion of what one should know and how one should go about learning have highlighted my naivety as I expected they would, so this has at the very least pointed me in the right/next direction of studies and I couldn't ask for more from you guys and gals, so thank you all.

"...I am only allowed two votes."

Stay on board and you will get some more votes ;-)

"...I couldn't ask for more..."

I don't see any serious reason why you shouldn't ask for more. PM is made for asking.

Thank you very much for your kind reply and best regards, Karl

P.S.: When worse comes to worse see Is guessing a good strategy for surviving in the IT business? ;-) For some more serious inspiration see intuition and Zen in the Art of Archery. And keep in mind that intuition grows out of repetition (AKA practicing). This applies for any skill.

«The Crux of the Biscuit is the Apostrophe»

Q: What 'should' a professional PERL programmer know?

A: How to spell "Perl".

What I look for, when interviewing, is a clear sense that the candidate has ... and has an interest in ... “more than just Book Larnin’” about the tool(s) that the project will use, whether that tool is Perl or not.   I look for the ability to understand a problem in light of how that problem might be solved (“using Perl” or otherwise ...) as well as a sensitivity to the potential issues (“hardware/software” or otherwise) that might work for or against any particular approach.

I want to find people who not only understand these contexts, but who can speak to them ... and, speak diplomatically.   Persuasively.   While also being quick-and-willing to be persuaded.   When someone is presenting another idea, are they looking for the first chance to interrupt (or, to talk over them), or do they seriously listen?   Then, is the first thing that comes out of their mouth an immediate counter-point (which they had simply been bottling-up, having stopped listening many seconds before), or, is it a thoughtful question?   In an interview, I try to un-obtrusively set up those dynamics, and observe what happens.   I’ll bring in other team members and have them discuss with the candidate something (non-confidential) that we are actually working on at the time.

Usually, I am not looking so much for “well-developed competencies” as “humility and the willingness to learn.”   I want to assemble a team of people who really can play as a team, and I want that team to build-up all of its participants through knowledge-sharing.   I don’t need one super-star.   I can teach anyone anything they need to know about dealing with ... the computer.   That’s easy.   (You mostly learn all this stuff on-the-job anyway.)

A real problem in this business is that you encounter people who are so supremely confident of their own abilities ... which confidence might well be well-placed(!) ... that no one can correct them or even speak to them.   They’ve done amazing things, single-handedly, but no one else was there.   There was no one else in the room except the client who (at the time, at least) trusted them implicitly but never questioned them.   Therefore, they aren’t used to being questioned or challenged, or for seriously testing their own code.   (Nor anyone else’s, because they never encountered anyone else’s.)   They don’t plan ... they can’t.   They just start writing.   Ask what they are doing and they look either impatient or insulted or both.   Usually both.

“Perl super-stardom?    Naahhh.   To the right person, I can teach that, in short order.

“What should a professional programmer know?”   First and foremost:   how to be a consummate professional.

“Perl super-stardom? Naahhh. To the right person, I can teach that, in short order.

This implausible claim appears to confirm the veracity of your earlier guidance:

A real problem in this business is that you encounter people who are so supremely confident of their own abilities. They’ve done amazing things, single-handedly, but no one else was there.

This implausible claim

Actually it's not an "implausible" claim at all - it's basically like the "no true scotsman".

If there is a person he is not able to teach then that person was not the right person and does not disprove his claim of teaching superstardom :-)

A real problem in this business is that you encounter people who are so supremely confident of their own abilities ... that no one can correct them or even speak to them.

Indeed!

Of all things that which is the most important skill for any programmer to develop is that of humility.

As far as Perl goes...
Firstly, write for maintenance, use strict/warnings all the time and just because you can do it in 1 line doesn't always mean you should. There are 2 people you care about when writing any program, yourself at 4am and yourself 6 months from now. Perl as lovely as she is can be a cruel mistress when you're half-awake... If you write well tested code that meets requirements you will make those 2 people happy and as a by-product everybody else that will eventually touch your code as well.

Learn regular expressions and EVERYTHING about them, from back-references to the meta-characters and symbols and all their little nuances as what is most efficient, as to when they will be compiled, or when they will be recompiled. Also learn what your best practices are as far as readability of those regular expressions and most importantly write test-cases for your regular expressions. Tests that succeed, tests that fail, and tests that do nothing (aggravatingly enough that happens plenty).

Lastly, and this has nothing to do with perl, just a general tip for anybody that is younger and starting out in a programming profession. Make sure that your office setup is as ergonomic as possible, carpal/cubital tunnel is a bane for those of us who have been doing professional computer work for many years. Find yourself a great ergonomic keyboard, ergonomic mouse, keyboard tray, chair, etc..., and don't forget to take a break every now and then. I've had carpal tunnel surgery on both wrists and will probably need cubital tunnel surgery on my left elbow and I'm still in my 30's. Take it for what you will, we all get older, time takes it toll no matter how good you feel now. :)

Thank you for that very inciteful answer. It is not often I get the opinion of someone from the opposite side of the interview table!

While your approach to the hiring, or not hiring of a candidate is something akin to my approach of things, I regret to say that I think that is sadly not always the approach taken. I sometimes feel that in interviews, the interviewer tries their best to out-tech me as soon as possible to give themselves the higher ground, but again that's just my opinion, and certainly not of ALL my interview experience.

I will certainly take into account your perception/opinion upon my next interview, If I am to get to that stage, as I'm still to receive feedback. Trying to pass the test is my first hurdle, who knows if i'll even get in the room! :)

So just a quick summation of your statement then - You value a persons attitude as opposed to their expereince, taken into account that the individual has already 'passed' a formative evaluation that they hold the necessary technical skills to learn what you have to teach?

FWIW, concerning the other side of the table—I’ve sat on hiring committees 10 or 12 times while working at two Fortune 500 companies and I disagree with almost everything sundialsvc4 said above.

The person you responded to is the least qualified person on the forum to give advice about programming (of any kind), computing or career path. See Worst nodes and their post history on their homepage for example.

As Your Mother points out, every company is different, and so my perspectives and opinions are ... well, just that.   In fact, the larger the company grows, the more rigorously-defined is the makeup and actions of “hiring committees,” who to their credit are often faced with a lot of candidates.   I do not work in that world, and never have.

And, yes, there are always interviewers who are going to “try to out-tech you.”   It is just as impossible to characterize how an interview(er) might go, as to characterize any other behaviors of real people.   All that I can express is what drives me, personally ... and, to a lesser extent, those of the committees that I have been part of.

Obviously, any technical position presupposes a certain amount of basic familiarity with the tools and techniques that are being used in the shop.   “We’re not running a school here,” even though you did hear me using the word, “teach.”   Some baseline competency and understanding is needed.   But I don’t necessarily want someone who is hip-waders deep “in Perl,” who has done nothing else in his life than “Perl,” who interjects how great he thinks “Perl” is, and especially who’s just a little too-quick to tell me how great he is.   Someone who has worked with a cross-section of tools beyond “Perl and JavaScript” will certainly draw my eye.   Someone who sees the fact that there’s Python and Java and a little C-sharp going on, and who seems glad to hear about that, will do the same.   A long-winded answer to, “so, which is better ... waterfall or agile?” won’t win points, especially if you produce a bible.

Full disclosure:   I have never, ever, hired at “entry level.”   Consider these comments (or, throw darts at them) accordingly.

I personally try to sense, “greatness without attitude.”   Where I feel that I can give this person a piece of work to do ... ideally, not in exhaustive pre-digested detail ... and know, not only that he will do a good and competent job, but that he will freely share what he is doing with the others and will work with the others so that the entire team reaches a mutual goal, and none of them rest until all the tests (including all the new ones) run clean again.   I need strong players, sometimes very strong, but they must be players.   Ability, professionalism, but not ego.

But, again ... that’s just me.   Hiring is a very tough thing to do, and everyone does it more-or-less differently.   This is my Humble and not one whit more.

A real problem in this business is that you encounter people who are so supremely confident of their own abilities ... that no one can correct them or even speak to them.

You just described yourself perfectly.