Java Interview: tips for the interviewer

This is a brief entry about how an interviewer should conduct a Java based interview. I have been on both side of the table and this is only based on my own observations.  I think most interviews that I attended in the past, and possibly some I have conducted myself, focus on the basic concept. I accept that developers should be aware of the language principles, but how can an interviewer test more advanced principles?

The interview time have to be split into: 

1. Theoretical conceptsThis 1st phase is about asking the common questions about OOP concepts, differences between interfaces and abstract classes, differences between List and Set, multithreading and so on. If it is required to store answers, do provide a written paper and avoid multiple choice questions. In my experience, open-ended questions allow the developer to express his knowledge better. Multiple choice questions provide unnecessary hints to question answers. Even if I did forget a terminology or a definition by looking at the various answers provided, I can pick the right answer 9/10 times. Theories are central to practices but make sure can be related to the role you are recruiting for.An important point when interviewing a developer, if you have a developer present during the interview, avoid asking domain specific question unless it is something common. I had some interview with senior and lead developers asking questions about a programming problem they have recently encountered and were able to fix after spending months working on it, how am I supposed to know about that unless I have encountered the same issues in the past.



2. Practical test
   In order to test a developer capability for the role, it is a must that he/she undertakes a practical test. You do not need to give the developer code with bugs for him/ her to fix, I believe this approach is not very useful. I would suggest that all interviewers prepare the developer to take a practical test using their favourite tools (provide two of the most common open source IDE) and provide them with a simple problem domain. In my experience, I had to write some simple factorial algorithm (a single recursive method) to a domain centric web service application (no DB, store data in memory instead) and to more advance concepts. If application multithreading is part of the main day to day job, then ask the developer to write a simple application that shows that.
   This practice exposes several features of the developer; from its reasoning by writing simple algorithm to coding practice (commenting and Java best practices) and problem solving.

After all, I believe that programming is more about logical reasoning and coding. The more senior we get in our profession, the harder it is to answer simple questions with straightforward answers; we get carried away and provide a complex answer to something so simple. We cannot talk baby talk anymore; our tongue is full of jargon. All developers should follow the KISS principle when answering theoretical questions but ultimately they should excel in the practical test. If they are good enough, they should use a text editor to write their codes and compile it through the shell (JVM command line).
Another thing that all interviewers should know; developers have very good memories and therefore can memorise more than 115 interview questions; I would recommend you to focus more on a practical test.

This was a brief entry for interviewers. The web is full of tips and questions for the interviewees and I do not see any point in duplicating them here.  As usual, this is based on my experience and belief, you are always welcome to comment. Also, support my blog by visiting my advertisers (by clicking on the link on the right) they might have something that you might need.