alan.b.pearce@stfc.ac.uk wrote:
>> I don't know how these people get hired, but it seems to happen all too
>> often lately.
>
> Those doing the hiring fail to ask for references to past projects?
>
> I guess there is a lot of problems with NDAs, but surely it must be=20
> possible to provide previous customers names to get a reference as to how=
=20
> satisfied they were with your work.

I've done my bit of hiring, and among other things, learned these two=20
maxims:

1. References (as in, "people") are useless. They are hand-picked by the=20
candidate, so obviously they will sing him praises.

2. People who "can't talk" about most of their projects because they "signe=
d=20
an NDA", are full of crap.

Back in 2005, we hired a contractor to help us write some code. He was in=20
his late 60's, and had a very impressive resume -- at least three pages=20
long. It listed skills from PIC Assembly to FORTRAN, and claimed that his=20
work experience included doing secret research for the US Navy and NASA. He=
=20
spent the bulk of the interview telling us tales of his adventures. Wheneve=
r=20
we pressed him to describe an actual project, he would invoke the NDA=20
excuse. We described the project, and he confidently said "I can do it". So=
=20
we hired him. Big mistake! We found ourselves teaching him the basics of th=
e=20
C language, and three weeks later, he made almost zero progress. He would=20
not have lasted three weeks, if I didn't go on vacation a week after he got=
=20
hired -- my partner didn't feel confident enough to pull the plug without m=
y=20
presence.

Earlier this year we had an interview with a web developer candidate, who=20
spent an hour telling us beautiful stories but "couldn't talk" about his=20
projects because he "signed NDAs". He also didn't know jack about web=20
development or OOP. "I know these concepts, but I don't have a texbook=20
answer". Oh yeah? So tell me in your own words. The amusing part was, I=20
asked him the same questions in the phone interview, and he was too lazy to=
=20
google "refactoring", "patterns", "aggregation", and "test-driven=20
development".

There are no shortcuts, in order to see through the facade that the=20
candidate puts up, you have to make mistakes, and learn from them. You have=
=20
to be brave enough to recognize when you made a hiring mistake, and be=20
strong enough not to prolong the agony. And read lots of books.

I use two methods for cutting through the crap:

1. Ask for contacts at the company where the candidate worked -- a manager=
=20
or supervisor. Even if they give you a phone number to the HR department, i=
t=20
is still more useful than a "reference" -- you can at least confirm that=20
they did in fact work for the company, and verify the duration.

2. Ask the candidate to tell you about non-NDA projects. If you're an=20
engineer or a software developer worth your salt, you must have at least a=
=20
couple of projects that you've done for your own enjoyment. Also, it is=20
almost always possible to talk about a project in a way that doesn't violat=
e=20
the terms of the NDA.

Congratulations if you've read this far. Sorry, I am in a hurry and don't=20
have time to condense. Hopefully this can be of use to someone.

Best regards,

Vitaliy=20

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.