The Dos and Don'ts of a Java Position Interview, Page 2
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?
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!)
About the AuthorLiviu is a Java consultant living in the UK with a lot of experience with high-availability systems, mostly in the online media sector. Throughout his years of working with Java, he came to realize that when performance matters, it is the "low level", core Java that makes an application deliver rather than a bloated middleware framework. When the injuries acquired playing rugby with his team, The Phantoms ( http://www.phantomsrfc.com) in London, he writes articles on Java technology for developer.com.