Company Leadership: The Software Developer Interview

I’ve done a lot of interviewing in my career and I have found that I interview employment candidates differently then consulting candidates. I use a different yardstick and so should you. When I hire a consultant I expect the consultant to be an expert in one or more areas that interest me. For example if I’m looking for a TCP/IP expert then the consulting candidate should be very familiar with TCP/IP. However, if I’m hiring an employee I am still looking for the TCP/IP knowledge but NOT EXCLUSIVELY. And that is my point. You hire a consultant to solve what is hopefully a targeted, short-term problem. You want the consultant to come in, do the job right, and leave for the least amount of money. An employee on the other hand is going to stick around, with a high probability that the person will be assigned to other tasks. So although the TCP/IP experience is important I also look for less tangible and harder to pin down traits.

I will ask an employee candidate to write some code. I’ve been asking for a strcpy() function for so long I’m still surprised by the number of people who can’t or won’t write one. I’m always amazed by the senior level software development candidate who refuses to write the strcpy(). Basically, the interview is over when that happens. Inflexible, arrogant, incompetent are words I’ve used. Fortunately for me and my team the candidate was kind enough to let me know early that he wasn’t the type of person I wanted to work with.

What I look for in an employee candidate is problem-solving skills, ability to learn, flexibility, curiosity, and the answer to the question, “can I work with this person”. I want smart, adaptable people around me who will help out the team when the unexpected happens, dig into the boring gnarly technical issue that no one else wants to look at, stand-up and fight for a design that he believes is best for the company. You can’t find out that kind of information by asking misstated puzzle questions that you don’t know the answer to, asking for exact syntax on some esoteric Oracle SQL call when the candidate has only worked in SQL Server, or by talking tech in areas you don’t understand.

I’ve been surprised by the number of bad interviews I have had over the last few years. I’m not sure if it’s Silicon Valley or the times. But interviewing employee candidates as if they are consultants is VERY short-term thinking. If you want a consultant, post for one and be done with it. Don’t waste a good candidate’s or your company’s time because you don’t know what you want.