The classical method of interviewing (either in person or over the phone), I've always found to be quite useless. It does have a 'weeding' effect of removing the completely clueless, but that's all. The problem is when you ask people to describe protocols/systems/methods etc you're testing their booksmart skills, not their real world ones.
Practical Tests
I've always loved the idea of a practical test, where some kit is set up in a 'mini lab' type setup, and a number of trouble tickets are given to the candidate. This will answer the 'can they troubleshoot' question! However it's quite time consuming to set up and grade - if you've ever tried to write these kinds of tests they actually take quite a lot of time to get clear and fair.
As an alternative - there is whiteboarding a problem, where the candidate is given a theoretical issue, which they need to talk through their troubleshooting techniques for. It's simpler to do for the interviewer, but can be quite daunting for people who are not used to public presentations.
Whiteboarding
In general, making someone answer an open question (e.g. show me on the board how OSPF works) will really test the depth of their knowledge - beyond being able to regurgitate the books they've read. However, again you have the problems of nerves and people unused to standing up and presenting. If you're not looking for 'public facing' staff, are you ruling out people based on a skill you don't need? Speaking to recruiters, this kind of method can rule out a lot of people!
Comments
I'm really interested to hear your comments on this one. What have you done (or had done to you!) over the years, and what do you think worked and didn't work!
4 comments:
I like to ask open-ended questions, with all apologies to the CCIE candidate community. For example, I might ask something like, "You've been given an unlimited budget and a requirement to build an highly resilient dual data-center networking infrastructure. Talk to me about it. Feel free to use the whiteboard."
From that starting point, I can probably find out everything I need to know. If the candidate responds by immediately describing his design, it might be a "fail". I didn't provide enough information to design much of anything, although depending on the design they offer and what kind of a position I'm interviewing for, it could work out.
What I would hope to get from the candidate are questions back so that we can start a dialouge. "What kinds of applications will the data centers support?" "Are the data center locations owned or leased?" "What is the local telco infrastructure?" "How geographically far apart are the data centers?" "What is our customer profile?" "Do we have specific SLAs we must meet?" And so on...
I want to hear that the candidate asks the right kinds of questions in response to an open-ended question. From that, I can judge experience and planning ability.
As that conversation progresses, I will ask other sorts of questions as opportunities present themselves. "So you say you recommend brand X load-balancer to sit in front of this HTTPS application. Why?" "Cisco is doing virtual port-channeling with the Nexus platform. Is there a reason you're recommending 6500s with VSS instead?" "What is your opinion on end-to-end encryption versus link encryption?"
The idea behind these questions is to determine the candidate's ability to clearly articulate an idea, and also see how deep they go on certain topics I might care about. I think that sometimes it's better to hire the candidate who might not know everything you need right that second, but who demonstrates decent experience and the ability to learn quickly + adapt to unfamiliar circumstances.
I don't know that approach would work for every technical position. My approach is going after someone who's more a designer, or a senior engineer who see the big picture (which admittedly isn't most pure engineers).
I think the practical tests are good and so is just having someone talk through the steps with you. I couldn't believe the other day when interviewing for a job someone just gave me a sheet and asked me just to rate my experience with certain items. The subjectivity came into question. I certainly wouldn't call myself a cisco expert, but to the interviewer I probably was. I like the idea of labs personally, but I suppose at some point the certifications are supposed to provide that reliability for the candidates and the organizations.
"In general, making someone answer an open question (e.g. show me on the board how OSPF works) will really test the depth of their knowledge - beyond being able to regurgitate the books they've read. "
I like this one. Infact, I think this would make me want to work at that company even more! An opportunity to show your worth and demonstrate not only your knowledge but HOW you understand stuff is a huge plus.
Even if you dont know a technology, this shows the employer how you would approach problems etc. which can be just as valuable.
There is a HUGE issue that is going without notice and that is that the "braindump bunnies" are also in senior roles in some companies, these same people are the "technical experts" that you sit down with for an interview. This is very frustrating for me.
I've run into situations where if I say I spent X amount of time on X certification they will state "it should really only take two months".
Good point Shane - there's nothing worse than interviewing somewhere and the 'technical expert' is a monkey bucket. I've actually ended an interview once (many years ago) because the 'senior' guy I'd be working for not only was repeatedly wrong, but wouldn't listen to reasoned argument. I knew I could never work for him!
Post a Comment