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.