How to prepare a programming job interview
Since I have been myself hunting for a job recently, I thought it would be a good idea to share with you what I think are a few and basic key points to successfully face job interviews.
Before the interview
1.- Find out about the company. Visit their website. Usually, at the beginning of the interview, you are given the chance to explain what you know about the company. Use this opportunity to show that you have some interest in them, and that you have done some research. For instance, if you know the names of the people who are interviewing you, google their names, many times you can find valuable information about them in sites linkedin or their personal blogs.
2.- Review the specifications for the position. They may ask you about technologies that you haven’t used for a while. A quick review the day before the interview can make a huge difference.
3.- Make sure you know where the interview is and how to get there. An obvious one, but worth to remind. I find it very useful to bring with me some notes with the names of he guys interviewing me, the address and the phone number of the agency.
4.- Arrive always a bit before to the interview. Another obvious one, I personally like to arrive to the interview 5-10 minutes before.
During the interview
5.- If you don’t know the answer to a specific technical question, be plain and honest. There is only one thing worst than not knowing the answer to a question and that is not being sure about yourself. If you don’t know it, don’t fake it.
6.- If you know the answer to a specific technical question, be precise, concise and rational. Meaning: answer what they ask you about, not something related. Explain as much as necessary, no more, no less. If possible, explain why your solution is valid as opposite to another solution.
7.- If asked to do some code review, design… Ask permission to stand up and use the board to explain better your ideas (assuming there is a board in the room). It is not only easier to explain your ideas through diagrams, it also shows that you are confident and have initiative.
8.- Ask questions at the end of the interview. Having interviewed people myself, one of the things I most appreciate is people that come up with good questions at the end of the meeting. Some examples maybe asking about their continuous integration process, testing strategy, architecture… One particular question I like to ask at the end of the meeting is “do you have any concern about my technical skills?” This question works great, because you are opening a door for the interviewer to provide you with immediate feedback about the interview. Also, if they do have some concern, you have a second chance to revisit the areas where they think you may be not strong enough.
At all time
9.- Smile and look in the eye to your interviewer. Looking confident and friendly is very important in a job interview, eye contact and smiling is fundamental.
10.- Relax, try to enjoy. Relaxing in a job interview and approaching it from a “let’s have fun” perspective is going to help you a lot to finish convincing your interviewers that you are the right candidate for the position.
[EDIT] Best contributions IMHO from the coments
11.- Bob: I would add: Study logic puzzles, algorithms and data structures like crazy… at least if you are going to interview for a coding position at any kind of startup. My last interview (two weeks ago) consisted of 4 hours and 5 different interviewers, and I spent a good 3 hours at the white board solving, or trying to solve, tricky logic puzzles and programming problems. There was very little interest in my work experience and past projects, and I have 15 years experience. Google and MSFT have ruined the interview process…
12.- Amin: Good points. Another tip can be referring to your previous cool projects. For example when you are talking about a method or algorithm you can refer to a project that you have used that method or algorithm and talk more on the results.
13.- Rick: Good, but all rather reactive. The most important thing to remember is that your chances of getting the job don’t depend on the quality of your answers, but in the way you can make your interviewers feel about you.
One good starting point for that is to try to figure out before or during the interview what problem they have that they are looking to solve by hiring. Because it is rare that a company is looking for just another programmer like the other ones they already have. There’s a specific void that needs filling, and only a small part of that void is described in the job description.
Related posts:
![[Google]]( http://www.makinggoodsoftware.com/wp-content/plugins/easy-adsenser/google-light.gif)
[...] This post was mentioned on Twitter by Walter Poch and Julien Grenier, Alberto. Alberto said: Con todo el rollo de buscar curro en Londres, hacia tiempo que no publicaba en el blog, ahi va mi ultimo articulo: http://bit.ly/a5qD3v [...]
Tweets that mention How to prepare a programming job interview | Making Good Software -- Topsy.com
16 Aug 10 at 5:20 pm
I would add: Study logic puzzles, algorithms and data structures like crazy… at least if you are going to interview for a coding position at any kind of startup. My last interview (two weeks ago) consisted of 4 hours and 5 different interviewers, and I spent a good 3 hours at the white board solving, or trying to solve, tricky logic puzzles and programming problems. There was very little interest in my work experience and past projects, and I have 15 years experience. Google and MSFT have ruined the interview process…
Bob
16 Aug 10 at 5:52 pm
That’s definitely a goo advice, Thanks Bob for your comment!!
Alberto Gutierrez
17 Aug 10 at 12:42 am
Good points. Another tip can be referring to your previous cool projects. For example when you are talking about a method or algorithm you can refer to a project that you have used that method or algorithm and talk more on the results.
Amin
17 Aug 10 at 4:52 am
Item 6 hardly works that way. When getting interviewed by a developer, Egos always cloud the response. I posted this recently on another blog talking about a similar subject:
I was recently on a couple of interviews for different PHP positions. Two different interviews that relate come to mind:
The lead developer came in and asked me a series of questions designed to test my technical knowledge of PHP.
One of the questions was: “You have a SQL query that takes a long time to execute and is called multiple times during script execution. How would you speed up that script?”.
I asked: “Why is this query taking so long?” his response was: “Just because”
“Ok….” I replied then asked “Why is it called so many times? Can the data be cached or can the code be re-factored to prevent so many calls?”
“Yes… What would you do?” He reluctantly responded.
“Well 1st I would examine the code base to find out why it is called so many times. I am sure that you can get away with making the call once. Also since the query itself is taking so long, I would looking into using something like memcahced”
“Thats not really what I am looking for as an answer what else would you do?” he came back at me with.
This point in the interview threw me off completely. I was really at a loss here. What the was his correct answer. I gave up and asked him what he was looking for. He wanted me to say the buzz phrase: “Put the word static in front of the result array”. Both answers are correct however mine would not only help increase performance of the 1st call to the script but all subsequent calls (Since I am caching the results).
On a different interview with a different company, I had to take a multiple choice test. One of the questions was: “Which of the following is a correct Regex for matching an email address?”. After looking at them all I informed the interviewer that they all would fail since they would not match the “-” in domain names or .co.uk. His response was simply: “Well we do not have any users from domains like that”
“Of course” I thought “Because they keep getting denied at registration”
MANCHUCK
17 Aug 10 at 7:47 am
Hey Amin,
I totally agree, thanks for your comment!!
Alberto Gutierrez
17 Aug 10 at 11:18 am
Hey Manchuk!
Thanks for your comment, those 2 stories are amazing, I hope you will have more luck in your next interview.
Alberto Gutierrez
17 Aug 10 at 11:20 am
Good, but all rather reactive. The most important thing to remember is that your chances of getting the job don’t depend on the quality of your answers, but in the way you can make your interviewers feel about you.
One good starting point for that is to try to figure out before or during the interview what problem they have that they are looking to solve by hiring. Because it is rare that a company is looking for just another programmer like the other ones they already have. There’s a specific void that needs filling, and only a small part of that void is described in the job description.
Rick
17 Aug 10 at 1:27 pm
thanks for the nice article!
imho #10 is the hardest one
mk
18 Aug 10 at 5:00 am
Like 12), it’s always a good idea to illustrate technical points by an anecdote. It makes the interview more alive and gives you the opportunity to explain in a concrete case how you solved a problem or learned some useful thing…
This can be
- “oooh yes i read that on the famous XXX blog, he said that…”
- “Yep one day i got a deadlock problem on my db, but found out that it was because of a bad transactional attribute on some EJB…”
…
Lorber Sebastien
23 Sep 10 at 9:02 am