왠만해서는 copy & paste는 안하려고 하지만 이거는 나중에 혹시나 없어질까 봐서 해둔다.
The Dos and Don'ts of a Java Position Interview
By Liviu Tudor
I'm suremany of us in the Java field have been through this — the interviewthat's going to get our next job! I'm also sure many of us have checkedthe usual places on the Net for hints about how to prepare for "theperfect interview."
If you're like me,I'm sure you found the usual "advices," advice that I personally neverfound to help that much. This is advice like show enthusiasm, askquestions, and make sure you study the company web site before theinterview.
The reality is inmost cases developers get a job through an agency and as such theydon'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 findout exactly what the role is all about!
Secondly, you canstudy any company's web site and in most cases you're guaranteed to befaced with some PR statements such as "Our company is the world leaderin this field" or "We are committed to leveraging the potential of ourpeople." These only give you a vague idea of what they do, and moreimportantly, the part that you would probably be interested in, howthey do it. So as I already said, I found most of the above-mentionedpieces of advice rather useless or redundant — at least when you workin IT. What follows is a series of suggestions for what you should andshouldn't do based on my experience on both sides of the story: as aninterviewer and as an interviewee.
Know that it's all Spring and Struts nowadays. It used to be EJB andCORBA 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 haveused them. In most cases you will be dealing with recruitment agencieswhose 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 eventhough you might be perfectly qualified for this. More specificallymake sure you have "J2EE" in your CV as I found out that lots ofrecruiters out there have no ideas that JSPs are part of J2EE!
Understand that more companies put a lot of emphasis on developmentmethodology and tools. It's not just frameworks, libraries andtechnologies that you need. Whether you come from a RUP background oryou've been an Agile/XP adopter all of your life, make sure you stressthat in the interview and your CV. Also mention any experience ofcontinuous integration, build tools and even IDE's used. Agile, ANT,CruiseControl, JUnit and Eclipse seem to be frequent prerequisites to alot of jobs out there!
Be aware of Infrastructure. Somehow related to the previousstatement, while you write once and run everywhere in Java, things arenot exactly the same unfortunately when it comes to the infrastructure,which in most cases will be some sort of web container running on ahost OS. If you've been using Oracle 9 or 10 on both Unix-flavoredplatforms as well as using Windows, and if you have been involved indeployment and configurations then make sure you mention all of this inthe interview — if it is relevant to the position.
Pay attention. In order to figure out what type of job you'regetting yourself into pay attention the questions that are asked. Ifthey ask you how to map beans to tables in Hibernate, then it probablymeans you'll be a simple coder, more than likely maintaining existingcode and adapting it on different platforms. If they ask about whyClass.forName does not work, then they are probably looking for aproblem solver — so you might have to do some maintenance of yourproduct in a customer site.
Ask about why did the company chose to use a certain technology. Anexplanation around why a SOAP-based approach was a better solutionmight indicate that the company is quite open to evaluating new ideasas opposed to a vague "it worked better for us," which might hide thatfact that you'll be stuck (forever?!) with some old-style CORBA.
Decide first whether you want a technologist or someone who is quiteagnostic about frameworks involved. Someone who is a partisan of Strutswill find it hard to let go when you're going to make the transition toanother technology (possibly even reject the idea from the start),whereas someone who is quite agnostic will be more open about changingthe technology. So you need to know upfront whether you're envisaging amigration to another platform of your product and be aware of suchpossible 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 Hashtableis synchronized whereas HashMap is not — however, you can find thisquestion (and the answer!) on a dozen sites (at least!) on the Ne. Tryre-phrasing your question like "If you were to implement a component inan application that holds a dictionary that's used and updated bymultiple threads at the same time, what collection class would you usefor storing this dictionary data?" This will trigger a whole discussionaround the subject, granted, however, it will touch on thesynchronized/not-synchronized issue no doubt!
Think about how you will use the candidate. Think very carefulwhether your candidate will be used in maintaining the old (legacy?)code, be involved in the new "branch" of your product, or be involvedin transitioning from one to another. No point in asking about thespecifics of Classic tags involved in taglibs if the position will onlydeal with the (new) Simple tags, probably written from scratch.However, if your candidate will be involved in porting the codebase tothe Simple tags model, a solid drilling in both aspects is probablyrequired.
It's hardly possible nowadays to have a application that doesn'thave some sort of backend storage (i.e. database). While Hibernatetakes care of a lot of things nowadays in the Java world, it's worthasking your candidate some basic SQL questions.
Your candidate has likely used XML in the past in aproject; however, does he/she know why the decision was made to go withXML? Why not use serialized objects instead? Asking questions aroundthis will reveal a lot of their understanding of the XML pro's andcon's — quite likely touch on DOM/SAX and maybe even web services.
Don't mention too much about a previous job that involvedanother language/technology (say C++ or PHP). That tends to make yourinterviewer think that perhaps you don't have enough experience in theJava field even though the job mentioned might even be a mixture ofboth Java and another language.
There's more than one way to do it, so don't turn down a jobjust because their technology is a specific Java-based technology suchas EJB. Maybe the technology you think of (something like EJB) is tooheavy for the product the company is developing (and therefore theydecided to use a different technology that you could end up adding onyour CV). Perhaps the company might not be aware of the benefits ofusing a different technology, and that's where you could come in handy!
Design patterns are great and we've all come across them I'msure. Make sure though you are aware of not only what the designpattern is used for, but also the particularities of their Javaimplementation — lazy initialization in a Singleton and thedouble-checking pattern anyone?
Don't go mentioning multi-threading programming in your CV ifyou really haven't got that much experience in it. While this is quitea generic statement, I've met candidates who claimed such skills onlyto turn out that the only threads involved in the application theyworked 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 interviewsnowadays, but unless you have worked at Socket/ServerSocket level don'tgo boasting about it. The fact that your Tomcat-based app is accessiblethrough HTTP over the Internet doesn't quite make you a networkprogrammer!
Don't repeat the same question in separate interviews! Forinstance, if you asked the first candidate about the wait/notifyAllbehavior, then don't ask your other candidates as well. Part of thequestions you ask might reach the ears of the recruitment agency, andfrom there be passed to other candidates. They'll be able to search forthe answer prior to the interview. If it is a crucial part of the joband you definitely need to verify the candidates' knowledge in aspecific area, try to ask the question in a different manner (see aboveabout re-phrasing your questions).
Don't ask the candidate questions that only proves his/herknowledge in an area of Java that you don't intend to use. If yourapplication uses Properties for configuration but you don't do anyother 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 thinkcarefully about your plans regarding incorporating some technologies inthe far or near future. If you're planning on embracing Hibernate inmore than a year for instance (perhaps after you have implemented allthe features required for next big release), then there might be verylittle point (if any!) in requiring your candidate to be knowledgeablein such things, as you might find out later that a new JSR has madethat technology obsolete!
Don't ask generic questions. Most serious developers will knowthe concept of "polymorphism", "encapsulation", the single-inheritancemodel in Java and the difference in between an abstract class and aninterface. 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 aJava evangelist, but does that help in developing your product?
And last but not least, since Oracle is acquiring Sun MicroSystemsnowadays, perhaps it's worth glancing over that PHP book after all! (Yes, that's a joke!)