Discussions

General J2EE: Why is it so hard to find decent Java/J2EE programmers?

  1. I have been interviewing people for months now for our J2EE positions. In London you get applicants from all over the world, yet the quality, on average, is shocking. We're not looking for a super-duper expert guru, just a competent programmer with relevant J2EE experience. Everyone's got the fabulastic introductory paragraph (don't get me started!) and all the buzzwords and acronyms, but when you get them in for an interview, they're useless. At the end of the interview, we have a simple home-grown test that we get them to look at. It does some String comparisons using == and equals(), some null Strings for a bit of spice, and the only slightly 'tricky' one compares two different String objects that has the same contents (the correct answer is that Strings in modern JDKs are immutable, therefore == will still return true). Almost no-one gets it all right. A lot of them get NOTHING right. I had a guy yesterday who told me you can't compare Strings using == (had many of those), and then he added that you can only compare Objects with ==, not Strings!!! And he's got a degree from a fairly good uni. I had a contractor once who coded the following line: if (anObject.equals(null))... Help! Tell me the average Java programmer is not a complete dimwit! Cornel Masson Shazam Entertainment, London.
  2. It's not just in London. There are a lot of reasons why a workforce could be insufficient. In this case, it probably has to do with: 1. The ease of successful bullshitting (lack of followup on applicants, particularly work history and educational background, access to google, ...) 2. Copy and paste 3. Bad process enforcement 4. Most HR departments being chock full of morons 5. Headhunters, no better than used car salesmen 6. Poor education, lack of computing history, context, and leaky abstractions (oh, I'm sure it's marketed as "the best") 7. Too much stress put on education vs. talent and experience 8. Most projects are poorly run, poorly planned, and can get by with cheaper, relatively useless labor, and still meet some amount of success to further justify spending on higher priced managers, kickbacks, and consultants when things go haywire I was aiming for the proverbial 10, but I need some more coffee. :)
  3. Not because of immutability[ Go to top ]

    It is not a good idea to compare Strings using == since it will only work for literal values and String constants. It is not because of immutablity that == may work (although it is necessary), it is because the compiler interns literal and constant String values. What about if the String had been constructed from inputs, eh?
  4. Re: Not because of immutability[ Go to top ]

    It is not a good idea to compare Strings using == since it will only work for literal values and String constants. It is not because of immutablity that == may work (although it is necessary), it is because the compiler interns literal and constant String values. What about if the String had been constructed from inputs, eh?
    Agreed. I forgot to mention that our test defines all the test strings as literals.
  5. Since you have had to vent it here I would assume that you interviewed 15 to 20+ of them therefore I would think your interview process is flawed (or atleast I would like to ask you thinking along that line). Or you are just being di** about how your test is making too many "experienced java developers" fail.