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.
The Absolute Don’ts in an Interview
If you’re the Interviewer:
Don’t mention too much about a previous job that involved another language/technology (say C++ or PHP). That tends to make your interviewer think that perhaps you don’t have enough experience in the Java field even though the job mentioned might even be a mixture of both Java and another language.
There’s more than one way to do it, so don’t turn down a job just because their technology is a specific Java-based technology such as EJB. Maybe the technology you think of (something like EJB) is too heavy for the product the company is developing (and therefore they decided to use a different technology that you could end up adding on your CV). Perhaps the company might not be aware of the benefits of using a different technology, and that’s where you could come in handy!
Design patterns are great and we’ve all come across them I’m sure. Make sure though you are aware of not only what the design pattern is used for, but also the particularities of their Java implementation — lazy initialization in a Singleton and the double-checking pattern anyone?
Don’t go mentioning multi-threading programming in your CV if you really haven’t got that much experience in it. While this is quite a generic statement, I’ve met candidates who claimed such skills only to turn out that the only threads involved in the application they worked on were the ones spawned by web container (Tomcat, JBoss etc), and these threads ran in absolute isolation of each other.
Network programming comes up quite often in job interviews nowadays, but unless you have worked at Socket/ServerSocket level don’t go boasting about it. The fact that your Tomcat-based app is accessible through HTTP over the Internet doesn’t quite make you a network programmer!
If you are the Interviewer:
Don’t repeat the same question in separate interviews! For instance, if you asked the first candidate about the wait/notifyAll behavior, then don’t ask your other candidates as well. Part of the questions you ask might reach the ears of the recruitment agency, and from there be passed to other candidates. They’ll be able to search for the answer prior to the interview. If it is a crucial part of the job and you definitely need to verify the candidates’ knowledge in a specific area, try to ask the question in a different manner (see above about re-phrasing your questions).
Don’t ask the candidate questions that only proves his/her knowledge in an area of Java that you don’t intend to use. If your application uses Properties for configuration but you don’t do any other I/O, then asking about RandomAccessFile is probably not needed. Instead ask questions around InputStream’s and Reader’s.
Technologies and trends come and go (CORBA anyone?) so think carefully about your plans regarding incorporating some technologies in the far or near future. If you’re planning on embracing Hibernate in more than a year for instance (perhaps after you have implemented all the features required for next big release), then there might be very little point (if any!) in requiring your candidate to be knowledgeable in such things, as you might find out later that a new JSR has made that technology obsolete!
Don’t ask generic questions. Most serious developers will know the concept of “polymorphism”, “encapsulation”, the single-inheritance model in Java and the difference in between an abstract class and an interface. If the candidate really isn’t familiar with these matters, it will become obvious throughout the interview.
Don’t start a whole discussion around subjects like “Java versus .NET.” We all know there is no definite answer to these discussions. Starting such a discussion might reveal indeed that your candidate is a Java evangelist, but does that help in developing your product?
For Everyone
And last but not least, since Oracle is acquiring Sun MicroSystems nowadays, perhaps it’s worth glancing over that PHP book after all! (Yes, that’s a joke!)
