The Dos and Don'ts of a Java Position Interview
I'm sure many of us in the Java field have been through this the interview that's going to get our next job! I'm also sure many of us have checked the usual places on the Net for hints about how to prepare for "the perfect interview."
If you're like me, I'm sure you found the usual "advices," advice that I personally never found to help that much. This is advice like show enthusiasm, ask questions, and make sure you study the company web site before the interview.
The reality is in most cases developers get a job through an agency and as such they don't know up front if the agency has dressed up (or even left out) some aspects of the job, It would be silly not to ask questions to find out exactly what the role is all about!
Secondly, you can study any company's web site and in most cases you're guaranteed to be faced with some PR statements such as "Our company is the world leader in this field" or "We are committed to leveraging the potential of our people." These only give you a vague idea of what they do, and more importantly, the part that you would probably be interested in, how they do it. So as I already said, I found most of the above-mentioned pieces of advice rather useless or redundant at least when you work in IT. What follows is a series of suggestions for what you should and shouldn't do based on my experience on both sides of the story: as an interviewer and as an interviewee.
The Big Dos in Java Interviews
If You're the Interviewee:
Know that it's all Spring and Struts nowadays. It used to be EJB and CORBA not so long ago... You need to watch for these technology "trends" and make sure you have them in your CV (or resume) if you have used them. In most cases you will be dealing with recruitment agencies whose CV databases are not the best they are probably written in PHP! so they'll be searching for these terms and might miss your CV even though you might be perfectly qualified for this. More specifically make sure you have "J2EE" in your CV as I found out that lots of recruiters out there have no ideas that JSPs are part of J2EE!
Understand that more companies put a lot of emphasis on development methodology and tools. It's not just frameworks, libraries and technologies that you need. Whether you come from a RUP background or you've been an Agile/XP adopter all of your life, make sure you stress that in the interview and your CV. Also mention any experience of continuous integration, build tools and even IDE's used. Agile, ANT, CruiseControl, JUnit and Eclipse seem to be frequent prerequisites to a lot of jobs out there!
Be aware of Infrastructure. Somehow related to the previous statement, while you write once and run everywhere in Java, things are not exactly the same unfortunately when it comes to the infrastructure, which in most cases will be some sort of web container running on a host OS. If you've been using Oracle 9 or 10 on both Unix-flavored platforms as well as using Windows, and if you have been involved in deployment and configurations then make sure you mention all of this in the interview if it is relevant to the position.
Pay attention. In order to figure out what type of job you're getting yourself into pay attention the questions that are asked. If they ask you how to map beans to tables in Hibernate, then it probably means you'll be a simple coder, more than likely maintaining existing code and adapting it on different platforms. If they ask about why Class.forName does not work, then they are probably looking for a problem solver so you might have to do some maintenance of your product in a customer site.
Ask about why did the company chose to use a certain technology. An explanation around why a SOAP-based approach was a better solution might indicate that the company is quite open to evaluating new ideas as opposed to a vague "it worked better for us," which might hide that fact that you'll be stuck (forever?!) with some old-style CORBA.
If you are the Interviewer:
Decide first whether you want a technologist or someone who is quite agnostic about frameworks involved. Someone who is a partisan of Struts will find it hard to let go when you're going to make the transition to another technology (possibly even reject the idea from the start), whereas someone who is quite agnostic will be more open about changing the technology. So you need to know upfront whether you're envisaging a migration to another platform of your product and be aware of such possible implications.
Phrase your questions such that they are not straight out of the "Teach Yourself Java in 24 Hours" book! Most of us know that Hashtable is synchronized whereas HashMap is not however, you can find this question (and the answer!) on a dozen sites (at least!) on the Ne. Try re-phrasing your question like "If you were to implement a component in an application that holds a dictionary that's used and updated by multiple threads at the same time, what collection class would you use for storing this dictionary data?" This will trigger a whole discussion around the subject, granted, however, it will touch on the synchronized/not-synchronized issue no doubt!
Think about how you will use the candidate. Think very careful whether your candidate will be used in maintaining the old (legacy?) code, be involved in the new "branch" of your product, or be involved in transitioning from one to another. No point in asking about the specifics of Classic tags involved in taglibs if the position will only deal with the (new) Simple tags, probably written from scratch. However, if your candidate will be involved in porting the codebase to the Simple tags model, a solid drilling in both aspects is probably required.
It's hardly possible nowadays to have a application that doesn't have some sort of backend storage (i.e. database). While Hibernate takes care of a lot of things nowadays in the Java world, it's worth asking your candidate some basic SQL questions.
Your candidate has likely used XML in the past in a project; however, does he/she know why the decision was made to go with XML? Why not use serialized objects instead? Asking questions around this will reveal a lot of their understanding of the XML pro's and con's quite likely touch on DOM/SAX and maybe even web services.