http://www.perlmonks.org?node_id=338823

My employer is trying to hire another programmer to join me in the shop here (which I would really like). The CTO strongly believes that any strong candidate who passes the interview should be required to pass a programming test before we make an offer. Having seen some of the code written before I got here, by people who they didn't test, I can't argue too much.

Now when I took this job, the test was to make a small modification to a medium-sized web app (about 5200 lines in 10 files). This app is pretty horrible -- subs are several hundred lines long, it uses no modules other than DBI and CGI (and that only for parsing POST params), and all data is passed around via global variables; no data is more complex than a simple hash. It does not use strict. It is, unfortunately, representative of the bulk of our code base, so being able to figure out its behavior well enough to make the requested modification is a pretty good test.

But I've been trying to advance the state of the art over the last year, and all my new code uses CPAN modules as appropriate, is mostly OO, runs clean under strict and warnings, and generally doesn't make me feel icky. In other words, it looks like Perl5. So I've been asked to develop an additional test that will allow candidates to demonstrate their skills along these lines.

I'm finding I don't have a good idea of how to proceed. 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. I'd appreciate any thoughts on how to construct such a beast, or references to any such tests. Thanks!

Replies are listed 'Best First'.
Re: How to measure Perl skills?
by Abigail-II (Bishop) on Mar 22, 2004 at 23:48 UTC
    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

      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 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

      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";

      GOLF?

      `ls *.foo */*.foo`

      cheers

      tachyon

        Might wanna check $^O there first. :)
Re: How to measure Perl skills?
by perrin (Chancellor) on Mar 22, 2004 at 23:36 UTC
    Ask them to bring a code sample and then have them walk you through it and explain what they are doing in this code. That will give you a good idea, and probably tells you more than a simple test.
      I agree. The only way you can clearly establish a coders credentials in a short amount of time is to look at their portfolio. See what work they've done in the past, if it's up to snuff, and have them explain what they did and why. (People might not use strict; for a reason -- i.e. they inherited a code base like yours. Best if they explain themselves and you don't jump to conclusions -- you might pass over a great coder!).

      Want to support the EFF and FSF by buying cool stuff? Click here.
        This isn't exactly fair if they have mostly commercial work that they cannot share. I know this is true of me -- I want to code in my spare time, but 50 hrs a week of staring at a monitor is usually enough for me.

        I think the best is to measure analytical skills, ask them to walk you through a previous design, or so on .. or maybe ask them to explain one of your Perl programs.

        But don't get TOO technical. I had a few interviews from PhD types who thought they were Gods gift to computer science (giving a bunch of problems they thought were clever, but really weren't -- and then made up arbitrary restrictions to limit my ability to solve them through 'normal' means). They rubbed me the wrong way, were full of themselves, and I wouldn't have wanted to work for those sort of elistists.

        So it comes down to ... (1) can they work and play nice with others, and (2) can they think on their feat and do they have a general grasp on good design, and (3) I think it's perfectly fine to ask if they understand closures and lexicals. You see, this is what distinguishes a basic hack-and-slash 'scripter' from someone who is into the stuff from a programming perspective. Maybe. Just don't become that PhD jerk who thinks he is smarter than the interviewee. Intimidation does nothing for anyone, and will problably just make your subject feel uncomfortable.

      We do this, too, if the candidate has something they can show us. As someone else mentioned, this isn't always possible.

      For what it's worth, we had someone come in a few weeks ago. Their code sample was pretty good, but there were things I'd have done differently, and, I think, better. But when he explained the code to me, not only was it clear he'd thought carefully about how it was supposed to work, but he had a solid explanation for every design decision. Based on that interview, I thought he should get an offer right away, test be darned. Sadly, after driving down for that, he decided that he didn't want to take on the commute that working for us would require.

      And even if he was willing, I'd still have had to give him a test, because that's what management demands.

