23rd May 2012

You are here: Home / Blog / How do you interview for technical people?

How Do You Interview for Technical People?

14th May 2010 By 6 Comments

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!

This post is copyright of Thropos Ltd ©2008-2011 at Etherealmind.com - contact | email: greg.ferro@packetpushers.net - twitter: @etherealmind | All rights reserved
Filed Under: Blog, Cisco
  • Sean

    Google’s interview process is pretty good at weeding out people (which by their own admission unintentionally drops qualified candidates, or at least I’m clinging to that lest my ego be destroyed by not getting an offer). While there’s some question and answer, there’s a lot of working through problems.

    For example, on my phone screening I was writing Perl and Shell scripts, discussing TCP SYN cookies, and various other things. In the in-person interviews it was a lot of problem solving. More writing scripts. Code on a blackboard. Discussion about Linux internals. “Describe what happens when”.

    Another thing to note was that in most of the cases when I was working through something, the interviewer would stop me and say “why did you do that?”, or “what if you couldn’t do that?” or “what would happen if?”

    Only one of the interview slots was question-answer style.

    Sean

  • http://twitter.com/matthewnorwood Matthew Norwood

    Greg,

    You make some good points. In the past year, I did some technical interviews of people my company was looking to hire. I always tried to have a generic list of things that would be required in the job and let the interviewee steer the discussion. For example, QoS was something that you were going to run across so I would simply ask them to tell us about QoS. Every now and then you have to ask an additional question or clarify something for them, but really the discussion for that particular topic would go on until we felt we had reached the depth of their knowledge. After doing this in several different areas, I think we had a decent feel for their understanding of the various technologies/protocols/etc.

    It was never a contentious interview. We tried to make it a relaxing conversation where we just talked about technical things, but from a friendly standpoint. One thing we did not do was correct them or disagree with them. I think if you start correcting every thing they say wrong, they will clam up and hold back. You also want to see if they know their limits. The best people we interviewed were the ones that knew their limits and would just say “I don’t know”.

    • http://twitter.com/matthewnorwood Matthew Norwood

      My mistake Dan! I am so used to coming to this site and seeing Greg’s name everywhere that I totally missed the fact that it was you who wrote this.

      • http://blog.olorin.co.uk Dan Hughes

        No problem! I let Greg take the flack when I post something crazy!

  • Mark

    We actually had this problem recently when our lead engineer moved on to a different position, since our team is only 3 people we decided to keep the technical interview friendly. We would sketch a basic topology and bring up a scenario and ask the candidate how they would approach it, we let them lead the process and usually just nod along or offer suggestions if they asked until they ran out of ideas. Our method seemed effective at weeding out people that really didn’t have any business applying for the position ; the people with server backgrounds would immediately fall back to using server based tools to solve the problems and the project managers/consultants would generally know of 3 or 4 tools that we should buy to address the issue rather than using what was at hand.

    In the end i think we should have made our scenarios a little more difficult and less text book because we still managed to find someone that interviewed really well (wowed the CIO in his follow up as well) but once he got the job turned into a wannabe project manager with no desire to get involved in the technical challenges :(

    • Echoreply

      Dan,

      In the future you should not forget to neglect personality traits, long term career goals, and business savvy.
      Don’t get me wrong they need to have the technical skills as well, but that is just part of the equation. I have found that over the years that many technically competent people aren’t suited to do much of anything but hammer away at configs, read hex in packet captures, and geek out in every new technology that comes to play. At the end of the day if they can’t apply this knowledge in ways that improve or meet the needs of their respective employer than it’s all for not. Also if they dont mesh well with the team or it seems to good to be true than theree is probably something amiss. I have seen all too often people fly through technicsl interviews witht the greatest of ease, and after the fact find that they want to skate by or they just want to get their foot in the door to move into some other area. Its tough to catch these things in short interviews and i personally always shoot for a 2nd completel non technical interview which is really more of a personality test than anything else. The technical prescription for interviewing that you have mentioned above is spot on, you just may also want to look into other aspects of the candidate before making a hiring decision. :)
      EchoReply