Shortage of qualified Java programmers

[eglato]

Lately I have been conducting technical interviews to fill some Java
developer positions, and this process is becoming highly frustrating. Good
candidates are very hard to come by in the Atlanta area. I don't know
whether there is an actual shortage of Java programmers in the U.S., or
whether the situation is unique to our metro area, or whether we are just
relying on the wrong recruiting companies. In any case I repeatedly find
that a candidate will list every Java technology in the world on his
resume, but then when I quiz him on specifics he can't answer. Or perhaps
he knows the buzzwords, but then when I ask him how he would apply the
concept in a specific situation he gets it all wrong.

Here is a sampling of some of the questions I like to ask candidates:

* Write a program that reads strings from a text file, one per line, and
outputs a list of the unique strings along with their frequency of
occurrence. For example, this input:

Tuesday
Friday
Tuesday
Saturday

results in this output:

Tuesday: 2
Friday: 1
Saturday: 1

(To do this right they need to know about FileReader, BufferedReader, and
some collections API stuff.)

* Write a program to compute the number of hours in the current day,
correctly accounting for locale-specific time changes that might make the
current day more or less than 24 hours in length. (Simple Date/Calendar
API test.)

* Suppose I have the following class:
public class A { public String key; }
Write the code to sort a list of A's in ascending order by "key" attribute
using Collections.sort(). (Basic Comparator test).

When I first started this process I was actually concerned that such
questions might be too easy for programmers with 3+ years Java experience.
In fact the opposite has turned out to be the case. Some candidates even
seem surprised that I expect them to know the core Java API and be able to
use it to solve actual problems. I could understand if I were asking about
obscure stuff like reference queues, but my questions generally pertain to
basic aspects of the Java API that I use frequently in my work.

Is my experience typical? I read a lot about unemployment in the IT
field, but it just seems to me that if unemployment were a significant
problem there would be at least somewhat competent people sending out
resumes looking for work, and I'm just not finding that to be the case. Of
course my experience is limited to the Java job market in the Atlanta area
and I can't speak for other technologies or locales.

-eg

 

[Stefan Ram]

Here is a sampling of some of the questions I like to ask candidates:

Do they have to answer in speech, by writing on paper,
or by typing into an editor or a Java-IDE?

Are they allowed to use any references (for example, the
API-specification)?

Or possibly allowed to access the web as a reference?

Are they allowed to debug their program?

How much time are they allowed to use?

When I first started this process I was actually concerned that
such questions might be too easy for programmers with 3+ years
Java experience. In fact the opposite has turned out to be the
case.

If allowed to use the web as a reference, even one with

 

[Chris Smith]

When I first started this process I was actually concerned that such
questions might be too easy for programmers with 3+ years Java experience.
In fact the opposite has turned out to be the case. Some candidates even
seem surprised that I expect them to know the core Java API and be able to
use it to solve actual problems.

A few things to keep in mind here:

People are nervous in job interviews. Unless one of your goals is to
get people who work well in very stressful situations, you'd be well
advised to do everything possible to avoid exacerbating the problem. I
know very competent Java programmers who probably could not write three
sample programs like that in a typical job interview environment, and
asking would probably cause them to lock up completely and the interview
would be useless.

Also, your frequently used APIs are not others' frequently used APIs.
For example, I'd have to check the API docs to solve that "hours in a
day" problem, and I consider myself a very competent Java developer. I
may have a general idea how to proceed, but knowing the details of Date
and Calendar is not general-purpose Java API knowledge. In the real
world, there's always the ability to look things up when you don't know
them.

One thing that works well for me is to give candidates problem
descriptions about 24 hours before the interview, and ask them to
complete the code, bring it, and be prepared to discuss the choices they
made during the implementation. Yes, you could get a disparity in the
amount of time different candidates spend on the problem... but you'll
at least be able to have an intelligent conversation about code that's
written in a more realistic environment.

Is my experience typical?

I find that there is generally an abundance of basically qualified Java
developers. On the other hand, if you are working under severe budget
constraints (for example, a salary of less than US$40K), then you will
be quite unlikely to find them. I haven't looked in Atlanta, though...

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[eglato]

