Interviewing enterprise java developers

Today’s Java job market is healthy. Major online job search engines show thousands of openings, and people are competing for these jobs. Skilled Java developers are just as popular as Visual Basic or PowerBuilder developers were back in 1996. There is a major difference though – back then, client/server developers could make a decent living by mastering one front-end tool and any major relational DBMS. These days a Java developer has to know about 10 different tools or technologies to find a good job and feel relatively secure for a couple of years.
During the last year I’ve been interviewing lots of J2EE developers, who are in demand again. But over the last several years job requirements, people, and resumes of Java developers have changed quite a bit and this is what I’ve noticed:
People do not call themselves Java developers or programmer-analysts anymore – most of them prefer the title of Java architect. Unfortunately, only some of them really understand how J2EE components operate and can suggest some design solutions.
Job applicants are more senior and I barely see any college graduates or junior programmers in the market. Many of the junior positions are being outsourced and the number of graduates with computer science degrees has declined over the past several years.
Java certification does not make your resume stand out. Actually, if a résumé starts with a list of Java certifications, most likely it’s a beginner. I’m not against certification as it helps you learn the language or a tool, and shows that you are willing and can study. But the fact that you have a Java certificate doesn’t mean that you’re a skilled professional.
Three to four years ago people with EJB experience were in high demand; now Struts is a more valuable asset. This is a good framework for Web applications, but it has the following side effect: some Struts developers don’t really

know what’s under the hood and how plain vanilla ser-vlets work. When I ask how an HTML form is being processed by a servlet, they start from the class Action.
On a similar note, some people don’t know exactly how JDBC works – they just pass a SQL statement to some wrapper class created by local architects and get the result set back.
I see a new breed of Java architects who used to be project managers. These people usually know their business really well, can talk about application servers, messaging and clusters, and capacity planning, but often fall short on Java technical questions.
Job requirements are longer these days and recruiting companies don’t even want to submit your résumé to the client if you have “only” 9 out of 10 required skills. As a matter of fact, recruiters screen candidates a lot better now.
Be prepared to pass at least four interviews to get hired. While back in 1999 two good interviews would be enough, in 2001 it was very difficult to even get an interview let alone a job!
What does a good J2EE developer have to know in addition to understanding the difference between abstract classes and interfaces? Usually employers are looking for people with at least 10 of the following skills: Java servlets, JSP, Struts or a similar framework, EJB, JMS, any commercial message-oriented middleware, JDBC, JNDI, HTML, XML, Ant, SQL, one of the major application servers, a couple of relational database management systems, any UML modeling tool, several design patterns (at least a Singleton!), and familiarity with Unix. Next year JavaServer Faces and Hibernate will most likely be included in this laundry list.
CIO, CTO & Developer Resources


1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)



Interviewing enterprise java developers