Re: How to measure Perl skills?
by jacques (Priest) on Mar 22, 2004 at 23:24 UTC
    Don't rely on the test too much. That would be a mistake. In the rush to hire, most employers never take the time to figure out if a candidate would be a good team player.
      I'd certainly concur with Jacques -- you need to ensure that your employers are aware that theoretical perl skills may not map well onto practical perl usefullness.

      You will only be able to get optimum benefit from a given person if you have optimum work processes; if your processes suck, and/or the person in question isn't able to work with them, then it dosn't matter how good they are -- you won't realise the full benefit of their skills.

      Unless the role specifically needs a savant, you're probably better off with someone who is technically adequate (say, good C and shell, but no perl experience) and excellent on the process/interpersonal side (organised, thorough, quick learner, teamplayer, etc), than with someone who has the technical skills of Merlyn, but the personality of Norman Bates.

      Take care not to focus solely on hiring the people who have the particular skills and knowledges that you currently need, be aware of the people who have the talents that you will always need -- the ability to learn quickly, work well with others, be thorough, disciplined and organised -- these are the people who will always have, or be able to quickly develop, the skills you currently need.

      That said, there remains obvious and definate merit in technical testing, personally I favour the "what does this code do" problems to the "write code to do this" ones, likewise I would advocate generalised, pseudo-code ones to language specific tests. Any tests should be designed and evaluated by the people most familiar with the specific job that the candidate is being considered for.

        These are all good points, thanks. If it were up to me, I wouldn't bother with a written test, but instead would be comfortable with a whiteboard-based discussion, as various people have suggested. Unfortunately, I am but a grunt, and the CTO wants to give a test. Thus: we'll give a test.

        And yes, all the skills you mention (learning, working with others, thorough, disciplined, etc) are indeed very important. The test is by no means the only (or even the hightest weighted) part of our evaluation process. There are other parts of the interview and screening that try to focus on that.

        A couple weeks ago, we brought in a candidate who looked good on paper, sounded fine on the phone, and sent in a very impressive-looking code sample. But when he got here, he couldn't explain the code he'd sent very well, he was pretty bad at "what does this code do", and he made some of the people he met feel unconfortable. So no test was required, since we wouldn't have hired him regardless of how well he performed.

Re: How to measure Perl skills?
by graff (Chancellor) on Mar 23, 2004 at 05:01 UTC
    Here's an idea I've thought about for awhile, but never tried -- in fact I never tried to set it up -- but from your description, you might have the raw materials for it (if it seems worthwhile):

    Present a bit of the old goofy code that is (mostly) self-contained -- maybe add comments about global variables to explain what they contain, if necessary. Then also present the equivalent chunk of logic as written in your current "non-icky" style. It might be instructive if the old version contains a flaw of some sort that is fixed in the new version.

    The task is to determine whether the two pieces of code really do the same thing, and in the process of discussing the snippets, get a feel for which of the styles seems more familiar to the applicant -- and which one is easier for him/her to understand (might not be the same as the more familiar one).

    As others have said, the key is still in the discussion more than in the "factual" answers. If the newer, better style confuses an applicant, but they really do get the older style, this might not be a bad thing, especially if they show signs of catching on to the newer one. You just have to figure out how much training you're willing to invest in "re-education", given that they have a leg up on the older coding style.

    On the other hand, if the newer code is a walk in the park for them, but they can't work out how the old code relates to it, they might not be as valuable when it comes to doing maintenance and retooling on the old code base, and now you have to figure out how much time you want to invest in just ditching the old code and re-creating an app from first principles (not quite "from scratch", but almost).

      This is an appealing idea, although I haven't done it, or seen it done anywhere either. The discussion would seem to lend itself nicely to finding out how the applicant thinks. Your analysis of the difference between understanding the two forms seems spot on. However....
      As others have said, the key is still in the discussion more than in the "factual" answers.

      I don't actually completely agree with this. The CTO's point in requiring the test in the first place is at least partly to find out whether the candidate can not only "solve the problem", but can also get their solution to work. By way of illustration, when I took the original test here, it took me 10-15 minutes to basically understand the code I was given, another 5 minutes or less to "get" what I needed to do, and then over an hour to actually get my changes to run! (A pathetic time, I admit, but in my defense I hadn't programmed in nearly a year at that point, and hadn't written any Perl in nearly 3. I'm much faster now.)

      So I'm thinking about a variation of this idea in which the "new style" is only partly written, and the test is simply to finish it. This could have the added benefit (I think its a benefit) of demonstrating how well the applicant can grok and match the style of existing code.

Re: How to measure Perl skills?
by Juerd (Abbot) on Mar 22, 2004 at 23:24 UTC

    I'm finding I don't have a good idea of how to proceed. 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

    I cannot resist: see How's your Perl?

    :)

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      Heh. Thanks. It's not what we're looking for, but I'll have to take it myself at some point, just to see.
      Booo, that's a horrible test for interview :)
