Three years of interviewing Java developers and I am about to write it down... here it goes, here is my way of doing interviews.
Make a little preparation. I usually create a template for the interview - so my interview has desired meaning and all my questions are answered. Here is an example of my template:Past: [what he has done so far?]
Present: [what is he doing nowadays?]
Future: [plans for future?]
Rating: [areas like OOP, Java are rated, use your own scale]
Salary: [salary expectations]
Start date: [possible start date given by the applicant]
Notes: [something to remember the person]
I store all of these notes in my personal wiki provided by my company. So I can go back to my notes whenever I need.
Introduction is fine as the first step. As interviewer you get info about the applicant. The applicant should know what is your role in the hiring process (are you manger, java developer, architect...). But, don't waste time with this that much, there are more important things to discuss.
I usually ask developers questions related to these topics: OOP, Design paterns, Java, SCM and frameworks. But how to find what to ask first or where to put more focus on? I usually ask for the biggest project the applicant has participated. If there is some, then I ask how he did it? What was at the beginning of development - has he started coding immediately or is he used to do some design work? What about requirements and some specification? What about GUI protype? Is he using SCM? What design patterns were used and why? What frameworks does he know? Does he know the Java language? Here are few question (it might be beneficial):
- What is an interface and you can use it during coding?
- Have you used an interface? If yes, how?
- What is the difference between List and Set collection classes?
- Do you draw class diagrams before you start coding? If yes, give him an example - so he is forced to draw UML class diagram. After he is done, give him Eclipse or Netbeans and ask him for implementation of his diagram.
- Do you use JUnit? What about mocking?
- Do you prefare work on back-end or front-end?
- What design patterns have you used and how?
The answers for these questions are signs which will tell you where to dig in. If the application is not using design patterns, then you should be interested if he knows how to implement class diagrams and if he knows something about OOP. On the other hand, if the applicant knows nothing about SCM - then you can just rate it as 0 and continue with other areas.
By the way, if the application's answers are satisfactory and I like the project, I ask for the link where I could download or use it.
At this stage, you should have enough info to ask practical question. An example: let's say that the applicant told you that he has used design patterns in last project. Let's ask him "What design patterns have you used?". The answer might be "Composite and Singleton". "Hurray! I will let him to analyse a problem with tree structure and if that goes well, he could code it. If not I will let him implement the singleton pattern!", scream your brain with delight.
Let your applicant to choose programming IDE (usually Eclipse or Netbeans). So he is not limited by a tool and he can be as efficient as possible.
If your participant is not able to analyse and code all that what you gave him... let him to code some loop and sum some values from a field. You can also try to force him to write a unit test.
Well, this is the most interesting part of interview. You can see your applicant solving issues and explaining stuff under stress. There is nothing better what could help you to see what kind of person the application is and how he is going to behave in your team or company. So, keep your eyes and mind open!
Ask for expected salary and start date (at least these two are quite mandatory). You can also ask what is he doing in his free time. If he is playing chess and practising fight art, I am pretty sure you will remember him.
Don't forget that the applicant is nervous. So ask the questions properly and rather slowly.
Don't help him too much. He should solve the tasks you are giving to him. Your task is to watch and analyse how he is proceeding.
Give the same easy questions to junior and senior. So you are able to compare applicants in long term perspective. I like when seniors have to answer simple questions about programming - so I can see how good they are at explaining things.
An example of my notes:
Past: high school, worked also for company XYZ as Java developer
Present: looking for job
Future: wants to be architect
Rating: OOP: 2, UML: 1,5, Coding in IDE: 2, Java: 3, Frameworks: Hibernate, Spring
Salary: 10 000$
Start date: 24.12.2012
Notes: plays guitar and online games, practising box in free time