Part 2, The Interviewer...
In Part 1, I covered things that would possibly aid you as an interviewee, now onto the other side. I will be the first to say, I still have lots to learn about interviewing people, and some of what I list below, I need to practice as well.
All companies have their general interview process, being certain technical tests, standard questionnaires and particular processes. Going beyond those -because they are a necessary evil- other things I feel important when interviewing a developer are:
1. Probably the most important thing I look for in a developer, being a developer, is a passion for development. Sadly this has also proven to be the hardest thing to find. There was only one candidate out of the 20 something interviewed that showed some passion for development and he ended up accepted an architecture role, where he probably won't get to develop. I feel if someone shows passion for what they do, they will learn faster, be more focused, be more positive and generally a much safer bet to employ. Judging a developers' passion in an interview can be difficult, the best way I can think of is to explore an area of their expertise. Taking myself as an example all you would need to say is: "So I see you worked with the Spring Frame..." and that would be the rest of the interview.
3. Try get the candidate to relax, people do not show their actual personality under stress. So begin the interview with light personal questions, none that will get you in trouble with the HR department, but just enough to allow the candidate loosen up before jumping into the technical stuff.
4. Make sure everything required for the interview is available and ready. A clean whiteboard and markers or paper and pens if the candidate needs to draw or describe anything. Having both available is preferable as some people are really not comfortable drawing on a board.
5. People sometimes don't feel very comfortable asking the interviewer questions, specially in the case of panel interviews. Prepare a standard list of points that would answer questions the candidate didn't ask. I mentioned some in Part 1 and some examples as an interviewer may be:
The regular day /week in the life of a developer here looks like: weekly dev meetings, daily meetings close to deadline, multiple tasks, tech specs, code reviews and unit tests, etc etc.
We support 15 different application on a 24/7 basis every couple weeks.
The team size and structure is as follows: 12 people, 1 team lead, 1 architect, 6 developers...
The career path here is defined as follows Developer - Senior Developer - Architect - etc.
We supply you with a choice of laptop or desktop, duel monitors, 4gb RAM, IDE is up to you.
6. 'Go with your gut'; the general interview process is actually too short to be able to completely assess someones skills and compatibility. We work in a very high stress environment, with hundreds of different scenarios everyday and I don't think we can determine if the candidate will cope or excel within a 1 - 2 hour period. There are no hard and fast tests that will determine if the candidate will take responsibly for their work. If they will complete things in a timely manner under pressure. If they will boost the morale of those in the team, or will they turn out to be a complainer that will to jump ship at the earliest opportunity.
My final point to end off -something I heard from my wife's boss- which appealed to me greatly. This will probably get some reactions from people and unfortunately my current boss did not allow me to actually do this... but... In a perfect world, where you get a fair amount of high quality CVs, I would personally love to divide the large stack of applications in half and toss 1 half of them directly into recycle bin. If you are unlucky, it's probably better you find work somewhere else.
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...