Re: How to measure Perl skills?
by kvale (Monsignor) on Mar 22, 2004 at 23:57 UTC
    All of your reqirements are needed to write a simple OO module. So pick a simple spec, e.g., a Book class with title, author and ISBN as object attributes and number of books as a class attribute. In an hour, someone versed in OO Perl should be able to sketch out a solution.

    Extra points for

    • using strict and warnings without being told to
    • using the two arg bless for inhertiance down the line
    • encapsulation of class attributes (if you care about that sort of thing)
    • Automating get/set methods with AUTOLOAD
    • test script

    -Mark

      That might work given the short time alloted for the test, but I wouldn't give them bonus points for the two argument bless. I assume that any competent programmer is going to do that (unless they are explicitly forbidding subclassing). I would simply dock them if they didn't use the two argument form.

      Cheers,
      Ovid

      New address of my CGI Course.

        please tell me that it counts as the two-arg form of bless if you let Class::MethodMaker generate your 'new' for you

      encapsulation of class attributes (if you care about that sort of thing)

      You should care. Otherwise, why are you bothering with OO at all?

      Automating get/set methods with AUTOLOAD

      No, that breaks encapsulation. AUTOLOAD isn't the best way to do that, anyway. Putting sub refs directly into the symbol table at runtime is much faster.

      ----
      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        A bit OT, but I think you've given a simplified answer to a simplified question.

        I'm not sure how AUTOLOAD breaks encapsulation, as the AUTOLOAD code can decide what is allowed and what isn't [die "Horribly" comes to mind]. And AUTOLOAD only needs to be called the first time an unregistered method is requested -- the symbol table hockey will avoid future AUTOLOAD calls on that method, at least.

        But maybe you meant to just generate all of the sub refs at initialization, so all the methods didn't need explicit coding, just a method factory? Autogenerating all method code is probably faster than the AUTOLOAD runtime on just one method (for some values of all method code).

        On further reflection, it sounds like we might be in violent agreement.

        -QM
        --
        Quantum Mechanics: The dreams stuff is made of

      Thanks, yes. This would probably get the job done, and make management happy. Taking Abigail's excellent advice, I would ideally have the candidate talk me through the solution, but perhaps simply on a whiteboard. What I'm leaning towards now is something they could think through and type up in 30 minutes or less, followed by a chunk of time in which they could walk me through their solution and explain it.

      And although I like to see (and create) test scripts for most non-trivial code, I don't think I'd expect anyone to write one given such a short time to complete the whole task. But 5 or 10 lines of comments (or POD) explaining basic design decisions would be a major plus in my book.

