Interviewing thread on altdotnet

Posted by Jeremy Miller on January 23, 2008

There’s yet another thread going on the altdotnet list about interview questions and techniques.  This message in particular caught my attention because I think it’s so true:

One risk of questions like these is that they lead you to candidates
who are clones of yourself – who know the same things, who agree with
you, who have the same experiences.

Since we all know that we are the best programmers in the world, we
may not see this as a problem. However, hiring clones of me is the
mono-culture risk – if we all approach problems the same, how are we
to approach problems in different ways?

 

I’ve been on both sides of the “I want another me” interview style.  Once I realized that I was guilty of the “clone me” attitude, I’ve tried to dial back questions on patterns, OO trivia, and Agile practices a bit.  I ask more open ended questions to try to bring out what they’re good at instead of just asking questions to find out if they know the same things I do.  I can’t say that it’s foolproof and it’s terribly unscientific, but I try to remember to look for skills that would expand the team instead of settling for more of the same.  One of the more frustrating interviews I’ve done was being interviewed by a C++ and SOA guru a couple years back.  I didn’t get a single chance to talk about anything that I did know or had done.

Besides, for me communication and the ability to explain themselves trumps almost everything else in an interview.  Facts can be learned.  Expressing yourself and thinking logically are a bit harder. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://shahkalpesh@gmail.com Kalpesh

    Jeremy,

    IMHO, expecting a candidate to know all the stuff that an interviewer knows looks more like people debating each other on the list on the same idea 😉

    Also, it is highly less likely – people would know all that an Interviewer has already worked on.

  • Jason

    @Mike

    Take a good look at what it is you’re testing there. You spent most of your time describing the self-assessment rather than assessing the candidate yourself.

  • http://blowmage.com/ Mike Moore

    I’ve interviewed my fair share of folks for a different groups over the last few years. My role has typically been the technical assessment. Besides technical competency we were also interested in getting a good fit for the group. Sometimes that means finding a clone, but sometimes that has meant finding complementary talents and skills. Personally, I’d hire a woman over a man with equivalent experience and expertise solely because my experience is they add a new point-of-view to solving the same old problems.

    My general approach is to ask the interviewee to rate themselves on a long list of languages, technologies, methodologies, and paradigms. I ask them to give me a number between 1 and 4, where 1 means you have heard of it and 4 means you are an expert and could write a book on the subject. Then I drill down into the areas they rated themselves the highest. This helps us get an idea of the candidate’s experience as well as their honesty.

    I’m largely generalizing here, but what I’ve found is that kids just out of college typically overstate their knowledge and proficiency. They rate themselves a 3 or 4 on all subjects they’ve ever used before, regardless of how much they used it or how well they know it. The veterans tend to have a better grasp of what they know and what they don’t know, and tend to answer more accurately. I don’t have a very large sample size, but my gut also tells me folks with additional degrees tend to overstate their knowledge more than those without. (But I’ve never interviewed someone with a Master’s degree that I would recommend for hire so I may be biased.)

  • http://blog.phatboyg.com/ Chris Patterson

    I tend to focus on how a candidate approaches a problem. I could care less if they know how to convert an integer to a string. That’s something anyone can look up in the help.

    I’m more interested in how far beyond the wizard they’ve gotten with real-world code. Issues they’ve had to troubleshoot, problems they’ve had in production. If they mention they had to load Visual Studio on a production machine to troubleshoot the problem, I get really scared and usually call it quits.

    I also find that if they don’t have any real details of anything they’ve done over the past year, they probably didn’t really get involved in the details and likely slept through a lot of meetings.

  • http://geekswithblogs.net/Podwysocki Matthew Podwysocki

    Now we’re entering in the lightning round!

    Which members are now obsolete in the Thread class and why?
    Tell me six ways to convert from a string to an integer…

    Totally agree with your points though with regards to logic, which is why I tend that stress that over the code semantics of the language of choice. If you can understand a queuing problem, or some other logical problem, that’s what I’m looking for. I don’t want to know how many methods are on the Convert class and what they’re used for.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    Nothing irritates me more than trivial pursuit interviews.

  • http://chadmyers.lostechies.com Chad Myers

    Jeremy,

    I wouldn’t hire you unless you can tell me what the expected result of this statement is on all the major C compilers:

    x+++++;