I changed job recently. In this new job, it is refreshing to see Java used like in the old days, without the J2EE layers, and without the extra IBM layers of my previous job. Granted, the fresh Java approach does not apply to many projects, because a lot of apps are just about interfacing a database with a web interface. But Spring success showed that even for many of those projects, fresh Java approach with a small framework is enough.
This makes me think about people (on the net) complaining that in some job interviews, candidates were not able to tell how to get a EJB instance, etc.. Those kind of question are really stupid, as what matters much much more are EJBs concepts and concerns, i.e. what it tries to solve and how it tried to solve it, and for example, what is good/bad about it.
Java is much nicer to use in the old way. Everything seems fast to do. I am surprised it is more pleasant to work with Java in this kind of environment than in a web/J2EE environment.
One of the reasons I like to ask some specific questions in interviews is that some candidates have a good high-level understanding of a given technology but clearly have never REALLY used it, can't answer any detailed questions about implementing with said technology and aren't likely to do a good job their first go-out.
ReplyDeleteYou can't tell the difference between someone who's read a lot of articles on EJB and someone who's really used it unless you ask these sorts of questions.
Now, that said, if you've got the time to work with the candidate to help them progress, that may not be a problem, but you need to know in which category they fall before you make any sort of contract/hiring decisions, IMO.
It makes a difference whether the hire is for an existing team that uses a certain set of technologies or for a new team. Instead of an EJB expert a Spring guy might be equally good and properly better as EJB can be learned in class rooms while Spring is still something for self learners, which is usually the better type of developer.
ReplyDeleteYou cannot compare Java SE with Java EE. Which technology to choose depends on your application category, the non-functional requirements, given environment etc.
ReplyDelete