Re: How to measure Perl skills?
by lachoy (Parson) on Mar 23, 2004 at 04:32 UTC

    I think the approach from a recent job posting can be very useful -- let people solve a task over a period of time, see how they solve it and how well they can explain it. It gets around a lot of the issues people have with being nervous in an interview and, along with published code, will hopefully give you a good idea of what someone is capable of.

    Chris
    M-x auto-bs-mode

      Hey, very cool job link. Thanks.

      It cuts right to the chase .. only the people who contact them in the appropriate manner can even get into the test. And you can bet that there are logs kept of every timestamped keystroke that the applicant made in solving the problem.

      Alex / talexb / Toronto

      Life is short: get busy!

      Update .. and if you go up one level from the web page that links from jobs.perl.org to 'more information' you get this freaking page which strikes me as hilarious.

      Strange job posting, requiring "Fearlessness" and a "decent selection of musical CD's" to qualify for the job. Referring to a mercenary background and having stacks of "Vietnam era" music would land me the job?

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: How to measure Perl skills?
by EdwardG (Vicar) on Mar 23, 2004 at 14:59 UTC

    These days I give applicants a written technical test BEFORE I invite them to an interview. That way

    • There is something tangible and technical to talk about during the interview
    • Inappropriate applicants don't consume much of my time
    • I get an idea about each applicant's coding style, attention to detail, approach to testing, etc, etc
    • Applicants gets a better idea of what tech skills we are looking for

    I recently interviewed someone who did ok on the preliminary test, although one of her answers failed (badly) under some conditions. During the interview I demonstrated the faulty code and asked her to debug it on the spot. It was very enlightening.

    I would not recommend this approach if you think personality is more important than technical aptitude.

      I would not recommend this approach if you think personality is more important than technical aptitude.
      Then I think you may have partly misunderstood what I was saying in that node, because I think your approach is exactly in line with hiring for personality.

      Neither of us would hire somebody with an excellent personality but crappy technical skills. I just have two bars that people must be above -- one for technical skills, the other for personality. Which is the same for anyone. But I will not lower the personality bar one millimeter for a candidate with stellar technical skills. I can understand the temptation, but I think it's one of the biggest mistakes you can make.

      As for your pre-interview test, I think that many of the qualities you are looking for are highly driven by personality: coding style, attention to detail, and approach to testing. It's the prima donna types who code with an unnecessarily complicated style, who don't bother to make sure all the details are really going to work for the other people who have to use their code, and who leave what they regard as menial tasks (e.g., testing) to their coworkers. And personally, after a long day spent orking fifty head of cattle, the last thing I want to do is write tests for someone else's "clever" code that follows a slightly different API than we had agreed upon because he decided his way was better.

      At the moment, it also doesn't appear that our technical bar is too low. In fact, we've shot down all of the candidates for the position so far on technical grounds. OT: in fact, it appears difficult enough to find a good perl web apps developer that we're probably going to end up hiring a PHP, Java, or Python coder instead. Are Perl app developers really that scarce, or does our job posting just suck? Our recruiter claims that Perl is on the decline for web apps, and that PHP and Python are fast becoming the only real players. I didn't believe her at first, but now I'm wondering...

        Are Perl app developers really that scarce, or does our job posting just suck?

        I read the job post, and it doesn't seem too bad. If you want one comment, I did notice that it doesn't seem to offer telecommuting, nor does it mention where the job is located. Or if you do say either of those things, I guess it's easy to miss.

        I think there might be plenty of Perl developers out there, but not too many on the lookout for a new gig. If my experience is any guide, any shop that believes Perl is the right tool to use, as opposed to J2EE, .Net, or some other buzzword du jour, is probably a pretty enlightened place to work. I mean, your job actually looks really interesting, but I'm not going to apply for it because I'm really enjoying myself in my current spot. Could this job be better? Sure! Can I imagine better companies to work for? Yup! But the changes wouldn't be huge, and there are so many things to like here, that it's really a crap shoot whether I'd be any more satisfied.

        If you don't think this is true - if your experience does not suggest that Perl programers are happy where they are, because where they are is a good place - you should be applying for our job opening (oh, and sfink's, too, I guess). Shouldn't you?

        At risk of looking like an appeaser, I think we are now mostly in agreement. Your earlier comment of
        for a technical job I want communication and enthusiasm first and foremost
        rubbed against my comment of
        I want technical skills and aptitude first and foremost
        but I accept we both have a position less black and white than these statements would indicate prima facie.
