Sounds like a great way to interview for an admin position, because really,
it isn't always what you know, but how fast you can research it and how well
you can do that under pressure. I have seen more than few people that looked
as though they could walk on water only to drown as soon as something broke
outside of their little box of knowledge.
On Jan 31, 2008 4:54 PM, 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> <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)