Do they have to answer in speech, by writing on paper,
or by typing into an editor or a Java-IDE?

Are they allowed to use any references (for example, the
API-specification)?

Or possibly allowed to access the web as a reference?

Are they allowed to debug their program?

How much time are they allowed to use?

I put them in front of a Windows PC without Internet connectivity or any
sort of reference material. They have their choice of a couple of
different editors but nothing resembling an IDE. There is no compiler and
I'm not interested the syntactic details of their code. I just want to see
if they are able to offer something intelligent without referring to any
reference material.

I've seen too many programmers that are dependent on IDE's to tell them what
a given class in the API can do. That's why I force them to rely only on
their memory.

I give them half an hour to answer five questions of the same general sort
as I posted. Note that I don't expect perfection--just something that
shows me they know what they are doing.

-eb

 

[Bob]

Well, I've been trying for months (many, many months) to get into a
serious computing role. My lower-second class degree in Maths and
Computer Science means that I am ineligible for graduate programmes. And
my total lack of commercial experience in programming means that
non-graduate roles won't touch me either.

I have the SCJP, but that proves only that I can read.

I could, given access to the API, offer solutions to each of your
questions. It would take me longer than someone that has been working
Java day-in, day-out, but that'd change after a burn-in period of
meaningful work.

The fact is, without a first or upper-second class degree, employers
don't want to waste graduate spaces on the likes of me. And recruiters
for non-graduate roles don't care about potential. They want only people
who have been doing *exactly* the same job already in a similar company.

At least, that's the picture I'm seeing in the UK. But, yeah, I'd guess
that the same situation occurs in most technology-hiring areas. The
criteria are very demanding, because companies have a severe "time is
money" attitude, and they want someone who can "hit the ground running".

 

[Jon Harrop]

I put them in front of a Windows PC without Internet connectivity or any
sort of reference material...

If you need someone to fill a seat from 9-5 then that approach should be
fine. If you want someone who will do good work then I'd suggest giving
them free access to as much information as possible.

It sounds as though you and I are quite similar in that we strive to be able
to work in vacuo. I use very few third party libraries when I code, for
example. However, I have found that working with a coder who is better at
using Google than I am can be very productive. When I can't implement
something myself, they can download it for me.

For example, a few of years ago I wanted to write a program to sort a
particle system by distance along a Hilbert curve. I spent a day trying to
write my own function to compute the distance of a point along a Hilbert
curve. After a day I had a function which was much too slow to use. The
next day, a friend spent five minutes on Google and downloaded a little C
function that I hadn't found. It was 100x faster than my function, and had
been very cleverly optimised.

Indeed, I prefer to be part of a team of people who have orthogonal talents.

 

[eglato]

It sounds as though you and I are quite similar in that we strive to be
able to work in vacuo. I use very few third party libraries when I code,
for example. However, I have found that working with a coder who is better
at using Google than I am can be very productive. When I can't implement
something myself, they can download it for me.

In fact I am constantly scouring sourceforge and apache for new components
that we can use, and I make heavy use of that stuff. For purposes of an
interview, however, I expect the candidate to have "internalized" the core
language and API. I agree that the ability to Google effectively for open
source components that fit your needs is very important; however it is a
skill that is awfully difficult to test in a job interview.

--eg

 

[eglato]

I have the SCJP, but that proves only that I can read.

I don't place much value on these certifications either. I've seen guys
with 95%+ scores on the tests that performed horribly in the interview.

I could, given access to the API, offer solutions to each of your
questions. It would take me longer than someone that has been working
Java day-in, day-out, but that'd change after a burn-in period of
meaningful work.

My position is that the time to study the API is *BEFORE* you get the job,
before the interview in fact. I need someone who knows this information
from day one and doesn't have to look things up constantly.

I used to think it might be reasonable to give people access to the API
documentation for tests such as these. However, in our system I ran across
an implementation of the Bubble Sort algorithm that someone had written
simply because they couldn't figure out how to sort a list of objects that
didn't implement Comparable. Hence the justification for the Comparator
question.