Re: How to measure Perl skills?
by jonadab (Parson) on Mar 23, 2004 at 20:42 UTC

    There are three things you really want to check for. You want to check that they understand context, references, and the CPAN. A good Perl coder really needs to understand these three things. There are other things that are useful (objects, closures, map and grep, certain specific modules, and so on), but these three things are really key, IMO. (Plus, you can only test so much in a screening, and if they've already learned this stuff they'll be able to pick up whatever other stuff you require.)

    References are easy to test for. Hand them something like a sub that returns a hash reference wherein each value is an arrayref, and ask them to write code that calls the sub, takes what it returns, and does something with the value for a certain key. A simple example will do ...

    sub newpoint { return [rand($maxx), rand($maxy)] } sub newcircle { return { center => newpoint(), radius => rand($maxradius), } }

    You might ask them to call newcircle twice and compare the results to determine which circle is centered closer to [0,0] or somesuch. If they have trouble with the dereferencing syntax, you know you have a problem. If they breeze through the thing, or even if they only breeze through the dereferencing and spend most of the time remembering from high school geometry class how to calculate the distance between two points, then they understand Perl's references well enough to pass.

    Testing their knowledge of context is at least as important, if a bit trickier. You'll probably want a series of three or four questions. Don't warn them that the questions are about context, just ask, "What does this code do?", but construct the examples so that if they don't understand context they'll get it wrong. Approach it several different ways, evaluationg different things in different contexts. For example, maybe print <FILEHANDLE>, "\n"; for one question, for another something like print "Some stuff " . @foo . " more stuff.\n" and so on.

    For CPAN, give them a web browser and say something along the lines of, "Find me a Perl module for working with MARC records", or something equally obscure that you've checked in advance does exist on the CPAN but is not a module they're likely to have used in the past. If they go straight to search.cpan.org, find it in notime flat, and start reading the documentation on how to use it, you have a winner. If they do a Google search and end up on marcpm.sourceforge.net (or wherever), give them a shell prompt and say, "okay, install it", and you can probably pass them if they fire up CPAN at that point.

    And yes, the ability to read your site's existing bad Perl code is at least as important as being able to develop new code well, so don't do away with that part of your test.

    Alternately, if you can detain them for several hours, you could combine the two parts of the test by handing them a few hundred lines of bad code and saying, "refactor this". But I prefer the other approach.


    ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
