I have a pretty good track record when it comes to interviews. Although some of it has to do with software developers being in high demand, I also believe I have some talent for it.
If I do a series of interviews I will receive favorable replies from most employers. Some of this has to do with my level of preparation. While it is pretty involved and you can get by with much less, I find being thus prepared helps boost my confidence, which is perhaps the most important thing of all when it comes to interviews.
Here are some tips on the subject.
Interview preparation tips
1. Familiarize yourself with your resume.
You should already know all of this stuff but if you haven’t done any interviews in a long time it helps to go over your resume again. This will help you be sharp and give fast and exact answers to the interviewer’s questions (ie: how many years of experience with specific framework X). Answering rapidly will help project confidence.
2. Prepare answers to common questions.
There are some common non-technical questions that are often asked in interviews. Along the lines of: where do you see yourself in 5 years, why should we hire you in particular, what would your ex colleagues say about you, etc.
We all know these.
The trick here is to think about what is needed for the current position and what you could highlight from your experiences and existing skills that would be the best fit for those requirements. I like to do this thinking in advance and prepare for some of these questions. I don’t memorize exacts answers but rather think about the specific ideas I want to convey.
3. Read up on the company interviewing you
This is a given but I will list it here nonetheless. Do some quick research, even if it’s just reading a website on the company or it’s main product. Make an effort to show you did some basic research during the interview but try not to overbear the interviewer by completing each of his sentences with facts from your research.
4. Go over online sources that you use for personal promotion.
This could include your LinkedIn profile, personal website, blog and such. Make sure everything is up to date and take some time to freshen them up if need be. These may be looked at by the people interviewing you. They can also help you recall interesting stuff you did and that you could bring up during the interview.
5. Skim over favorite books
Skim rapidly over books you have already read and that inspired you. For me these would be books like The Pragmatic Programmer, Getting Real and Clean Code. I like to go over these and remember why they had inspired me in the first place.
Check for overall design tips and general concepts and make sure they are fresh in your memory.
6. Language and Frameworks
Go over and review technical details about the language and frameworks you have experience with or are interviewing for. Look for typical interview questions, read up on what was added in the latests versions.
7. Familiarize yourself with some design patterns
From time to time I still get questions similar to: “tell me about your favorite design pattern” or to talk about a specific design pattern of my choice. I usually re-check the details of two or three patterns I already know just to make sure everything is still fresh in my mind.
10. Fizzbuzz and other interview coding problems
From time to time people will ask you to solve a simple problem. One popular example is FizzBuzz(link http://c2.com/cgi/wiki?FizzBuzzTest) or variations thereof. You should be able to solve this one easily even if you don’t know it, but if you fear you will get nervous try it at home first.
Try looking into slightly more advanced problems. I tried Interview Cake (http://www.interviewcake.com/) back when it was free and liked it. There are also other sources of questions. If you are looking for a challenge rather that interview prep questions you might want to look elsewhere (Project Euler comes to mind http://projecteuler.net/).
11. Customize your preparation for the type of interview
If you are meeting with a head hunter you can skip the technical preparation. On the other hand if you know will be grilled by a senior developer and an architect focus on the technical and design side of the equation.
During the interview
During the interview use examples and anecdotes. People love stories and they help to make an impression. Of course you are in an interview so keep them short but if people ask you about your best quality, tell them how this quality manifested itself in your previous work rather than simply saying : “I have great attention to details!”.
For example, when people ask me : “what would your past co-workers say about you?”, instead of replying: “Oh, they would probably say…” I tell of an actual instance where a co-worker complimented me about my work and what led to this. If I can’t recall anything specific I will use a formula along the lines of: “since people often come to me for advice on X I guess they would say Y”. The trick here is to find, if possible, real examples from your work history that fit in with the job in question. Never make up stuff. I could give you reasons like it might make you look bad if you get caught, but the simple fact of the matter is that it’s neither moral nor ethical and that should be reason enough.
After the interview
Reflect on the interview itself. What went great, what could have gone better.
If some example or anecdote you told confused the interviewer or failed to make the point you were trying to make think about how you could reword it. Or maybe just drop it altogether for subsequent interviews.
Sometimes things don’t go smoothly. This has happened to me in the past because I was tired and didn’t have enough energy. If this happens to you don’t blame yourself and don’t worry, this isn’t a reflection of your preparation or your skills and it doesn’t necessarily mean you won’t get the job.
One of the first tips in The Pragmatic Programmer is “Think! Stop and think about your work”. This can be applied everywhere, including here. If you really want to get good fast at interviews you need to put in some focused effort in the process.