Why is it so hard to find good Java developers?
Here are some of the most common arguments why recruiting a good Java developer is damn near impossible
Like needles in a haystack of bored programmers, good
Java developers are in short supply. But who’s to blame?
Disinterested programmers? Misguided recruiters? Or is it the
Whether or not you agree, here are some of the most
commonly spouted arguments as to why it’s so hard to find a decent
The problem isn’t the language, it’s the people
Most developers want to make a difference. Most
developers even want to experiment. But more than all of that, most
developers want a job (and a
well paid one). The easiest way to get one is to stick with
Java – whether or not you enjoy writing it. That’s why many of the
world’s less passionate developers end up with the Java flock.
“I’m not implying that all Java developers are sheep,”
writer blogger Sandy Walsh, who argues that too many
developers are rewarded for blindly learning software packages
without understanding them. “There are many, many awe-inspiring
Java developers out there. Sadly, there are far more sheep.”
Sainsbury, an Android developer “stuck using Java”, says the
problem is Java writers trying to be architects. “[…] so often I
find I’m reading code that looks more like a plan for something
that solves a problem, rather than something that actually solves a
Rather than being able to skim code and see what the
person is up to, supervisors often have a tough time trying to make
sense of what developers pass on to them. “You have to dig deep,
you have to learn a whole new vocabulary of abused and tortured
words (“AbstractAdapterFactory”), you have to become part of the
The problem isn’t the people, it’s the language
Java blogger Michael O.Church argues it’s the other way
round. The issue with Java is that it’s hard to tell whether a
developer is good or not based on a short sample of code. The
average company will try to take a look at some examples of the
applicant’s code before hiring. The more careful dev teams will
usually call their applicants in for an assessment day filled with
various coding assignments.
[…] a bad hire can derail a project and, for small
businesses, sink a company. For this reason, technical interviews
at leading companies tend to be very intensive.
But given the notoriously long-winded nature of Java,
even a 500 line sample (which is often beyond the time constraints
of some supervisors) will not be enough to get a sense of what the
programmer is trying to do. And neither the recruiter nor the
developer have time for more.
Everyone speaks Java
As the first language everyone learns, many developers
can claim to have a “background in Java”. It’s a bit like finding
someone that speaks English. Most people claim they can speak it,
but finding someone that writes can eloquently finish a sentence
is… well, kinda hard… right?
To make it even more difficult, a Java developer with
only basic skills can make themselves look experienced. The more
simple test assignments put to them by a recruiter can often be
solved with a copy-paste from Stack Overflow. Meanwhile, a good
developer will often be too busy (or proud) to be subjected to
complex or lengthy coding assignments.
At the same time, young, ill-educated recruiters are
busy hunting for “ninja programmers”. Cordelia Dillon argues that the ideal developer
is less like the “rockstar coder” that many recruiters target, and
more like a sculptor or archaeologist.
If recruiters really want to talk about ninjas and
rockstars, or even sculptors and archaeologists, they should spell
out the qualities that are shared between those roles and the
software development roles they’re advertising. Candidates will
identify more with a list of desired skills than with a list of
You’re not looking properly
Companies are afraid of hiring employees whose skills will date
quickly, because most companies don’t like to start projects in
languages where it’s tricky to find developers. By playing it safe
with their enterprise solution, companies are essentially looking
for developers to blindly code Java. They enter as Java developers,
and they leave as a Java developers.
That’s why Sandy Walsh says the problem isn’t the
language, it’s the way companies hire. “If you build a product that
is going to have a long life-cycle, you have to assume the software
is going to have to live beyond the developers that assembled it.
If the application is written on niche or trendy languages or tools
it will be harder to replace these developers later. This is broken