The Perfect Java Technical Interview
So lately I've been participating in a lot of interviews. My company is looking for skilled developers who know about continuous integration using Ant, extreme programming and lots of other good stuff. While I'm in Bangalore the idea is to go through lots of interviews so we can find that perfect candidate.
Joel Sposky (of JoelOnSoftware.com
fame) has a good article
on how important excellent programmers are. It's a valid idea and I generally agree. I'd rather have 3 excellent programmers than 100 mediocre ones. However, I'm sort of stuck in a situation where we can't hire rocket scientist programmers. We need solid developers with knowledge of Java/J2EE and various open source APIs.
In the olden days (1996-2000) the typical questions of "Difference between interface and an abstract class?", "Draw a UML class diagram for String.", "How would you design a connection pool?", "What is a race condition?", etc don't seem to be cutting out the chafe like they used to. I need a new set of questions that can really narrow down if developer's know their stuff, or are just really good at googling. (Don't get me wrong, googling is extremely important to a good developer.)
So I found my new favorite site, techinterview.org
(by one of Spolsky's programmers). It's full of great, useful brain teaser questions that should occupy a good 10 minutes in an hour interview.
We Don't Need no Stinking EJBs
(EJB 3.0) is out for public review now. It has some neat new features in it to try to simplify EJB development.
I've been working with EJBs for a long time (back since 2000 or something). I've always discounted Entity EJBs for being terribly ineffective. For a 2000-2003 a typical interview question was "When would you use Entity beans?" with the correct answer being "Never" and the incorrect answer being Sun's blargh about how great they are.
Stateful beans were also kind of a waste, I've only seen one instance where you would actually use a stateful bean instead of some other more lightweight cache (like HttpSession for instance).
That left Stateless EJBs which were handy for transaction control and distributed apps. EJB2.0 brought us MDBs which are pretty handy for async processes (way better than the old db or file pollers).
In my current architecture that my company is using, we implement SOA with EJB service implementations. We did this for 3 reasons: 1) we get remote access to services and can distribute services accross physical servers 2) we get container managed transactions 3) our previous technical director told the board of directors we were using EJBs so we had to.
So we have a bunch of services with EJB implementations. I was thinking about why we need the overhead of EJBs. I mean we never have remote access to our apps. There's no way we'd ever run the war and EJBs in separate JVMs. And our web service framework will provide remote access when someone really needs it (SOAP is just as fast as RMI). That kills issue #1.
A lot of our access goes to legacy systems that don't support J2C. So the EJB can't really control transactions. We have to code it ourselves. This kills #3.
Finally, number 3 isn't really relevant since the technical director is gone and the board has changed a lot since his edict.
So I'm thinking of just scrapping our EJBs and making our web apps call out to the standard, plain java classes. The service impls won't be distributable (away from the war) and they won't doa ny transaction magic for us, but they will be quick and easy to deploy. No more JNDI bindings and clustering settings. No more bean pools and crap like that. And now we can run in TomCat, which makes life easier (and cheaper).
I wonder if the spread of Web Services is really going to kill EJB. As most of the EJB features are overlapping with features provided by WS engines. Let me know if you're using EJBs and if so, why.
Oh yeah, IntelliJ 5.0
from IDEA just came out. It's the best IDE in the world (for any language). I know it's better than Eclipse 3.1, but I can't really remember why. I know it's more than Eclipse's stupid compiler.