Pam, you raise a good point. Something I have tried to do for years when interviewing sysadmins, netadmins, webmasters and developers is to try and find out how they approach problems as much as I try and find out their technical skills. I tend to as questions about their experience and then drill down to see if they really understand the things they have worked on. I have also been known to throw out a problem we are currently working on to see how they would go about identifying what might be causing it (and in one case the candidate identified something we hadn't though of that led to us solving the issue -- unfortunately he took another job before we could make him an offer).
Long ago at another position we had a handful of set technical questions that we asked every candidate. The classic one was for the candidate to write strcmp(). They could use an existing language or pseudo code, and we were happy to explain details of how strcmp() worked if they didn't know it. This gave us a couple of things: 1. We found out if they would ask questions if they didn't understand the scope of the problem, a few of the other questions did this as well. 2. We saw how they approached solving a programming problem 3. We saw a little bit about how they structured their code (this was mostly used on developers) 4. To some extent we saw if they understood and could handle edge cases, one of the other tech questions did a better job of this 5. We saw how they reacted to outside input as we would continue to question their choices in their code and try and point them towards any errors We really didn't care what their answer was or even if it worked, although we would try and guide them towards a working solution with follow up questions. We wanted to see how they solved problems and what their approach might be in their daily work. It worked fairly well, I can't think of more than a couple of cases where someone who made it through the interview process wasn't a fit -- and those tended to be personality clashes more than technical skills. Pam Ochs wrote: > Chances are your article is already out, but here are my 2 cents. > > Some years ago a few of us at HPTi put together descriptions of the > most puzzling and difficult problems we had addressed and used them as > interview questions "If X happens, what would you do?". We found them > useful because there were multiple good answers, and we learned > something about the candidate's technical knowledge and their approach > to troubleshooting and customer relations from their responses. > > I think hiring managers value knowledge too much and ability too > little. A friend and I once interviewed the same person. He rejected > her as inexperienced, I hired her. He hired a more experienced > candidate. My employee was sharp, learned and ramped up quickly, and > I could turn her loose on any problem. What she didn't know she found > out. My friend was disappointed in his employee. > > In this field technology changes constantly. People who learn quickly > and easily are worth their weight in gold, and while they may take a > little longer to ramp up in a position outside their current knowledge > base, in my experience they contribute more over time. > > -Pam > -- Dan Rich <dr...@employees.org> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