Re: How to measure Perl skills?
by Sandy (Curate) on Mar 23, 2004 at 19:32 UTC
    Maybe I'm being silly, but do you really want to test for perl skills or programming skills?

    Perl is not used much where I am, and so as I require help, I need to get this help from unperlish people. I have found that, generally speaking, the best help I have gotten is that from people who are good at programming (and willing to learn perl) than from people who already have perl skills, but not so good programming skills.

    If I had to devise a test, I would not make it a condition that a specific language be used. i.e. here is a problem, solve in any language of your choice... then let's look at it and make sure that all cases are handled, errors are trapped, comments are appropriate, etc. etc.

    That's just me.

    Sandy

      Well, it's a reasonable question. And we have talked about considering people with good skills and the right background, even if they don't have a lot of Perl knowledge. The difficulty is, we are a 100% Perl shop (ok, there's SQL, too, and the occasional shell script), so if we hire a good programmer who doesn't know Perl (at least not well), we won't get a lot out of them until they come up to speed. And to compound the problem, right now I'm the only developer here (we used to have another, but he left a few months ago), so all the training would have to come from me, reducing productivity even more. And there's a lot to do.

      But if the new job posting we're putting out next week doesn't get a better response, I guess we'll have to reconsider this decision, reduce or eliminate our Perl experience requirement, and rethink this whole test business.

Re: How to measure Perl skills?
by EvdB (Deacon) on Mar 23, 2004 at 12:59 UTC
    It might be fun to give them a bit of data and then get them to 'roundtrip' it between lots of different formats.

    eg, give them a list of addresses in CSV, ask them to populate a DBI table with it, pull the data from the database into a YAML file and then from there to an XML file. Finally produce a CSV file and compare it to the original.

    Doing this they will need to use several CPAN modules which all have different calling conventions, YAML exports functions, CSV_XS is OO, XML::Simple allows for chaining. It may not be relevant to your existing code base but it might open up good discussions on the way they did it - which will allow you to gauge how the might work in a team.

Re: How to measure Perl skills?
by MidLifeXis (Monsignor) on Mar 24, 2004 at 18:22 UTC

    Are you possibly putting your interviewees at risk (see Professional Employees and Works for Hire). Could not their current company block you from hiring them?

    On the other hand, maybe this could be used to strike out some of those clauses in contracts...

    Oh yeah, I am not a lawyer (isn't it obvious?), nor do I play one on TV or PM.

    --MidLifeXis

      Thanks for the link to this node. A chilling tale, and a fascinating thread. I wasn't familiar with tilly's story in particular, but I have heard similar things. I'm pleased to see that they are apparently out of that heinous situation. Now, IINAL, either, but....

      I don't believe that, in general, one's current employer can prevent one from taking a different job, unless you signed a work contract that specifically includes a non-compete clause. I seem to recall reading somewhere that those have generally been struck down by the courts on some constitutional grounds, unless they are fairly narrow. So if someone is working in our particular industry (web hosting), yes, they might be prohibited by their current terms of employment from accepting a job with us. Otherwise it's probably ok.

      Regarding IP and employer ownership, I've never accepted a job where "everything you write is ours" was part of the actual contract. I did take a job once where they handed me a form to sign on my first day that said something along those lines, but I never signed it or returned it, and they never asked. I was prepared to argue that my contract didn't require me to sign everything they gave me, nor was signing away rights to my IP part of the duties laid out, so I had no reason to comply. Whether this argument would have flown at all is an utter mystery to me.

      Even if a job applicant has signed such an agreement, it would certainly (remember: IINAL) be unenforcable if it tried to maintain such an agreement as holding after the employment contract was terminated. So ok, the applicant's current employer might hold the rights to the "work" the client did here during the interview, i.e., the results of their programming test. If they asked us for it, I'm certain we'd give it to them.

      Oh, needless to say, my current employer has placed no such restriction on any employees. Many people, including our CTO, do independent consulting and/or open source development, in addition to their work here.

        Where do you work, and are you accepting resumes? :-)

Re: How to measure Perl skills?
by Juerd (Abbot) on Mar 24, 2004 at 10:13 UTC

    I'd include in my test at least one trick assignment. Ask them to write a bubble sort. If they do so without suggesting using sort, they fail. Unless of course you're looking for a monkey who will do exactly as you tell.

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      This might seem like a good idea in principle, but you would have to be really careful about the wording of the assignment. If it just says "write a bubblesort", chances are I would, without asking any questions. That doesn't mean the idea would ever cross my mind in real code.

      Makeshifts last the longest.

        If it just says "write a bubblesort", chances are I would, without asking any questions.

        If you write the bubble sort without asking questions and without suggesting a better way of sorting, you would not be the ideal employee I'm looking for. There are employers who want their people to do whatever they say, without asking questions. I think a question like this is a good way to find out if employer and possible employee match.

        The wording would be "Write a bubble sort". Of course, somewhere much earlier in the interview, you'd have to mention that you're not looking for typing monkeys :)

        It's a trick question for a reason. It's a test. If you explicitly state you want suggestions, it is no longer a test.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Re: How to measure Perl skills?
by educated_foo (Vicar) on Mar 23, 2004 at 03:10 UTC
    golf.

    Update: Jesus, people, enough with the -6! I wasn't completely serious here. On the other hand, if you're interviewing for just "Perl skills" as opposed to "application design skills", "testing skills", "system administration skills", or whatever else, you're probably looking for someone who is intimately familiar with how Perl behaves. And since Perl golf is all about exploiting strange corners of the language, I think it's a decent test of "Perl skills".