Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: How to measure Perl skills?

by Abigail-II (Bishop)
on Mar 22, 2004 at 23:48 UTC ( #338843=note: print w/ replies, xml ) Need Help??


in reply to How to measure Perl skills?

Ideally this would be something that a reasonably skilled developer could finish in 30-60 minutes, that would demonstrate an understanding of, and comfort with, strictness, lexicals, modules, objects, and references.

30 to 60 minutes isn't much if you all want to test this. It's also way too short to get familiar with the horrible code you are describing. You also mention usage of strict several times in your post. Don't stare yourself blind on that. "use strict" is an aid, but a defensive one. Like safety belts. You wouldn't judge the quality of a driver on whether he wears safety belts or not (and while you may demand that a driver wears a safety belt if you hire him, his driving won't improve). You also might miss out on great coders like Damian, who seldomly uses strict.

I once got to do a programming test while doing interviews. A simple test: list all the files in the current directory, or any subdirectories (no deeper than one level) that end in '.foo'. Don't use the File::Find module. There's a white-board, here's a pen. Go ahead, write it, and explain what you are doing. Believe me, what I said was far more important than what I wrote.

I'd say, if you make a test, keep the test simple. Don't solely judge the result, look how the candidate reaches the result. Let the candidate talk.

Abigail


Comment on Re: How to measure Perl skills?
Re^2: How to measure Perl skills?
by Anonymous Monk on Mar 23, 2004 at 08:05 UTC

    If you feel like not being hired, here's one way :)

    #!/usr/bin/perl -w use strict; print join("\n", grep{-f&&/\.foo\z/}map{<$_/*>}grep{-d}'.',map{"./$_"}<*> ), "\n";
Re: Re: How to measure Perl skills?
by tachyon (Chancellor) on Mar 23, 2004 at 18:47 UTC

    GOLF?

    `ls *.foo */*.foo`

    cheers

    tachyon

      Might wanna check $^O there first. :)
Re: Re: How to measure Perl skills?
by optimist (Beadle) on Mar 23, 2004 at 19:14 UTC
    Sorry, I wasn't clear. The 30-60 minutes would be in addition to the original test of modifying the existing app; they get 2.5 hours for that.

    I do like the idea of having the candidate just write on the whiteboard and explain. With a suitable problem (yours feels like the right level of complexity), I could possibly convince the powers that be to dispense with formal, written test.

    You also mention usage of strict several times in your post. Don't stare yourself blind on that. "use strict" is an aid, but a defensive one.

    Yes and no. I don't think anyone expects one-offs, especially of the perl -pi -e... variety, to be strict, and there are definitely good reasons be unstrict sometimes. But IHMO there should be a reason -- symbolic refs are useful when constructing accessor methods, or doing some kinds of dispatch; barewords have their place occasionally; I can't think off the top of my head why you wouldn't want strict vars in code you intend to maintain, but I'm sure there is a justification sometimes. Regardless, it seems to me that the programmer should make a concsious decision to relax those restrictions, because by default restrictions support other properties, e.g., modularity, loose coupling, separation of concerns, etc., that promote maintainability. And that's a big part of what I care about.

    Like safety belts. You wouldn't judge the quality of a driver on whether he wears safety belts or not (and while you may demand that a driver wears a safety belt if you hire him, his driving won't improve).

    Actually, I would judge a driver on that, depending on what I was judging him for. If I wanted him to drive my race car, perhaps not, but if I wanted him to drive me around, definitely. Because seat belts are a massive safety improvement, and these days, deciding not to wear one is tantamount to admitting you aren't concerned with safety.

    You also might miss out on great coders like Damian, who seldomly uses strict.

    Certainly, Damian is infinitely more skillful than I, and yeah, he'd be great to have! There are plenty of other Perl gods and demi-gods who can manage without it on a regular basis. I wouldn't turn any of them away either. But these folks have the experience, and the skills, to write code with whatever properties are desired, whether that's clarity and maintainability, efficiency, compactness, or finished-by-yesterday-ness. But not everyone can pull it off without some external help; using strict, using warnings, various coding conventions, -- that's what they're really good for, is providing that help.

      <rant>You've got to be kidding me. If a potential employer handed me a test and said "You have 2.5 hours to complete this", I would walk out the door if I thought it would take me more than an hour. I have no qualms being verbally grilled and taking short written tests, but I would never take a 2.5 hour test.</rant>

      I have performed several interviews and after talking with the person for 30-60 minutes I know what they know. My style of interviewing is a verbal test and discussion. It is very informal and allows for the answer to be presented in any way they feel comfortable (verbally, written, long explanation, or short answer).

        I would walk out the door if I thought it would take me more than an hour.

        Can't say I blame you. We hope/expect people to finish in an hour or less (when the first test was developed, I understand that the consultant who was the first to take it got done in about 40 minutes). But you can have 2.5 hours, in case you're having a bad brain day, or it's been a while since you've written Perl, or whatever. I wouldn't want to give (or take) a test that took that much effort, either; at that point it's not a test, it's consulting!

        My style of interviewing is a verbal test and discussion. It is very informal and allows for the answer to be presented in any way they feel comfortable (verbally, written, long explanation, or short answer).

        This is all I've ever done at past jobs, and I thought it worked well enough. And any candidate who comes in for an interview will have this sort of opportunity, as well.

      I can't think off the top of my head why you wouldn't want strict vars in code you intend to maintain, but I'm sure there is a justification sometimes.
      I would care about proper scoping of variables (which also implies using lexicals where lexicals ought to be used). "use strict" doesn't enforce scoping. It's not a magical wand. It's not a requirement to have proper scoping either. A program doesn't become bad (or harder to maintain) if you remove the "use strict" line for a good maintainable program, neither does a bad program become good by the introduction if a "use strict" line.

      "use strict" is an aid but it's neither necessary nor sufficient to write good programs. I'd be hestitant to work for anyone who focusses on details, forgetting the overall picture.

      Abigail

        Good points. I think I haven't expressed myself very well. As I mentioned before, among the problems with our existing codebase is the fact that most of the data is stored and passed around via (undeclared) globals. This obviously makes the code very hard to understand and maintain. When I try to refactor a chunk of this, the way I start is a search and replace, driven by slapping a "use strict" at the top of one sub at a time, then on the top of the file, and I watch the compiler barf. Getting a clean compile after that doesn't mean the program is now perfect, but at that point at least I can get a better sense of the flow of data, which makes it possible to do more interesting refactorings.
        "use strict" is an aid but it's neither necessary nor sufficient to write good programs.

        In general, yes. Although there is a back-burner project to move a big chunk of the system into mod_perl, and IIRC from the last time I did that, any program that won't compile strict will have some problems when it is moved to a persistent environment.

        I'd be hestitant to work for anyone who focusses on details, forgetting the overall picture.

        Fair enough. In reality, there has to be a major subjective (Is it subjective? It's holistic, at least -- how much do my teeth itch when I read the code? How happy would I be if I had to maintain it? Would I want to rewrite or seriously refactor it first?) component to the evaluation of any hiring candidate. I don't see myself rejecting anyone because of any single, specific thing they wrote, or failed to write.

        Thanks for your comments. You're helping clarify my thoughts on this.

        "use strict" is an aid but it's neither necessary nor sufficient to write good programs. I'd be hestitant to work for anyone who focusses on details, forgetting the overall picture.
        I was once "fired" from a short online web programming job for not using strict.

        The guy who'd hired me was himself a Perl programmer, subcontracting this job to me because he had more work than time. I took a day or two to code up a prototype solution for him, and (due to the thinness of his original requirements IMHO) fired it off to him with a "how's this, is it something like what you need?"

        He responded with an expression of horror that my code was missing use strict and use warnings. I was clearly unsuitable to perform Perl programming, for him or anyone else, if I didn't understand this basic principle.

        I guess I would advise fellow Monks to use strict until and unless you know the boss feels otherwise, or trusts you to make the call.

        Or, like Abigail, be prepared to NOT work for them.

        --
        Jeff Boes
        Database Engineer
        Nexcerpt, Inc.
        vox 269.226.9550 ext 24
        fax 269.349.9076
         http://www.nexcerpt.com
        ...Nexcerpt...Connecting People With Expertise

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://338843]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2014-07-30 22:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (241 votes), past polls