The Software Purist |



Interviewing Software Developer Candidates

One of the more challenging things in your professional career as a developer is evaluating potential candidates for hire. I wanted to discuss this topic a bit and provide some of my experiences and opinions on the matter. I think this is an area that a lot of developers have a challenging time with, being that we are often not social beings by nature and, therefore, are at risk of evaluating purely based on superficial characteristics or not asking the pertinent questions.

Who should interview

The first thing is knowing and noting the roles of all the players in the interview process.  In most cases, the manager cannot provide the technical deeper level of a tech out.  Likewise, the developer can’t be expected to focus on the high level business goals during the interview process, because the developer’s foremost concern is and should be: “can this guy code?”  If you’re a manager reading this, you need to understand that a suave developer can BS his way past any answers.  You need that expert developer to counter-balance from the technical side.  Any interview process for a software developer that is done without a developer present is a risky proposition, because managers are a risk for hiring the best speaker, instead of the most talented.  Ultimately, at least one manager and at least one developer should be involved through the process.  Ideally, you may want as many as 3-5 developers involved in the process, because it removes the responsibility from a single developer in finding the shortcomings.  The developer MUST be an expert in the subject matter he is interviewing for.  If not, he is at the same risks as the manager was.

What to Look For

There are two levels of things to look for during an interview.  The first is personality.  You need to be confident of positive answers to the following questions.  In most cases, the manager is more keen to these than the developer:

  • Does he or she tell the truth?  When pressed with a question he doesn’t know, will he admit it or will he not acknowledge his mistake?  A developer who has a habit of lying can cause real problems for teams he works with in the future.
  • Does he or she point the finger and/or place blame at others during the interview process?  This is a big warning sign.  It’s normal to have a bit of disdain for your previous company, but the interview is not the place to do it.  If the developer does this during the interview, you can expect more of the same once they’re onboard.
  • Is his work experience relevant?  Can he explain pieces of his work experience in detail?  Does he sound like he has pride in his accomplishments?  Does everything sound like a team effort or did he accomplish a lot outside of the team goals?  A developer who only says “we” is giving off subtle warning signs.
  • How quickly does he answer questions?  Slow answers sometimes mean either: A) the developer was confused by the question, or B) the developer is in the process of making up an answer.  If it looks like B, end it quickly.
  • Basic knowledge of company and position applying for.  Most candidates will spend a little time investigating your company.  You always want to know if he wants to work there, so this is important.  It should be a very small piece, but it’s a warning sign if the developer didn’t spend the time.
  • How does he react to pressure?  Give him a problem he couldn’t possibly know.  If the developer sweats, swears, freezes, etc… it may be time to move on.  If the developer will try to work through the problem, it’s a good sign.
  • Find out what his interests are.  What does he read?  Developers who don’t read quickly become obsolete.

The second group, and equally important is the technical portion.  This is where some managers fail.  A developer can appear to pass with flying colors on the first part and then simply not be a good candidate because of technical reasons.  Or vice versa.  Every candidate is different.  Here are some of the things you need to know from the technical point of view:

  • Ask beginner questions, intermediate questions and a few advanced questions.  In a first interview, these can be kept to generic situations.  In later interviews, you may want to get into more specific scenarios, such as a simple application and how they would approach it.  In any case, you look for consistency.  It’s okay to get a question wrong.  Depending on your questions, the level for what passes and what fails can vary.  A rule of thumb is to find a developer you trust and ask yourself what he would get if you quizzed him.  Then subtract as much as 10-20% from the score and you have your bare minimum.
  • Ask questions about coding style.  Find out what his favorite style is, then casually ask if he’d be comfortable using the opposite style.  His reaction will tell you all you need to know.  In my experience, there are a number of developers who are very particular about style.  This is one of the least important things when developing code, yet one of the highest contention points.  Anyone who demonstrates contention during the interview is not a team player.
  • Delve into job history a bit and ask him about interesting coding problems he came across.  If the code he wrote was a while back, it’s a very good sign if he discusses what he did at the time and then how he would improve on it now.
  • Problems like, “here’s a code sample.  Do you see any issues with it?  What could you do to improve it?”  These sorts of exercises are very useful to see how he thinks and if he can read the code of others.
  • Give a specific problem and ask him to draw UML diagrams.  See if the high level architecture matches the concepts.  Does he use design patterns?
  • Find out his comfort zone.  If he’s really into high level programming, give him a problem that involves bitwise logic.  If the programmer is an expert at Intel assembly, give him a high level problem.  Reaction and approach will be very telling in these cases.
  • Finally, don’t try to nail anyone to prove you are smarter.  I’ve known one interviewer who did this, for reasons beyond my understanding.  The point of the interview is to hire a candidate, not to prove your intelligence.  Your intelligence is already accepted, because you are employed, in the position you hold.

Defective Habits During or After the Interview Process

  • Not being prepared.  There’s no excuse for this.  Every single resume requires 30 minutes to an hour of dedicated attention.  You should go into the interview with a list of questions already prepared, just from reading his experience.  Note the time hit here: Each candidate you decide to interview can take anywhere from an hour of time to 3 or 4 hours of time, depending on how far along the interview process they make it.  Management often does not understand how time consuming the interview process is.  If you work at such a place, you should seriously consider your own options.
  • “We’ll give him a shot”.  No, no no.  Don’t hire a candidate unless you’re sure.  It’s too expensive for the company to hire candidates and then fire them later if they don’t work out.  The company should not be taking this risk unless they are fully aware that you really are unsure.  Be sure.  Hold additional interviews to make sure you’re sure.  If you go a lengthy period without being sure and the candidate is on the fence, you’ll need to pass.  It’s not fair to hire a candidate under those conditions.
  • Long waiting times.  If you truly like a candidate and he is “the guy”, you need to move on it.  You can afford to wait on a maybe, because maybes are a dime a dozen, but not “the guy”.  If management is dragging their feet, they need to be reminded that it could take months to find a equatable candidate if they move too slow to make an offer.
  • Focusing only on style.  I have seen so many developers do that that it drives me nuts.  The most important thing is not whether the developer codes with the same style as you or uses the same favorite library as you.  The important thing is whether they can do the job and whether they will play by the rules.  If they fit these two criteria, you’re gold.  You can tell if you’re getting into this habit if every K&R-Unix code sample looks “good” and every Allman-style Visual C++ code sample looks “messy”.


Ultimately, developer interviews are a tricky process.  The post was getting a bit on the long side, so I think I’ll have to do a follow up to it at some point soon.  Regardless, hopefully the point has gotten across and makes sense.  These are some of my tips based on my experience and hopefully you will take them into account in your interview process.

· ·

No comments yet.

Leave a Reply



Theme Design by