Uri Guttman writes:
> that is my primary filtering technique. i review their sample code and
> talk about its strengths and weaknesses, ways i would like to see it
> improved, etc. HOW they react to that is a critical part of my review.
> a couple have been so pissed they almost hung up on me. how dare i
> tell them how to improve their code!! but most are very open to
> getting reviews and we end up in good conversations about reasons why
> i said that and other ways to do things, etc. a collegial attitude
> where they can learn.
I've found that too.
And also that, in some ways, "experience" counts negatively:
When a job requires a certain number of years experience, the hirers are
generally using experience as a proxy for ability. But with programming
it's possible to look at an applicant's code and get a better idea of
her ability directly.
Once I interviewed two applicants on the same day, with a programming
task. Both applicants turned out similar mediocre solutions, both with
SQL injection errors in their solutions. The morning applicant claimed 8
years' Perl experience. The afternoon one had downloaded Perl 1½ years
previously, cos he'd heard it might be useful for his job; nobody else
in the organization was using Perl, he had no support network, and
initially he'd just been dabbling with it a little in-between continuing
to do his job the previous way, gradually building up his Perl
experience in that time.
So we hired the afternoon applicant, the one with the _least_
experience. Somebody who'd spent 8 years as a Perl programmer and was
still churning out code like that didn't seem likely to improve, and
gave the impression he thought what he'd written was decent Perl code.
Whereas for the relative newbie to've already got to that point in the
circumstances he'd been demonstrated somebody striving to improve and
willing to learn.
The attitude Uri mentions appeared when I pointed out the SQL injection
problem ("What would happen if somebody called O'Reilly fills in that
form?"), and then introduced them to the concept of DBI placeholder
variables -- which neither had seen before.
The morning applicant was defensive over interpolating into SQL
directly, saying it's the way he's always done it and he's never had any
problems with it. The afternoon applicant was clearly keen to learn how
he could avoid such SQL injection issues, and enthusiastically grasped
the concept and advantages of placeholders.
So I think the actual code an applicant writes is much less important
than their replies and attitude when you ask them about that code. And
that's something which can't be automated away to an online test.
Cheers
Smylers
--
http://twitter.com/Smylers2
