Hi Steve,
Looks like you have a somewhat principled method.
It would be great if PLUGs could help in the accreditation process
in some way by staging workshops, etc. I guess its a chicken-egg
problem though, people don't get involved because its not legitimate,
its not legitimate because people don't get involved.
I suggested staging code contests, but as is typical, doesn't go
anywhere. I think local employers would hire more local talent and
businesses may consider being Phoenix based if there was a bit of
organization there... but I have ranted enough on this topic here and
elsewhere so I will refrain.
-jmz
On 1/31/08, steve crandell <
steven.crandell@icrossing.com> wrote:
>
> I've been banging my head against this very issue on and off for a couple
> years now.
> Based on my own experience and that of others gained through some less than
> perfect hires (and the problems created thereby) I now use this method:
>
> First I run two interviews of increasing complexity that do their best to
> cover a wide range of linux related admin topics.
> Questions are always phrased in a way that require a few sentences to answer
> rather than...
> "Do you have any experience with NFS?"
>
> During these interviews I'll obviously will eliminate based on incorrect
> answers but more than anything I'm looking at personality, composure, body
> language and how follow up questions are answered like:
> "And if that didn't work, what would your next troubleshooting step
> be?........And what if that didn't work either?.....And...."
>
> The point is that I'm not data-mining, I'm method-mining.
> I really don't care what a person knows or what degrees or certs they have.
> I want to know:
> 1. Can they work in a team?
> 2. Can they figure out new things without having their hand held through
> every step of the process?
> 3. Will they follow through?
> 4. Etc
>
> For instance I interviewed several guys last year who ran hugely important
> systems at AT&T, IBM, CNN, and none of them made it past the first
> interview.
> Reason being that their "trouble-shooting-path" if you will, didn't extend
> anywhere beyond
> 1. Read the big red book the vendor sent us
> 2. Call the vendor
>
> Which brings me to the final interview.
>
> This 3rd interview is done entirely online and involves connecting via vnc
> to the candidate's desktop.
> The candidate is given login credentials to a server used for testing.
> Various prefab'd problems need to be fixed and tasks need to be completed.
> Most importantly, everything is open-book, open-google, open-whatever.
>
> In this interview I hope to stump the candidate so that they have to go
> search around in real time.
> That they may not know the answer immediately doesn't really matter to me.
> I get to watch them construct a complex command, or decide what terms to
> throw at google, or dig through system resources to decide what is causing a
> particular issue.
> In essence, I get to see how their thought process works as they research.
>
> Having this remote connection is the golden ticket to really figuring out if
> the person on the other end knows what they're doing.
> It can also be rather nerve racking for the candidate but there's some value
> in that also given that it's pretty important to be able to keep a cool head
> when conditions are less than ideal.
>
> -s
>
>
> Matt Graham wrote:
> From: alex@crackpot.org
> Quoting Joshua Zeidner <jjzeidner@gmail.com>:
> The Question is... how does an employer measure Linux expertise
>
objectively?
> With great difficulty. (So some of them look for the RHCE label.)
> earning an advanced degree does show a person has
commitment, and should
> have a good general understanding of the
subject. But none of that is a
> guarantee. I've met a lot of
knotheads with masters degrees (in many
> fields).
> Yep. There are even a number of complete idiots with PhDs out there.
I've
> seen them; my father's a professor, so I met a number of
> ...
less-than-useful people in the department who all had PhDs.
> You find out what people know, and what they're good at, by talking to
them
> and finding out about what they've done in the past. It's not
objective by
> any means, but I think it's also less artificial than
trying to establish
> arbitrary tests or benchmarks.
> This is true. However, it's also harder to reduce this to a nice
> little
number and put it into a happy chart. I have seen researchers,
> HR
departments, bean counters, and ordinary folks just freeze up and
have a
> cow when it comes to data that has to be interpreted in a
> more
time-consuming fashion than "normal"
> data.
---------------------------------------------------
PLUG-discuss
> mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To
> subscribe, unsubscribe, or to change your mail
> settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
> --
Steve Crandell
Linux System Operations
480.282.6047 direct
> 480.239.9286 mobile
480.505.5801 fax
steven.crandell@icrossing.com
> www.icrossing.com
ATLANTA | CHICAGO | DALLAS | NEW YORK | SAN FRANCISCO |
> SCOTTSDALE
Winner of OMMA Magazine's 2005 Agency of the Year: Best
> Search
>
> ---------------------------------------------------
> PLUG-discuss mailing list -
> PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
--
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)