From: ptkwt@... (Phil Tomson)
Date: 2005-11-04T03:52:09+09:00
Subject: Re: Ruby Certification

In article <B106AF0C-AB40-4515-B877-9043A19C891F@mac.com>,
 <gwtmp01@mac.com> wrote:
>
>On Nov 3, 2005, at 11:41 AM, Obie Fernandez wrote:
>> Assuming we're on the verge of a big boom in Ruby jobs, shouldn't
>> there be a place where employers can verify a candidates reputation?
>> I'm thinking a testimonial or trust-based system of some sort.
>
>Speaking as someone who has done hiring in a area with lots
>of "certification" (Cisco Networking).  I can say it means nothing
>when I see it on a resume.   If I want to know if someone understands
>BGP in an interview, I can ask one or two questions and within five
>minutes have a pretty good handle on their level of expertise.
>I found that there was very little correlation between what I could
>discern from someone in person to what was on their resume relative
>to "certification".
>
>
>> When the market for Java programmers exploded there were hug numbers
>> of highly (un)qualified people getting hired to do Java and causing
>> all sorts of grief to everyone involved. Lots of them had (or claimed
>> to have) certification.
>
>Sounds like bad hiring practices to me.  I think *technical* knowledge
>is one of the *easiest* things to figure out in an interview.  What I
>find really hard to figure out is if the person is going to have a good
>attitude, work well with others, be good with customers, and so on.
>

I would even maintain that a technical interview is not a very good way to 
guauge someone's technical expertise and talent.  There are very talented 
people who lock-up in that situation.  And it is an artificial 
situation: 
In real life how often do you find yourself locked in a room without any 
reference books and no internet access? 

It would be better to consider a candidate's community involvment 
including open source code the candidate has produced.  Lacking that, I'd 
like to see more 'real-world' technical interviews where the interviewer 
brings in a laptop (with wifi access, a compiler or interpretter, 
program editors, IDEs, etc), some reference books and outlines a 
problem s/he would like to have the interviewee solve.  The interiewer 
then leaves the room for 2 or 3 (maybe more) hours and checks back later 
to see the code written by the interviewee.

Phil