in reply to Re: Technical Interview
in thread Technical Interview

Out of curiousity, what do you do when the person hears your first question, and responds, I know you want me to talk about list context, but before we get to that, unless you really mean to have implicit argument passing, it is a good idea to avoid using the &func syntax. In fact even if you do, I prefer writing that as func(@_) for clarity...

Also what you should ask depends on context. Personally I avoid asking "Perl trivia". I would prefer to take a good programmer and teach them Perl than to try taking a Perl expert and teaching them good programming. (Getting someone who doesn't need teaching is, of course, preferable.) Given that I prefer to ask questions on strategies, algorithms, see them write some code I can go over for style, etc.

Replies are listed 'Best First'.
Re (chip): Re3: Technical Interview
by chip (Curate) on Dec 29, 2001 at 08:54 UTC
    Well, I only used the &foo syntax for clarity of expression: "&foo" is the one and only name of the function "foo", while foo() could refer to an operator. When teaching or explaining about function calls I think it reasonable to use the ampersand. In real code, of course, I avoid ampersands whenever possible.

    But to answer your question: I'd probably smile broadly and hire the candidate on the spot. If there was no hurry, I would first indulge in a thoroughly enjoyable argument over how attempts to improve readability can break things by accident. (Contrary to popular folklore, &func is not synonymous with func(@_); the former shares a single @_ array, while the latter makes a temp copy that disappears when func returns. Don't feel bad if you didn't know that; I actually caught TheDamian in the same mistake at TPC5.)

    It's certainly true that a good programmer is a good programmer no matter his background. But background can take time to overcome, and some habits are difficult to unlearn. A really good programmer must grok his tools, above all his language. I was hired in my current job to mostly code Python (ack! spit!); I thought for sure I'd have no problem with it, but it's taken a few months to get get to the point where coding in Python isn't like translating English to Spanish word for word. (Which, incidentally, sucks.)

    UPDATE: Fixed usage of the word "latter", per tilly's kind correction.

        -- Chip Salzenberg, Free-Floating Agent of Chaos

      Don't feel bad if you didn't know that; I actually caught TheDamian in the same mistake at TPC5.
      Well, it's certainly true: chip did indeed catch me out at TPC5. And in front of 400-500 people!

      Though in fairness, my mistake occurred in SelfGOL: quite possibly the most complex 1000 bytes of Perl ever written.

      But it wasn'tbecause I was unaware of the @_-sharing nature of &foo. In fact, the code in question deliberately abused that feature. I messed up because I (carelessly) relied on the behaviour once to often within the same block.

      Nevertheless, I was very grateful to chip. His correction encoraged me to make SelfGOL even more diabolical. As indeed has this thread.

      >;-)

        Damian is right about SelfGol; it is excruciatingly diabolical. It evidences a skill in Perl compression and obfuscation far beyond my own. My work with Perl has mostly been under the hood, so to speak. Knowing your car can help you be a good driver, but it won't turn you into Evel Knievel. Damian's coding stunts left his TPC5 audience, myself included, in awe.

        But more basic forces were also at work that day. As every teacher learns, nothing quite motivates a roomful of students to cleverness like the thrill of catching the teacher in a mistake.

        Come to think of it, Damian mentioned early in that very presentation that he had recently enjoyed catching Jeffrey Friedl--regex guru nonpareil--in a regex error. Did Damian's own anecdote plant a seed in my mind, which then bore fruit when I noticed his error? Who can know....

            -- Chip Salzenberg, Free-Floating Agent of Chaos

      I actually did know that, as is evidenced by the fact that I knew without looking at documentation that the right correction to what you wrote is s/latter/former/. :-)

      (ie &foo shares @_, foo(@_) does not.)

      Those who didn't know this should check out perlsub, or if you don't want to think carefully about consequences, the excellent summary at (tye)Re: A question of style. (Hrm, glancing at it a current version of perlsub gets it right twice, but the comment in the code sample is misleading.)