While interviewing Java developers, I often ran into people who did not understand how some components of a distributed application operate and interact. In many cases this was caused by the use of one or the other framework that was shielding developers from the nitty-gritty details. It “s OK, as long as this person understands how other moving parts of the Web or enterprise application work.
Today, one of my former clients asked me to interview a job applicant for a position of a senior enterprise Java developer . After the interview I realized that I was talking to a representative of some new breed, which can be called framework coders. The guy had on his resume all required components (JSP, Struts, EJB, databases, application servers) utilized in various projects. The scariest part was that he did not lie on the resume: he really worked on these projects without knowing almost anything about neither Java SE nor Java EE.
Most of my questions were answered the same way: “I called a method on a custom-made framework rdquo;.
– How did you call a session bean (EJB) from your JSP?
– We had this framework, and I had to pass parameters to a special class “s method
– But if you had to call this session bean from a JSP directly, how would you do this?
– How did you get a connection to your database?
– We “ve had an XML file where we stored the data source parameters like user name and password.
– But where was this data source was actually defined/exist?
– We just had to pass data source parameters to a special class from the framework
– What “s the use of Java interfaces?
– It “s a convenient place to store all method signatures.
– What IDE did you use to write JSPs?
– This IDE was used by everyone in this company
– Where did you program business logic of your application?
– We were coding by the spec, which would explicitly say where to put the code.
I’m sure, this guy will find a job as the Java market is booming in the USA. But our profession is degrading, and it’s sad.