Sean Chase Blog The frenetic soapbox

Jan 14

Sean

Interviewing People

  • Created: Saturday, January 14, 2006
  • Sean
Within the last year I've had the opportunity to interview people for junior to senior-level positions. It has been an interesting experience and in order to make sure I'm being fair to both the candidate and the company, I've had friends review some of the questions I ask and end up revising and throwing some away. The real trick is to have a 30-60 minute conversation with someone to figure out what they can do - it's pretty darn difficult to do that. Much like when you interview for a position, interviewing someone requires you to re-think certain assumptions. Those of you who have interviewed at Microsoft know what I mean. In fact, this whole process of interviewing people prompted me to aggregate questions for the Microsoft interviews I've had just in case you are interested in reading them. Personally I don't think that I ask questions anywhere as near as difficult as what I've been asked at Microsoft. Joel Spolsky has interesting ideas on this subject, but I don't totally buy into everything that he does either. My own interviewing experience with various companies at various levels of difficulty, not to mention having many co-workers over the years that were quite good but probably not the best interview candidates has given me enough confidence to follow my own recipe for interviewing. I typically start with questioning experience on a resume. I then delve into questions related to the type of development work I've recently faced and then some basic questions about the technologies (in this case ASP.NET, some SQL syntax, and OO design questions). However, I recently discovered an assumption of mine: that senior developers would all understand the word “immutable” which is something I've thrown out and rearranged into questions that cover the concept (example: using System.String or System.DateTime). This was one of those assumptions I made as an interviewer and assumptions are bad m'kay. I'm not looking to filter people out based on their development vocabulary; I just want people with good development skills that can hit the ground running. Unlike many interviews I've had, I also ask at least one problem solving question and try to make the question into a conversation. It's not a “hey, answer this or you are toast” which some might say is best, and certainly “I don't know” is not an answer. There's a gray area that is very subjective. This is a process of trying to see in 30-60 minutes:  how the person thinks, how well they communicate, where they go to find answers, and if they know the technology well enough. If you are hiring contractors for a 3-6 month project, they have to hit the ground running and do a good job. The process I follow is a little different than what I would do for a perm employee (this is more of where I agree with Joel Spolsky because the person has to be smart in general, not necessarily great at the current technology you are using). Anyone have thoughts on this? What have your experiences been as an interviewer?
;