Part 1, The Interviewee...
Firstly let me say, I am by no means an expert interviewer, I have just recently been included in the whole interview process. I originally wanted nothing to do with it actually, but now several months and 20ish interviews later I quite enjoy it. The only frustrating thing is how people actually come to an interview, in one word: Unprepared. This may be a South African thing, where the demand way out strips the supply when it comes to software developers, but sadly the quality of the candidates coming for interviews is really disappointing. I am going to try keep this technology agnostic, as it is not only limited to Java, my wife -a dev team manager in a .Net technology company- goes through the same frustrations when looking for new staff.
So out of the 20ish candidates I have interviewed in the past months only 3 potentially had the skills we required, 1 was hired, 1 accepted an architect position at another company rather than the senior developer we were offering and the other's personality was not a match for the team. The other 17-20 people were either unprepared, unskilled or incorrectly represented by a recruitment agency.
I personally have not been for an interview in about 4 years, so my own interview skills may be a little rusty. However if I had to apply some of my experiences of being the interviewer into being the interviewee. I would do the following, above and beyond the standard interview success practices of being presentable, on time, professional, confident and having a self sales pitch.
1. If you are going through a recruitment agency, make sure that they show you the CV (Curriculum Vitae / Resume) they will be sending to their clients. Make sure you are happy with it. I would say about half the CVs we get really do not accurately describe the candidate. When this happens it immediately changes the tone of the interview and your chances diminish greatly.
2. Find out upfront what kind of tests the company makes candidates do, and prepare for those.
In the case of my current employer:
2.1 There is a general "aptitude" test, which I personally don't agree with, but it generally covers classic word sum, riddle, trick and what's the next in the sequence type questions. There seems to be a lot of companies doing this kind of test these days. So it is well worth searching the web and practising this kind of test. One site I did find quickly India Bix, would be a good way to prepare.
2.2 A Tech Check, which is a scaled down version of the official certifications and as such the same preparation can be done for those.
2.3 Finally after the initial interview there is a long Psychometric Test. Which you can't really prepare for.
3. Find out who is interviewing you, and just to a quick web search on them. They may have a blog, a book, a twitter feed, public facebook account all of which can give you vital information that can drastically alter the entire interview. Take myself for example, if you knew I was interviewing you and you found my blog, you would find this article along with a whole bunch of technical stuff about the environment / company that can give you a very nice advantage in the interview.
I Google all the candidates, only fair that they do the same.
4. Stay Current, we are in a ever changing industry, companies and your current employer may not be able to keep up with the changing technology environment, but this doesn't mean we as IT professionals shouldn't. As an interviewer I often ask the questions, "how do you stay current?", "what do you read?". How I try stay current, is this blog and Google Reader, I follow and read many Java, development and architectural related websites and blogs. I also plan to get the new Kindle in the next week or so, as there are quite a number of books that I need to get through.
5. Make sure that you read and know the common interview questions for your technical specialities. There are a lot of resources online to help with that. You don't want to show up to an interview as a Hibernate, Spring, Oracle or Asp.net 'expert' and then get put on the spot by a relatively simple well known interview question.
6. Ask questions, from the interviews I have done very few people have even asked the basic questions. It is important to ask questions, firstly there are things you should know about your working environment and you to engage the interviewer. Some example questions I would ask are in no particular order:
6.1. What does a regular day in the life of a developer or architect here look like?
6.2. What applications are you supporting? What are the support hours like?
6.3. What is the team size and structure?
6.4. What is the career path and policies on training?
6.5. What IDE, and what kind of hardware will be supplied?
6.6. Why are you hiring? Is it because the team is growing? (or are people jumping ship... don't ask that :) their answer will imply that.)
6.7. What are the greatest challenges facing the new person in this position?
6.8. What is the management style of my direct manager?
6.9. Who will evaluate my performance? When? How?
On a side note:
If I was to find new employment I would firstly research companies I want to work for and see if I could directly deal with them, as I stated before recruitment agencies can sometimes do you more harm than good. Search the top 100 companies to work for in your country / city, check the technologies they use, their culture, their location. I would also use social networks, a candidate that comes recommended from a current employee already has a huge advantage to just some random Joe Smith off the street.
In Part 2, I will discuss some of my experiences on the other side of the table as a interviewer.
I have recently been slacking on content on my blog, between long stressful hours at work and to the wonderful toy that is an iPhone, I have...
I make no claim to be a "computer scientist" or a software "engineer", those titles alone can spark some debate, I regar...
I saw an article (well more of a rant) the other day, by Rob Williams Brain Drain in enterprise Dev . I have to say, I do agree with some o...
This series of posts will be about me getting to grips with JBoss Drools . The reasoning behind it is: SAP bought out my company's curre...
I recently finished 97 Things every programmer should know . Well to be completely honest I did skim over a couple of the 97, but all and al...