I remember my first interview. I had just gotten out of the Army and was finishing up my degree when a national bank asked me to come in for an interview. The position was for a programmer that would spend his day troubleshooting and fixing problems in securities floor trading. This was 2006 at the height of the bubble. The atmosphere was electric with the anticipation of moving into a large under-construction skyscraper, and I could feel everyone’s jubilation. Much like every other bubble, everyone thought this was a New Era.
As I was being escorted through the building to my interview, the recruiter made sure to impress me with things like sales growth, the new building, and even the amenities close to work. As I was escorted into the interview room, I thought that just maybe I’d want to work at that bank.
Until the interview started, that is.
Being a programmer, I thought the interview would revolve around programming — but it didn’t. No, the interviewers wanted to see how I handled pressure by throwing questions at me while I solved brain teasers on their whiteboards. They wanted to let me know that the trading floor was a hectic place, so I’d better be able to handle pressure. I think I made some offhand comment about how army training was a picnic. I’m sure that didn’t help.
So the interview comes and goes, and very little programming is discussed. It took them two weeks and me threatening to accept another offer for them to turn me down. I accepted that other offer, played with Perl for a few months, and then finished college. I was in the middle of the semester when I heard that everyone in the IT part of that division was being let go due to the economic downturn. The bubble burst.
I tell that story because it shows that programmers shouldn’t be taken in by the glitz or the glamor, but rather how the interview is conducted. The interview will tell you what you can expect in the day to day business; not the building. The interview is your most important insight into a company, and you should make the most of it. This post will take you through what you should and shouldn’t do in an interview, and what you should look out for.
Before the interview
Ask your recruiter how long the interview is going to be, and ask him for the names and email addresses of the ‘head’ interviewer. This will come into play later. You should have a list of questions to ask about the interview process:
- Will I write code during my interview?
- Is it a group interview? A solo interview?
- Who am I meeting during this interview? The Project Manager? The Team Lead?
Knowing the battlefield allows you to mentally prepare for the interview. If you don’t ask these questions, you only have yourself to blame when you’re surprised.
Also make sure you know what the dress for the interview is. Some require a suit and tie, others are ok with Jeans and Polo. Don’t overdo it, but don’t underdo it either. If it’s an east coast corporation, it’s more likely to be suit and tie. If it’s a small start up, they may say Jeans and Polo.
Arriving at the Interview Site
Most people would tell you to come 20 minutes early to an interview. Bad idea. If you do that, you’re just going to annoy the person interviewing you. They probably have real work to do, and every moment of their day is precious. Be respectful of their time, and even if you’re an hour early, announce yourself only 5 minutes before the interview is scheduled to start.
Length of the Interview
The length of an interview tells a lot about a company. A full day interview means that they have an in depth interviewing process, but that they don’t have ‘real work’ to do. This is good and bad. It’s good because it means that they don’t let just anyone in, but it’s bad because it’s probable that in 6 months to a year, you’ll be on the hiring team for the next candidate, and do you really want to spend all day interviewing a candidate?
A short interview (at most an hour and a half) means just the opposite: They have a lot of work to do; but their process may not be in depth enough to catch all the programmers that can’t program.
The sweet spot for an interview should be about two to three hours; at most a half-day. I’m thinking of your corporate, everyday Line-of-Business software development team. This doesn’t really apply to Amazon, Google, or Microsoft. They’re the big boys, they can do things however they want. Everyone else, however, has to meet deadlines and doesn’t have the resources to just interview endlessly.
Interview First Impressions
The moment you meet the interviewer is the most important. As a frequent interviewer, I’m looking for a few indicators when we first meet: How are you sitting when I come in? Are you slouched? Are you carrying anything with you? If so, is it something that is relevant to the interview? Paper and Pen are good, extra copies of your resume are even better. You did tailor your resume for the position, right?
Taking Refreshments
I recommend taking the interviewer up on the offer for refreshments, but stick with water. Drinking water will help calm you down when you’re nervous. Food == comfort. it works for water too. If you spill water, there’s no foul. If you spill coffee or tea, that could get messy. When you’re answering questions and you feel your mouth starting to dry, you’re going to wish you had water.
In the Interview Room
You’re nervous, you’re in a strange place, and your body is instinctively ready to fight or flee. It’s natural. Take a moment when you enter the interview room and check out everything, from the whiteboard to the chair situation. Wait for the interviewer to make the first move to the seat they want, and generally they’ll point to a seat that they want you to sit in. If it’s a good company they’ll have it set up already and it’ll be obvious where you should sit.
Tell me about your recent work history
When a interviewer asks this question, he doesn’t want to know about what your company sells, or what sort of product it is. He wants to know how your experience translates to the job you’re applying for. Measure your words so that everything you say is relevant to the question asked. Here’s an example:
If you’re applying for a mid-level developer job in C# and ASP.NET MVC, then they want to know how your skills fit in to that:
“George, tell me a little about your recent work history.”
Well, I’ve been developing software for 7 years in some capacity or another, and most recently I’ve spent my time designing and coding in C#. I use ASP.NET MVC for all of my side projects, and so far I’ve written two customized CMSs, a blog, and a stats site based on ASP.NET MVC. In my day job I spend all of my time in C#, with most of it going towards Winforms development and a slice of it going towards maintaining a ASP.NET MVC dashboard I wrote in C# for the project.
I didn’t tell the interviewer anything outside of what the position called for. If they want to know, they’ll ask. The worst thing you can do is talk about how you’re really good at Java and C++ when the position is asking about .NET development. It’s great, just not that relevant.
Writing Code
Practice writing code on a whiteboard at home. Ikea sells a glass whiteboard for $10, there’s no excuse not to have one on a spare wall. Whiteboard coding is a very important skill to have, because in most interviews you won’t be in front of a compiler. In interviews, syntax errors matter (You wouldn’t believe how many “Expert” C# developers tell me that the C# operator for modulus is ‘mod’), and whiteboarding will help you keep those to a minimum.
A great practice tool is to solve the Project Euler questions on a whiteboard first, and then type that code into a compiler (LinqPad is great) to check syntax. If you’re a .NET developer, spend a month without intellisense.
Practice Writing Class Diagrams and Design Patterns
I work on a project that is chock full of design patterns, especially the horrid singleton pattern. That means that new developers *must* know design patterns to be successful on this project. Overuse of design patterns is a bad thing, but if you have production software, you have to pick your battles. When I interview candidates, I’ll ask them to describe some design patterns for me, and I may ask them to sketch out those design patterns on the board. If you’ve ever implemented a design pattern, it’s easy. But, if you don’t have practical experience implementing design patterns, it’ll show when you’re asked this question.
Show that you’ve researched the company
When you come into the job interview, you should have a good sense of what the company does. I like to ask the candidates to tell me about my company. It shows which ones have actually researched the company. The company may have marketing speak that makes it hard to understand what they do. That’s normal, but even taking that into the interview and asking for clarification helps.
Asking Questions
Make your questions count. If you don’t have answers to these questions already, then ask them here. Have them written down when you go in to the interview so you don’t forget them. Don’t go away without asking good questions. A candidate with no questions is a candidate who isn’t interested in the position. If you’re not interested, I’m not going to hire you.
Watch out for Trick Questions
I ask trick questions. I ask them to see if the candidate will stick up for their viewpoint, or if they’ll correct me when I’m wrong. Other interviewers do the same thing. If you know you’re right about something, speak up. The point is, you’ve got to know you’re correct, otherwise you’re taking a big risk.
Close the deal
After you’ve asked and had all your questions answered, it’s time to close the deal. If you don’t think the interview has gone well, ask the interviewer for their feedback right there. If you think it has gone well, use that opportunity to sell yourself. Re-iterate your enthusiasm for the job and the company.
Next Steps
After your interview is finished, make sure to send thank-you notes (via Email is fine) to the interviewer and the recruiter. If you don’t know the interviewer’s email address, ask him for a card, or ask the recruiter. Out of the dozens of interviews I’ve done over the past year, only 2 candidates have sent thank-you notes. Those two candidates stood out.
Epilogue
An interview is a lot of work. It’s exhausting and it’s terrifying. Just remember why you’re there: To see if the company is a good fit for you. It may be an excellent company, but just like a relationship built on looks, you may find you have nothing in common. It happens.