How to Interview: Part 1

Interviews suck.  There’s no way around it.  It’s impossible to know exactly what your interviewers are going to expect or want.  Recently I was going through my feed reader and came across this article about “How to not suck at a technical interview.”  Prior to reading that, I had been planning on writing something about interviewing and using that as inspiration, I decided I’d finally do it.  In the past 2 years, I’ve interviewed about 200 to 250 people for technical positions (primarily .Net Engineers).  In the past 6 months, I’ve been in many interviews as my current employer has been looking for new .Net engineers. While Brad’s post, and this one, focus primarily on technical interviews, the core principles of both his article and the series I’m planning to write here can be taken and applied to any sort of interview.

1.  Know your abilities and rate yourself right

One of the first things I do on every interview is ask the person to rate themselves on a few technical categories.  It’s a straight 1 to 10 scale where 1 is they haven’t heard of it and 10 is they could answer any question I could come up with.  I never want to hear a person rate themselves a 10.  More than 99% of the time, you don’t know everything about a topic and you should assume that.  What’s worse, most people that do rate themselves a 10 can’t answer most of the basic questions that I’d expect a 5 to answer.  There’s no way you know everything so rating yourself a 10 is only going to hurt you.

2.  Be honest on your resumé

In today’s economy, people will do just about anything to land an interview at a good company.  It seems for a lot of people, that includes throwing every buzzword they can find on to their resumé.  When working on your resumé, the rule of thumb you should follow is, if you put it on there, you should be able to answer questions about it.  In detail.  If you say you worked on Nhibernate on a project, I want to know how you set it up.  If you’ve worked on both WCF and ASMX web services, I’m going to want to know the differences between them.  Saying that you worked on a project where the tech lead incorporated something is not good enough.

3.  Know your resumé

Nothing is worse than asking someone to go over their past work and project experience and having them pick up their resumé and read from it line by line.  If you’ve made it to a phone or in-person interview, I’ve obviously at least spent some time looking at your resumé.  You should know what’s on it and you should know it well enough to talk about it without looking at it.

4.  Be prepared to answer questions about gaps and job hops

If you’ve had 4 different jobs in the past 4 years, I am going to want to know why.  Any recruiter will want to know why as well.  The reason here is obvious:  if you left (or were asked to leave) your last 3 jobs after less than a year, why wouldn’t you do the same thing if I hire you?

5.  Tell me if you don’t know the answer to a question

A few things can happen when I ask you a question you don’t know the answer to:

• You think you know and answer incorrectly
• You don’t know and you make something up and get it right (lucky but not very likely).
• You don’t know know and you make something up and get it wrong (more likely)
• You say you don’t know

If you haven’t sent any red flags up before we got to this question, I’m going to ask you how you’d find the answer.  An interview is not all about finding out about the experience a person has.  Especially in technology, the experience you have today might not matter tomorrow.  I want to also find out how you’re going to figure problems out going forward.  When it comes to this, again, be honest.  Would you talk to coworkers?  Would you search on Google or Bing?  Would you try to find a book that might have the answer?  Would you post in a forum?  One caveat to this is that I don’t want to hear you say that every time a situation like this comes up you go talk to your friend Steve or your architect Matt.  If that’s your answer for everything, feel free to send Steve or Matt’s resumé my way.

6.  Research the company you’re interviewing at

At a bare minimum, you should have some knowledge of what the company you’re interview at does.  Scour the internet for information on the company.  Understand how their business works.  As an example, if you were interviewing at US Airways for a software engineering position, try to learn about how an airline works.  What sort of problems do they solve?   What could they do better?  Spend sometime trying to solve the travelling salesman problem.  The point is, just knowing that US Airways flies planes from points A to points B isn’t enough.

7.  Be ready to write code

I’m sure I’ll catch some flak for this one but, if you’re interviewing for a programming position, I’m going to expect you to be able to write some code without an IDE.  Intellisense is awesome and helps me get some things done a lot faster, however, I still know what I’m doing without it and you should too.  Someone could answer all of the technical questions I could dream of and not be able to write a line of code.  Bottom line: if you interview with me, you’re going to have to write code.  Period. 

8.  Follow up with any questions you didn’t have the answer to

One of the things I find most impressive with an interviewee is when they follow up after a phone or in-person interview with the answers to questions they missed.  It demonstrates that they’re paying attention and are enthusiastic about both the job and staying knowledgeable.  I know it’s hard to remember after a phone interview what the questions were that you missed, but it’s not too hard to jot down a word at the time the question is asked so you’ll remember afterwards.  I can’t stress how easy this is to accomplish and how impressive it seems when you do.

9.  Be passionate about what you do

The biggest thing I’m looking for when I interview someone is passion.  If I’m trying to find a .Net Developer, I want to hear about how they play with the latest beta release to come from Microsoft.  If they’ve done ASP .Net and PHP, I want to know all about the differences and why they like one over the other.  This is incredibly hard to quantify but incredibly important if it’s down to you and another person for a job.  Every single time I’m going to take the person that’s a bit less experienced but really passionate about what they do over the person that has more experience but comes off as just a 9-5 worker.

10.  Ask questions about the position / team / company you’re interviewing for

When I’m done asking my questions, I always give the interviewee the chance to ask whatever questions they have.  This is your chance to find out about the job you’d be doing, the team you’d be on, and the company you’d be working for.  Remember that this isn’t just about me interviewing you, this is about you interviewing me.  You could go into an interview thinking the company you’re talking to rocks only to find out that it sounds like a corporate hell hole.  Asking questions like the following can help me with my perception and understanding of you and they can make sure you’re applying at the right place:

• How is the team structured?
• What sort of projects would I be working on?
• If I find something being done that I think can be improved, what would I do?
• Why do you like working here?
• Is there typically a lot of documentation surrounding projects or very little?
• If I have questions, can I go directly to the person that has the answer or do I need to go through someone else? (I know this might sound crazy but I’ve worked at a company where I was actually not allowed to talk to a Database Administrator directly)

11.  Ask what you could have done better at the end

Of all the interviews I’ve done, I’ve only had 5 to 10 people ask how they did at the end of the interview and how they could have done better.  If the person interviewing you gives a damn (and if they don’t they shouldn’t be interviewing people) they should give you an honest answer.  By the time you’re talking to a recruiter again, the people that interviewed you have probably already forgotten why they passed on you and how you did in your interview.  Sometimes you’re not going to get a very detailed answer, but any feedback can help.

The biggest lesson that can be learned from all of this is to just be honest.  Overstating your skill level, lying, and blind guessing will end up hurting you in the end.  Furthermore, never be afraid to ask a question of the people interviewing you.  If your question is reasonable and they won’t answer it, you’re probably not interviewing at the right company.  I’m hoping to have a few more entries in the coming weeks and months about interviewing. I’m definitely going to talk about how to be the obvious choice if you’re a junior- or entry-level person as well as go over to the other side of the table and talk about how best to interview people if you’re trying to fill a position.

*Note:  These are my opinions and thoughts and don’t reflects the opinions or thoughts of my employer, my dog, Bananarama, or anyone else.