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 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 : > 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