Your Interview Process Probably Sucks

I had an interview last week that made me realize the emperor isn’t fully dressed.

For the past seventeen years, I’ve coded client-server or mobile applications for a variety of platforms, for companies large and small, as a contractor or an employee. I’m relatively agnostic when it comes to tools or methodologies, the ones I’m currently using are .NET, C#, and Agile but in the past I’ve done FoxPro, Visual Basic 6, and Waterfall. I’ve heard (and believe) that every five years you should throw away a lot of what you know and learn something new.

Like most of us I code in the “real world.” The newest technologies and techniques are always in the back of my mind and I’m always open to a better way of doing things (that’s how I got into Agile) but my focus has always been solving the immediate problem in front of me with a blend of analysis, design, and development. Overall, I’ve been relatively successful and I’m grateful that my work combines something I love with something I do.

Here in New England there’s a small but growing indie game presence anchored by some bigger companies. I’ve always been a gamer so after PaxEast 2010 I decided to spend some time exploring the game landscape and see if there were any opportunities out there for a software developer with my skills and experience. I found out that a Triple-A MMORPG game developer in the area was hiring so I submitted my resume, not expecting to hear back. To my surprise they contacted me and I had an initial phone interview with the manager looking to fill a Senior E-Commerce Systems Engineer position. Having gotten through that “boss level” I moved on to the database & programming problem challenge “level.” Apparently I did well enough that I was moved forward to the on-site interview.

I’ve been on hundreds of interviews and I’ve come to the conclusion that the interview process at a majority of companies I’ve interviewed with is broken and needs fixing. Usually, you’re ushered into a room and over the course of an hour or two speak to the manager, who gives you background information on the company and the position they’re trying to fill, and one or more developers who ask a variety of technical and non-technical questions, trying to suss out whether or not you’re a “good fit” for the position. Usually the developers haven’t seen your resume until an hour before they meet you so, while I’ve had to play the “I don’t know but I can look it up” card on occasion, I’ve never really been thrown for a loop by any interviewer I’ve met. The process is pretty standard and cookie-cutter as far as I’m concerned but, since there are so many factors outside of the interview that bear on getting the job, I simply try and do the best I can and then forget about it.

The interview last week was one of the most exciting and humbling experiences I’ve had in my entire career. I spoke to ten people from programming, database administration, quality assurance, management, even the chief technology officer, alone or in groups of two, for five and a half hours. Everyone I met exhibited a passion for their work and knowledge of their craft. I also found out that all of them had met together the day before to decide what questions each of them were going to ask. Many companies talk about having a “culture” and a “mission,” but, clearly, here was a company that had incorporated it into their DNA. Probably for the first time I came away from the process with a crystal-clear picture of what it was like to work at this company day-to-day and deal with the issues the development teams deal with hour-to-hour.

I wish I’d gotten the job and I’m glad, right now, that I didn’t. Glad that I didn’t because the interview process made me realize that there are some “gaps” in my software development knowledge, .NET and !.NET, that I need to start rectifying before I can work at this type of company. Questions came up in the individual interviews that I couldn’t answer at all or couldn’t answer very well that made me realize that my gradual accretion of skills and experience over the past seventeen years has resulted in a pearl that could use some work. Questions like:

  • What things do you look for in a object-oriented class to tell if its design is “good” or “bad?”
  • What are some of the best practices you follow to make sure your .NET code will scale well?
  • What C# keywords are used to implement polymorphism? (The answer is the virtual/override modifiers. I knew that, should have remembered it, and am still kicking myself for flubbing that one.)

I’ve already started working on answering these and other questions, trying to replace the adhoc knowledge that I’ve gathered over the years with a little more rigorous, even “scientific” scaffolding.

I certainly hope I get a chance to interview with this company in the future.

This entry was posted in Software Development and tagged . Bookmark the permalink.