Re: [tlug] Job Posting

[Curt Sampson <cjs@example.com>]

On 2009-01-12 22:02 -0500 (Mon), Joe Larabell wrote:

>> So you would take the problems specification as incomplete and assume
>> that securing the ruby system command was part of the problem without
>> consulting further with the client.
>
> That's a good point and may well have been intentional in the assignment. 
> Since it's just a test assignment, I probably would make the assumption, 
> put in a comment, and bring it up at the interview. But since the text of 
> the web site says that the applicant should ask questions if he has any (or 
> something to that effect), I probably would *not* get hired.

Actually, you'd probably do fine. The aim of the assignment (and
how well it achieves its aim is an open question) was not to test
specification-reading skills, or get production-quality code, but just:

    1. Find out if the candidate can write a Ruby program that's not
       completely trivial;
    2. See if the candidate has some understanding of a fairly important
       part of the POSIX API; and
    3. Try to get some sort of look at the candidates OO design skills.

All this without eating up too much of the candidate's time, of course.

This was actually a pretty tough one for me, and I'd love to hear other
ideas for how one might achieve these aims, and even other ideas for
what we really should be trying to test. Just keep in mind that it's
very, very important that it be something a competent programmer should
be able to put together in a couple of hours: this is a screening
device; much more interesting tests come later in the interview process.

(And, shocking as it is, I've interviewed programmers with "years" of
C++ experience who have no idea what the "POSIX API" is.)

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com