When I first got out of school I received two pieces of advice from several different sources:
You are interviewing them as much as they are interviewing you
Tell a story in the interview
Both of these points are obvious on their face, but rarely are ever grokked until people have been in the industry for at least a few jobs. I still see people who are older than I am who seem to believe that interviews are about something completely unlike what they are actually about.
An interview, done properly by both sides, is an honest attempt at appraisal to see if you will fit inside the company. The company is attempting to ascertain your qualifications and whether you will fit into their corporate culture.
Meanwhile, you should be doing the exact same thing.
In the excellent book Do What You Are : Discover the Perfect Career for You Through the Secrets of Personality Type it lists 10 items for each of the MBTI types that the type needs in their work environment. They are all pretty much spot on.
The important thing to recognize is that the job can be a great position and you can be a great person and a hard worker and would still be miserable in that position. Thus it is vital that when you are interviewing–especially if you already have a job, but even if you don’t–that you ask questions to try and figure out whether you really want to work there. Will their management style work with you, is their corporate culture something you feel that you can mesh with, and will you be doing work you believe in (or can at least live with yourself for doing)? Will you be working with and for people who are competent and reasonable?
Telling a Story
One of the techniques I like to employ in interviews is to try and answer questions with stories. “Tell me about your experience” should not be a dry recitation of your resume or what technologies you have worked with, but a broad story that provides a large amount of context. Don’t just say “I’ve used Hibernate,” but say “I used Hibernate in this context, to solve these problems, and this was my experience working with it.”
There are a few great reasons to do this:
It demonstrates that the item on your resume is not just there as a talking point, but that you have Real Experience™.
It shows an interest in what you have done previously.
It demonstrates your ability to talk with people.
It gives you some control over the interview.
It helps avoid detailed technical questions that you might not know.
I was talking with the HR representative of a company a couple of weeks ago who said that there were people who he would ask questions like “How did you use Jython” (Jython is one of the items on my resume) and they would answer “Let me look at my resume real quick….”
Beyond the obvious–that you should have your own resume down cold by the time you enter the interview–you should also be able to say more than “we used Jython on this product for x.”
“We used Jython on this product at this job in this capacity, here were my responsibilities with it, here is why we made that decision and here is what we learned.” The story starts with “once upon a time” and ends with “happily after,” and you should be able to do this automatically.
It shows that you were interested and engaged in what you were doing and it gives you opportunities to flesh out the context on your experience and show that you critically evaluated the tool and didn’t just copy a few functions from the website then slap it on your resume.
If you acquit yourself well during this process it shows that you can communicate effectively, something that is hard to do when you are consulting your resume to figure out where and how you used a language or a toolkit.
The last two points on my list tie together. Telling stories gives you some control over the interview: it lets you dictate the flow and guide to areas that you are stronger in, while keeping them from comparing you to a list of bullet points (do you have at least 10 years .NET experience?)
it also helps avoid the technical games that sometimes happen in interviews. I make a good software engineer, but I make a very poor compiler. While I may be able to spot the problem in a block of code, I am unlikely to be able to remember all of the different checked exceptions of a given class (that’s what Eclipse is for) and when separated from my IDE, documentation, and compiler I might stumble. So long as I control the conversation and can demonstrate my technical competence without playing a game where I have a higher chance of stumbling, the better.
This is not an excuse for not knowing your field, but there is a tendency at some places to ask “nanoquestions,” as Russ Olsen points out:
By all means do ask technical questions. But there is a difference between a technical question What is inheritance? What is the downside of using Java? and questions that could appear in Trivial Pursuit/Geek Edition.
By telling stories and gaining a measure of control, you can sometimes convince them that you know what you are talking about–and talk about interesting questions (what are the downsides to your favorite language?)–as opposed to “what is the airspeed velocity of an unladen swallow?”
He concludes with this statement:
One of the best interviews I ever had was with this guy who was an expert in a technology I know very little about. I got him to talking about his role in keeping a mainframe database system operational. He told me all about nursing this module along despite the fact that this other data segment was corrupt, of being awakened in the middle of the night because something had gone down. He described to me the procedure that they put into effect on 9/11 when one of their NY data centers was wrecked. He talked at length about the maintenance nightmares in some of the badly written code, and with some passion about the people he had worked with. He may have been BS’ing me the whole way, but I don’t think so. Near the end of the interview he expressed some surprise that I handn’t asked him any hard questions. That was the only thing he got wrong in the whole interview.