Prev: Smith-Waterman Algorithm in Python
Next: Perl -> Python unpack
From: Peter on 11 Aug 2010 17:14
On Aug 11, 8:50 pm, Tim Chase <python.l...(a)tim.thechases.com> wrote:
> On 08/11/10 01:24, Terry Reedy wrote:
>
> > On 8/10/2010 8:08 PM, Roy Smith wrote:
> >> In any case, if the candidate were to submit somebody else's
> >> work, it would come out pretty quickly as we discussed their
> >> code.  I suppose one question I might ask would be, "Can you
> >> explain why, when I copy-paste one of your comments into a
> >> google search box, your entire program appears?"
>
> > Mostly likely because I wrote the original...
>
> > would be my answer.
>
> Unfortunately there are candidates who would give your answer but
> then have trouble with "Then why are the Last-Modified HTTP
> headers showing a date several months before our interview?"
> It's as bad as the phone-interviews I've done where in the
> background I can hear the person on the other end typing my
> questions into a search box and reading off answers.  On the
> bright side, those are short interviews... ;-)
>
> -tkc

I know we are straying somewhat here :-) But as an interviewer way
back when in the never-never, I used to look at the interviewee's work
history i.e. 18 months here, 12 months there, 6 months here etc and
pretty much wipe them from my short-list based on that alone :-)
Because it takes at least 3 months for a programmer to get "up to
speed" fitting into your company and on your applications, they are
usually only really productive and really "hitting their stride" at 6
months - somebody who "job hops" will already be looking for the next
job by that time!

I really did't have time to waste on these people - then there was the
agents fee for finding them for you - big investment for zero return.

So I would recommend to anybody that they attempt to maintain a stable
work history in this respect. For example, my personal work history is
8, 7.5, 8.5, 0.5, 3, 3, 8 (years that is). My current company is
extremely stable, I enjoy the work, so I don't see any reason why I
won't be here until I retire (or die at my desk - whichever comes
first :-)).

Peter
From: Simon Brunning on 13 Aug 2010 13:03
On 11 August 2010 13:34:09 UTC+1, Steven D'Aprano
<steve(a)remove-this-cybersource.com.au> wrote:
> Getting interviewees to do a take-home problem just means you hire the
> guy who is friends with a good programmer, rather than the good
> programmer.

We give a take-home problem. If we like the code we see, we invite the
candidate to come in and pair with one of our devs in adding a simple
feature or two to their own code. It's time consuming, but not so time
consuming as hiring a weak dev.

--
Cheers,
Simon B.
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: Smith-Waterman Algorithm in Python
Next: Perl -> Python unpack