In real-world problems, when we are writing code at 90 miles an hour to meet
a deadline, few people take the time to scour the documentation to find out
exactly what they need. Hence I want them to have this information in
their brain (not the exact method signatures, but at least a general idea
that such-and-such method exists in such-and-such class that will do what
they need).

The fact is, without a first or upper-second class degree, employers
don't want to waste graduate spaces on the likes of me. And recruiters
for non-graduate roles don't care about potential. They want only people
who have been doing *exactly* the same job already in a similar company.

Many employers are like that, but not all. In my case I could care less
what industry he comes from. And we will cut the guy a lot of slack if he
seems to have high general intelligence, is quick thinking, knows core Java
and has a good foundation in CS. I find that if you are intent on getting
a candidate who is a match on 10 or so skills, you will overlook some very
talented folks who in the end will be much more valuable contributors.

 

[Lucy]

Lately I have been conducting technical interviews to fill some Java
developer positions, and this process is becoming highly frustrating. Good
candidates are very hard to come by in the Atlanta area. I don't know
whether there is an actual shortage of Java programmers in the U.S., or
whether the situation is unique to our metro area, or whether we are just
relying on the wrong recruiting companies. In any case I repeatedly find
that a candidate will list every Java technology in the world on his
resume, but then when I quiz him on specifics he can't answer. Or perhaps
he knows the buzzwords, but then when I ask him how he would apply the
concept in a specific situation he gets it all wrong.

Here is a sampling of some of the questions I like to ask candidates:

Sounds like you want a code monkey. Good luck.

 

[Lucy]

I don't place much value on these certifications either. I've seen guys
with 95%+ scores on the tests that performed horribly in the interview.


My position is that the time to study the API is *BEFORE* you get the job,
before the interview in fact. I need someone who knows this information
from day one and doesn't have to look things up constantly.

This sounds like you have some productivity goals and that you want to
be able to specify exactly where and how a given person meets or does
not meet these goals as opposed to wheater the goals are met or not.

It's like hiring an editor and not allowing them to use a dictionary.

 

[Paul Tomblin]

* Write a program that reads strings from a text file, one per line, and
outputs a list of the unique strings along with their frequency of
occurrence. For example, this input:

Runtime.exec("sort < input | uniq -c > output");

 

[Bjorn Borud]

[eglato <[email protected]>]
|
| * Write a program that reads strings from a text file, one per line, and
| outputs a list of the unique strings along with their frequency of
| occurrence. For example, this input:
|
| Tuesday
| Friday
| Tuesday
| Saturday
|
| results in this output:
|
| Tuesday: 2
| Friday: 1
| Saturday: 1
|
| (To do this right they need to know about FileReader, BufferedReader, and
| some collections API stuff.)

no, first and foremost the candidate needs to be able to recognize the
fundamental problem that needs to be solved and present you with a
plan for a solution. knowing the exact APIs for the standard class
library of Java is what you have computers for -- not people.

personally, I keep forgetting the exact APIs for file IO, so I check
the Javadoc or I use whatever capabilities the editor provides for
assisting me in the utterly tedious task of remembering which part of
the IO plumbing that provides me with a neatly line-based interface.

if you were to test me, I'd probably fail because I didn't remember
every detail of the API. also, if you relied on such tests, you would
fail, because it would tell me something about your company: if these
are the skills you measure and decide by, you have no idea what you
are doing and I'd be foolish to work for you.

| * Write a program to compute the number of hours in the current day,
| correctly accounting for locale-specific time changes that might make the
| current day more or less than 24 hours in length. (Simple Date/Calendar
| API test.)

oh, I'd fail that one too. spectacularly. mostly because anything
having to do with calendars or even formatting of dates in Java is
wrapped in lots and lots of tediously involved APIs.

yech!


| * Suppose I have the following class:
| public class A { public String key; }
| Write the code to sort a list of A's in ascending order by "key" attribute
| using Collections.sort(). (Basic Comparator test).

why? it takes a reasonably, un-stressed candidate less than a minute
to figure out how a Comparator works given the Javadocs. after which
it is likely that the knowledge will stay with him for a while after
that.

the intelligent question to ask would be:

"would you rather use a Comparator or implement the Comparable
interface if you wanted to sort instances of class A and why"

