http://qs321.pair.com?node_id=1112771


in reply to What 'should' a professional PERL programmer know?

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.

  • Comment on Re: What 'should' a professional PERL programmer know?

Replies are listed 'Best First'.
Re^2: What 'should' a professional PERL programmer know?
by eyepopslikeamosquito (Archbishop) on Jan 10, 2015 at 03:59 UTC

    “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 :-)

        Damned Perlmonks! They ruined Perlmonks.org!!

Re^2: What 'should' a professional PERL programmer know?
by Anonymous Monk on Jan 09, 2015 at 16:09 UTC
    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!

Re^2: What 'should' a professional PERL programmer know?
by tully (Initiate) on Jan 13, 2015 at 15:23 UTC

    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. :)

Re^2: What 'should' a professional PERL programmer know?
by perloHolic() (Beadle) on Jan 09, 2015 at 16:29 UTC

    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.

        Okay, fair enough ... care to elaborate for our friend?   What do you encounter and do?   What’s important to your teams, your decisions, your big-Co?   What directives does HR and so-forth hand to your team?

      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.
      A reply falls below the community's threshold of quality. You may see it by logging in.

      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.

        What they point out is that you are the least qualified person to give advice about Perl or programming using on the forum. Worst Nodes and your posting history are testament to this fact.
Re^2: What 'should' a professional PERL programmer know?
by Anonymous Monk on Jan 10, 2015 at 08:20 UTC
    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.