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.

Understanding why a particular J2EE component is being used in your project is equally important. If the interviewer asks you, "Why did you use EJB in this project?" please do not answer, "This decision was made before I joined the project." Have your own opinion and explain why you think it was a good or bad choice for this particular project.

I keep hearing the "horror stories" about questions some people get during interviews. In my opinion, the interviewers should ask more open-ended questions about the applicant's prior experience, going into technical details when appropriate. I don't think it's fair to ask a person to write a Java program processing a binary tree or implementing a finite state machine. These are the things that can be looked up online or in the books when needed.

Good knowledge of the business terminology of your potential employer is also important. I'm not sure about the Silicon Valley or Europe, but here in New York just being a techie may not be good enough to get a senior job. For example, if you're applying for a Java position in a financial brokerage company and don't know what a short sale is, this may be a showstopper. If you are a senior developer, you should be able to hit the ground running… Try to find out from your recruiter as many details as possible about the business of your potential employer, do your homework, and you'll get the job! They are desperately looking for good Java people and you can be one of them.