I would probably even introduce and explain the Comparator and
Comparable interfaces, along with the other relevant API bits before
asking the question to ensure I didn't needlessly stress out the
candidate.


this would give the candidate a chance to show you skills that are far
more relevant when writing code than merely memorizing an API.

| When I first started this process I was actually concerned that such
| questions might be too easy for programmers with 3+ years Java
| experience.

I'd fail them. I've used Java (on and off) since 1996. I use Java
every day now. I work on 3-4 different Java projects simultaneously.
I'd fail those tests miserably.

because I don't even bother to remember every bit of API. because
most of the time I have far more difficult problems to tackle than
looking something up in the J2SE Javadoc.


| In fact the opposite has turned out to be the case. Some candidates
| even seem surprised that I expect them to know the core Java API and
| be able to use it to solve actual problems.

it *is* surprising. it is *very* surprising. it wouldn't be as
surprising if you were interviewing for C++ grunts, since it has some
real ugly warts you *must* know of -- but Java? No.


| I could understand if I were asking about obscure stuff like
| reference queues, but my questions generally pertain to basic
| aspects of the Java API that I use frequently in my work.

then you can't be doing anything very difficult, because what you are
talking about here is just simple plumbing that nobody really bothers
to learn.


| Is my experience typical?

it is what I would expect, but it is symptomatic only of your poor
interviewing questions. I recently read a piece on interviewing
programmers written by Bill Venners. most of it I thought to be
rather obvious, but apparently there are still people who struggle to
think of meaningful ways of uncovering good programmers. anyway, the
article can be found at:

http://www.artima.com/wbc/interprog.html


| I read a lot about unemployment in the IT field, but it just seems
| to me that if unemployment were a significant problem there would be
| at least somewhat competent people sending out resumes looking for
| work, and I'm just not finding that to be the case. Of course my
| experience is limited to the Java job market in the Atlanta area and
| I can't speak for other technologies or locales.

your experience is limited, full stop.

-Bjørn

 

[Bjorn Borud]

[[email protected]]

| In real-world problems, when we are writing code at 90 miles an hour to meet
| a deadline, few people take the time to scour the documentation to find out
| exactly what they need.

first you apply selection criteria that favors those who do not refer
to the API documentation. then you point out that not making a habit
of referring to the documentation poses a potential problem.

also the "writing code at 90 miles an hour" bodes ill. does this mean
you expect projects to go awry? you expect to fall behind schedule
and work in a state of panic?


what kind of software does your company make, if I may ask?

-Bjørn

 

[Bjorn Borud]

[eglato <[email protected]>]
|
| * Write a program that reads strings from a text file, one per line, and
| outputs a list of the unique strings along with their frequency of
| occurrence. For example, this input:
|
| Tuesday
| Friday
| Tuesday
| Saturday
|
| results in this output:
|
| Tuesday: 2
| Friday: 1
| Saturday: 1
|
| (To do this right they need to know about FileReader, BufferedReader, and
| some collections API stuff.)

no, first and foremost the candidate needs to be able to recognize the
fundamental problem that needs to be solved and present you with a
plan for a solution. knowing the exact APIs for the standard class
library of Java is what you have computers for -- not people.

personally, I keep forgetting the exact APIs for file IO, so I check
the Javadoc or I use whatever capabilities the editor provides for
assisting me in the utterly tedious task of remembering which part of
the IO plumbing that provides me with a neatly line-based interface.

if you were to test me, I'd probably fail because I didn't remember
every detail of the API. also, if you relied on such tests, you would
fail, because it would tell me something about your company: if these
are the skills you measure and decide by, you have no idea what you
are doing and I'd be foolish to work for you.

| * Write a program to compute the number of hours in the current day,
| correctly accounting for locale-specific time changes that might make the
| current day more or less than 24 hours in length. (Simple Date/Calendar
| API test.)

oh, I'd fail that one too. spectacularly. mostly because anything
having to do with calendars or even formatting of dates in Java is
wrapped in lots and lots of tediously involved APIs.

yech!


