Monday, September 22, 2008

Interview Questions

I've recently had the opportunity to partake in interviews of four candidates for programming positions.  On the last several, I've been the one responsible for determining the technical proficiency of the candidates.  And since having a degree or experience seems to mean absolutely nothing in the software world, this is not as easy as it seems.  I'd love code samples or a few weeks with each applicant, but as it turns out, the other prime requirement is that I find a way to determine technical aptitude quickly.

So here are my new three questions for interviewees:

1. Explain the difference between an interface and an abstract class

Goal: Determine proficiency with object oriented development
  • Bad Answer: Uhh...
  • OK Answer: An abstract class has partial implementation.
  • Great Answer: Delve into the difference between implementation inheritance and polymorphism.
Evaluation: If they can't answer, the candidate does not have a good OO background.  If they also claim experience with OO development, the interview is over.  If they get philosophical about inheritance and polymorphism, they will almost certainly get an offer letter.

2. Are you familiar with Dependency Injection or Inversion of Control patterns?

Goal: See how people will react when they don't know.  Also, they might just know the answer, in which case: wahoo!  I usually ask this question as a, "by the way..." when the candidate is approaching the white board for a coding question or some such.
  • Bad Answer: Pretending to know when clueless.
  • OK Answer: "I don't know."
  • Great Answer: It's a technique for limiting coupling whereby objects are given everything they need, rather than having to go out and find it themselves.  Think of it as the anti- Service Locator.
Evaluation: This question hopes to achieve two goals: first, someone with real serious experience will have a pretty good clue what this is.  If they are claiming to be a rock star programmer with six figure salary requirements, they damn well better know how to answer it.  All told, though, this isn't something that is taught in schools and most junior programmers will be clueless.  Watch how they answer for some insight into their ego.

3. The programming question.  There are two I like depending on how the situation is progressing.

Goal: Does the candidate have a good basic understanding of OOP, and can he or she explain an idea?

3.A. Could you pseudo-code for me a class to represent a time?
  • Bad Answer: Using Strings for hours, minutes and seconds, using a platform Date/Time class, anything that doesn't make sense.
  • OK Answer: A class with fields for hours, minutes and seconds, and methods for getTime(), etc.
  • Great Answer: Keeping a single field that is, say, milliseconds from a reference point.  This is how most platform libraries do it.  It avoids problems with time zones, etc.
Evaluation: When asking, keep prodding.  Does this implementation take into consideration time zones?  How would it handle a Daylight Savings switch?  You are evaluating not only OOP fundamentals, but also how well the candidate approaches the problem.  Can they explain their thinking?  Do they respond to criticism?  Do they attack the problem, or are they afraid of it?

3.B. Could you pseudo-code for me a class to represent an address?

Make sure to keep prodding the candidate.  Would this address work in Canada, where there aren't states?  Would this work in Xxx, where zip codes are not numeric?  How are you parsing countries?  Would that work for, say, the city of Lebanon, Missouri?

OK, this is a trick question.

This was the interview question I received when interviewing for my current position, and the person giving it to me received it when interviewing at Microsoft.  When I left the interview, I went home and told my friends that I was definitely not getting the job.  The purpose of this question, even more than the previous one, isn't to get a correct answer - the question is, quite literally, impossible to get correct in the span of an interview - but to judge how the candidate approaches tough problems.

H'okay, so I lied - there are several others I like, but those are the main ones.  But what am I really getting at?  What am I looking for in a potential new developer?  I'll try and get to those next time...