Re: Lying applicants/Intemperate language

[JIMCHEVAL -at- AOL -dot- COM]

<<I have had five applicants lie through their teeth to me about their skills.
>>
Internal evidence contradicts you about at least this one - you yourself say
she BELIEVED her own assertions.  Ergo, didn't lie.

Having just interviewed a bunch of TW's, I'm quite clear that a lot of people
believe they have skills they don't.  When I asked one person what level he
was at with Word, he said blithely "I'm an expert."  Then begged off on almost
every specific question I asked him.

The thing is, as far as his previous clients had been concerned, maybe he WAS
an expert.  Hopefully, at least, he knew more about Word than they had.  Also,
he and several other candidates were so put off by my TESTING them (that's
right, written test) that it was obvious most people don't.

Why then are they surprised when candidates turn out to not have the skills?

Certainly, from the client's point of view, it would be the consulting firm's
responsibility to verify that a candidate actually had the skills.  And
apparently (by your own account) you did not do that.

<< At my company, a tech writer with good SQL skills is like a hunk of gold.
My
 clients are so desperate for writers with database experience that
 naturally, when anyone comes in the door with claims such knowledge, I am
 inclined to overlook some deficiencies to get them on site right away.>>

Not unusual actually.  When I was doing DB2 work at one bank, they hired a
project manager (instead of promoting her superbly skilled subordinate)
without teching her out.  It turned out she belonged to a 'computer cult' (I
am not making this up) which sent its members out to get jobs in DP, no matter
how little they knew about DP.  She spent the whole day on the phone talking
to her co-religionists, asking panicked qustions about DB2.  And ended up one
day just *walking out*, overwhelmed.

That experience is one reason I TEST anyone I'm interviewing.

But really, Andrew, how many questions does it take to find out if someone
knows the most basic things about SQL, hm? "What is relational integrity? What
is an inner join?  Who is Codd?" Etc. (If you really want to be mean, you ask
them to list the 12 principles.)

On the same project, though, we had another woman who was an absolutely
astounding programmer.  Truly a marvel.  And she learned SQL very quickly.
Because of her clear competence elsewhere, we all deferred to her in designing
our system, even though we were all equally new to SQL.  But in fact she was
initially wrong about some key elements of it (the need for indexing, in
particular).  Which it took us (and her) months to find out.

She wasn't lying.  She was just used to being right.

<<All this lead me to an interesting discovery.  People believe their lies.>>
Like, duh-uh....

<< Sheesh, our own damn President thinks it is okay to lie.

 Well, I don't want to get into the current political scandals,>>
Perish the thought....


Vet people. Ask them specific questions.  Do your homework as a manager.

Then you won't end up in this kind of mess.

Jim Chevallier
North Hollywood

New and improved!!!  Jim Chevallier's home page:
http://www.gis.net/~jimcheval


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=