| * Suppose I have the following class:
| public class A { public String key; }
| Write the code to sort a list of A's in ascending order by "key" attribute
| using Collections.sort(). (Basic Comparator test).

why? it takes a reasonably, un-stressed candidate less than a minute
to figure out how a Comparator works given the Javadocs. after which
it is likely that the knowledge will stay with him for a while after
that.

the intelligent question to ask would be:

"would you rather use a Comparator or implement the Comparable
interface if you wanted to sort instances of class A and why"

I would probably even introduce and explain the Comparator and
Comparable interfaces, along with the other relevant API bits before
asking the question to ensure I didn't needlessly stress out the
candidate.


this would give the candidate a chance to show you skills that are far
more relevant when writing code than merely memorizing an API.

| When I first started this process I was actually concerned that such
| questions might be too easy for programmers with 3+ years Java
| experience.

I'd fail them. I've used Java (on and off) since 1996. I use Java
every day now. I work on 3-4 different Java projects simultaneously.
I'd fail those tests miserably.

because I don't even bother to remember every bit of API. because
most of the time I have far more difficult problems to tackle than
looking something up in the J2SE Javadoc.


| In fact the opposite has turned out to be the case. Some candidates
| even seem surprised that I expect them to know the core Java API and
| be able to use it to solve actual problems.

it *is* surprising. it is *very* surprising. it wouldn't be as
surprising if you were interviewing for C++ grunts, since it has some
real ugly warts you *must* know of -- but Java? No.


| I could understand if I were asking about obscure stuff like
| reference queues, but my questions generally pertain to basic
| aspects of the Java API that I use frequently in my work.

then you can't be doing anything very difficult, because what you are
talking about here is just simple plumbing that nobody really bothers
to memorize.


| Is my experience typical?

it is what I would expect, but it is symptomatic only of your poor
interviewing questions. I recently read a piece on interviewing
programmers written by Bill Venners. most of it I thought to be
rather obvious, but apparently there are still people who struggle to
think of meaningful ways of uncovering good programmers. anyway, the
article can be found at:

http://www.artima.com/wbc/interprog.html


| I read a lot about unemployment in the IT field, but it just seems
| to me that if unemployment were a significant problem there would be
| at least somewhat competent people sending out resumes looking for
| work, and I'm just not finding that to be the case. Of course my
| experience is limited to the Java job market in the Atlanta area and
| I can't speak for other technologies or locales.

your experience is limited, full stop.

-Bjørn

 

[eglato]

Sounds like you want a code monkey. Good luck.

I want someone with good Java coding skills in addition to good design
skills, and I ask questions aimed at assessing both.

I personally have a bias in favor of proficient coders and my interviews
reflect that bias. I have never known a first-class architect who wasn't
also an awesome coder. Theoretically such a person might exist, but in my
experience I haven't seen it.

 

[Bjorn Borud]

[[email protected]]

| In real-world problems, when we are writing code at 90 miles an hour to meet
| a deadline, few people take the time to scour the documentation to find out
| exactly what they need.

first you apply selection criteria that favor those who do not refer
to the API documentation. then you point out that not making a habit
of referring to the documentation poses a potential problem.

also the "writing code at 90 miles an hour" bodes ill. does this mean
you expect projects to go awry? you expect to fall behind schedule
and work in a state of panic?


what kind of software does your company make, if I may ask?

-Bjørn

 

[Patricia Shanahan]

I put them in front of a Windows PC without Internet connectivity or any
sort of reference material. They have their choice of a couple of
different editors but nothing resembling an IDE. There is no compiler and
I'm not interested the syntactic details of their code. I just want to see
if they are able to offer something intelligent without referring to any
reference material.

....

As soon as I discovered the lack of Internet connectivity and reference
materials, I would have got up and walked out of the interview.

I simply don't program without reference materials. During the 32 years
that I was either a programmer or an architect, I never encountered a
real-world situation in which that was any handicap at all.

Now that I'm a student, I've been grumbling to faculty about closed-book
tests, requiring days of memorization. I though that sort of nonsense
was limited to academic life, so I'm a bit shocked to find it in
industry as well.

Patricia

 

[Bjorn Borud]

[[email protected]]
|
| I just want to see if they are able to offer something intelligent
| without referring to any reference material.

how does this reflect actual working scenarios?

| I've seen too many programmers that are dependent on IDE's to tell
| them what a given class in the API can do. That's why I force them
| to rely only on their memory.

so you are looking for people who can *memorize* things? aah! I'd
look for people who are able to solve problems and think critically
about what they are doing. people who are keen to understand and
improve. but hey, that's me.


memory? I hardly remember the exact commands I use in the shell of my
UNIX machines. thankfully I don't have to, because my command shell
has the ability to perform incremental searches in the command history
so that I can usually recall long commands, or chains of commands,
with just half a dozen keystrokes. without this functionality I
become really slow. with it I am way faster than anyone unable to use
it -- and since my mind seldom has to deal with the mere mechanics of
what I do, I can think about what I am really trying to accomplish.

| I give them half an hour to answer five questions of the same general sort
| as I posted. Note that I don't expect perfection--just something that
| shows me they know what they are doing.

I'd spend about 15-20 seconds looking at the questions, then I'd tell
you why I wouldn't even bother trying. your reaction to my response
would be critical to my assesment of you as an interviewer and your
company as an employer.

-Bjørn

 

[eglato]

first you apply selection criteria that favors those who do not refer
to the API documentation. then you point out that not making a habit
of referring to the documentation poses a potential problem.

No, my selection criteria favors those who are not *dependent* on the API
documentation and who are not dependent on an IDE. An interview is
necessarily a limited test upon which you must make a decision, and since I
can't test everything I test a few things that appear to correlate with
success on the job.

If you make these tests too easy then you aren't really testing anything,
and allowing them to refer to the Javadocs for Comparator, Calendar,
BufferedReader, etc., would make the test ridiculously easy.

also the "writing code at 90 miles an hour" bodes ill. does this mean
you expect projects to go awry? you expect to fall behind schedule
and work in a state of panic?

Like most American IT departments, panic is pretty much the normal state
Maybe this is poor management, but that's just the way it is.

what kind of software does your company make, if I may ask?

We make the software that controls insertion and extraction of Cadmium
control rods in nuclear reactors

 

[eglato]

People are nervous in job interviews. Unless one of your goals is to
get people who work well in very stressful situations, you'd be well
advised to do everything possible to avoid exacerbating the problem. I
know very competent Java programmers who probably could not write three
sample programs like that in a typical job interview environment, and
asking would probably cause them to lock up completely and the interview
would be useless.

One thing that works well for me is to give candidates problem
descriptions about 24 hours before the interview, and ask them to
complete the code, bring it, and be prepared to discuss the choices they
made during the implementation. Yes, you could get a disparity in the
amount of time different candidates spend on the problem... but you'll
at least be able to have an intelligent conversation about code that's
written in a more realistic environment.

Nervousness is always an issue in job interviews. Ideally I would prefer to
give them my test online so we can avoid wasting their time with an
in-person interview if they fail the test, and it would be a less stressful
environment.

The "take home" test has the disadvantage that it is less controlled. One
of the things I am trying to assess is how long it took them to solve the
problems. Thus the test I give is time-limited. It doesn't tell me as
much about the person's ability if I don't know whether it took them 30
minutes or 3 hours to complete the test.

Also, your frequently used APIs are not others' frequently used APIs.
For example, I'd have to check the API docs to solve that "hours in a
day" problem, and I consider myself a very competent Java developer. I
may have a general idea how to proceed, but knowing the details of Date
and Calendar is not general-purpose Java API knowledge. In the real
world, there's always the ability to look things up when you don't know
them.

I consider Calendar to be pretty basic stuff. There are numerous methods on
Calendar, but I only expect them to know 3 or 4 of those methods. Also, if
they don't remember the exact names of the constants (HOUR, MINUTE, etc.) I
won't count that against them.

It's just really difficult for me to believe someone knows Java unless they
can do basic time/date manipulation. When I used to do C programming,
every competent programmer knew how to use localtime, gmtime, mktime, and
the various fields in the tm structure. It seems like pretty basic stuff,
and at the very least should warrant a quick refresher prior to the
interview.