Shortage of qualified Java programmers

[Eric Sosman]

...

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

Different strokes. I'd have declined the offer of the
PC (after all, the O.P. says he isn't actually interested
in the code) and just talked out my approach to the problem.
Along the way I might have said "There's a class with a line-
reading method that would be convenient here; the name escapes
me right now and I don't recall off-hand exactly what its
constructor takes, but the JavaDoc would tell me everything
I need in less than two minutes."

If the O.P. wouldn't accept such a response, *then* I'd
have walked out -- and he'd probably have been glad to see
me leave, proving that happiness is not a zero-sum game.

 

[Eric Sosman]

Lucy wrote:




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.

IMHO there is far too much emphasis placed on writing
code, and far too little on reading it. The commonest
programming assignment of all is "Program X does almost
what we want, but it has bugs/lacks features/runs slowly
or in some other way doesn't quite fill the bill. Your
job is to alter it to meet our need."

Someone who's an "awesome coder" might approach the
task by discarding all of Program X and starting from
scratch -- and sometimes, evaluation of Program X may well
indicate that this is the best approach; I've taken that
route occasionally. More often, though, you need somebody
who can find his way through Program X's two million lines
of code to the places where changes are needed; the skills
to navigate a large program that you cannot hope to understand
in complete detail are not exactly the same skills used when
writing new code in a vacuum.

 

[.]

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.

My experience is similar. I'm not in the U.S. but north of you in Canada.
I've talked to people outside of the role of interviewer, i.e. just
chatting with people I meet outside work or on the web. A number of people
believe that everyone lies on their resume. If they are honest they will
not get an interview. So they lie on their resume too. One person who has
applied for jobs with this mentality now interviews people. He told me he
assumes people lie on their resumes. So if you apply to a position with
him and you are JUST qualified for the position he will not call you in
for an interview because he assumes you lied or exaggerated and are
underqualified for the position.

Just last week I interviewed someone who looked amazing. She is a Sun
Certified Programmer, she list EJBs, Servlets, JSP, JMS, JDBC. she worked
on WebLogic 7.0, WebSphere 4.x and 5.0, Tomcat 4.x and 5.0. She developed
using Eclipse and WSAD. She is expert in SQL, Oracle and DB2. The list
goes on and on. She even listed companies where she 'used' all her skills
and knowledge.

When she was brought in for the interview we kept it very friendly. She
felt at ease. She was always a little nervous. I made it clear that the
interview was not black and white. No one is expected to know everything.
There will be some questions she will have trouble with. That does not
mean she is not the best candidate. This put her more at ease. So much so
that after 15 minutes she admitted that she was certified years ago (she
couldn't remember if it was Java 1.0x or 1.1) and she has barely used the
knowledge since. She worked on projects that used a lot of the skills and
technologies but she was not directly responsible for any of them.

Many of the things listed on her resume she had not used for 4 or more
years. Most of them have changed a lot since then and her ability to
recall things was weak to none existent.

This was probably the worse case of exaggerating I had seen in some time.
Most the time it is junior employees who exaggerate and they know not to
claim too much or we'll know they are lying.

I continue to tell people, if you lie on your resume then I cannot trust
you. If I cannot trust you then I cannot give you any authority. If I
cannot give you any authority then I cannot give you any responsibility.

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.)

We'd ask questions like this. They don't have to write something that will
compile. Just has to have the basic idea. I understand that some good
programmers rely on their compiler and development tools to help them out.
But if they don't even know they need FileReader and BufferedReader then I
have a problem with them.

* 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.)

Not something someone I'd hire needs to know.

* 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).

Our work does use Collections and sorting so this is the sort of question
we might ask.

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

Yes. I was too.

What is the difference between private, protected and public? Many
know what public is but they get the difference between private and
protected confused.

I've asked, "How do you compare 2 String objects?" You'd be surprised the
number of people who answer, "Use ==."

What is the difference between an interface and an abstract class?

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.

Yes, that is my experience. I've also noticed a growing number of messages
from people, on newsgroups and forums, starting with, "I just got this job
doing XXX. How do you do XXX?" To which a number of people respond, "How
did you get the job if you don't know how to do it?" Answer: they give
good interview. This is why my current company has a set of multiple
choice questions we ask on a computer. The first day they have you sit in
front of a computer with a quiz on it. You have 2 hours to answer the
quiz. The first half is multiple choice. If you get more than 50% wrong on
the multiple choice the interview is over. The second half is short
answer. After the short answer questions are complete the technical
manager will ask you to explain anything that is not clear in the short
answer section.

I thought I'd blown it because the technical manager had no questions for
me after the quiz. Turns out he was pleasantly surprised because I
answered all the short answers correctly. The questions were things a
first year student would know.

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.

My own experience looking for work is that many of the people I worked
with would stop looking when they landed a job. Especially in the past few
years. The people who are out there looking for work are usually the
people who got laid off or fired.

When times got tough a few years ago the site manager showed his true
colours. I looked for work for 2 years. I was good at what I did. I was
horrible at writing a resume. After 2 years of research and what little
feedback I could get from interviewers I now know how to write a killer
resume.

Maybe the best Java programmers in your area are really bad resume
writers.

Also, an interesting observation... all the people hired here since I
joined are people gainfully employed but unhappy with their current job
(due to merger or change in management). If you are looking at people who
are unemployed and surfing the job sites, maybe you are looking in the
wrong spots.

 

[eglato]

A number of people
believe that everyone lies on their resume.
If they are honest they will
not get an interview. So they lie on their resume too. One person who has
applied for jobs with this mentality now interviews people. He told me he
assumes people lie on their resumes. So if you apply to a position with
him and you are JUST qualified for the position he will not call you in
for an interview because he assumes you lied or exaggerated and are
underqualified for the position.

I have just about decided that lying on resumes in IT is almost universal.
The candidate really does have to lie just to get through some moron
recruiter's ridiculous screening procedure. Most candidate don't expect
anyone will notice, but I generally take the time to quiz them on a pretty
broad sampling of the skills they list, so the chances are reasonably good
that I will catch them if they are lying.

I think many hiring managers don't have the knowledge themselves to
correctly ascertain whether a candidate is lying, so most of the time the
liars just slip by.

Just last week I interviewed someone who looked amazing. She is a Sun
Certified Programmer, she list EJBs, Servlets, JSP, JMS, JDBC. she worked
on WebLogic 7.0, WebSphere 4.x and 5.0, Tomcat 4.x and 5.0. She developed
using Eclipse and WSAD. She is expert in SQL, Oracle and DB2. The list
goes on and on. She even listed companies where she 'used' all her skills
and knowledge.

When she was brought in for the interview we kept it very friendly. She
felt at ease. She was always a little nervous. I made it clear that the
interview was not black and white. No one is expected to know everything.
There will be some questions she will have trouble with. That does not
mean she is not the best candidate. This put her more at ease. So much so
that after 15 minutes she admitted that she was certified years ago (she
couldn't remember if it was Java 1.0x or 1.1) and she has barely used the
knowledge since. She worked on projects that used a lot of the skills and
technologies but she was not directly responsible for any of them.

Many of the things listed on her resume she had not used for 4 or more
years. Most of them have changed a lot since then and her ability to
recall things was weak to none existent.

I've seen very similar things in my interviewing. This is why you have to
pretty much quiz them on everything they claim to know that is in any way
relevant to the job.

I continue to tell people, if you lie on your resume then I cannot trust
you. If I cannot trust you then I cannot give you any authority. If I
cannot give you any authority then I cannot give you any responsibility.

*Amen*! Who wants to work with someone who has already lied to them? I
have a very hard time trusting you to work on my project if you have lied
to me.

We'd ask questions like this. They don't have to write something that will
compile. Just has to have the basic idea. I understand that some good
programmers rely on their compiler and development tools to help them out.
But if they don't even know they need FileReader and BufferedReader then I
have a problem with them.

My point exactly. It amazes me how some programmers are profoundly offended
by the idea that I might ask them to actually know stuff without depending
on a book or the Internet.

I am probably a little old-fashioned (15 years in the industry), but when I
was in college we took closed-book tests and were given programming
problems that would make my sample questions look like an absolute cake
walk.

What is the difference between private, protected and public? Many
know what public is but they get the difference between private and
protected confused.

I've asked, "How do you compare 2 String objects?" You'd be surprised the
number of people who answer, "Use ==."

What is the difference between an interface and an abstract class?

I have asked your first question too, and about 50% of candidates don't know
that a protected method or field is accessible within the same package.

I'm also shocked by how few people know the specific semantics of hash
codes. A substantial fraction of candidates actually think that hash codes
must be unique, so that you can save some programming effort by just
implementing equals() in terms of calling hashCode() on the two objects and
returning whether their hash codes are equal. This is stuff you learn in a
freshman data structures course!

Maybe the best Java programmers in your area are really bad resume
writers.

It's possible, though most of the time the recruiting companies "clean up"
and reformat the resume prior to submitting it.

 

[eglato]

Also, you've figured out with what you get with a 3+ years programmer.

If that doesn't meet your criteria, try hiring 5+ or 15+ year
programmers. They cost more, but you get what you pay for. Its alot
cheaper to do it right than wrong, wrong again, wrong again...

There's a difference between speed and velocity.

The really amazing thing is that doesn't seem to matter too much whether
someone has 3 years or 15 years experience. On both ends of the spectrum
you will find equal numbers of morons. I've talked with people with 10+
years experience and 5 years Java experience who don't know the proper
semantics of hashCode() methods and don't know how to write a comparator.
IMO that is absolutely pathetic.

 

[Andrew McDonagh]

.. wrote:
snipped




My point exactly. It amazes me how some programmers are profoundly offended
by the idea that I might ask them to actually know stuff without depending
on a book or the Internet.

I am probably a little old-fashioned (15 years in the industry), but when I
was in college we took closed-book tests and were given programming
problems that would make my sample questions look like an absolute cake
walk.

You still seem to be missing the point that almost everyone has said.
Testing someones ability to remember or indeed know, parts of J2SE is
secondary to whether they are a good developer.

I've been a Java developer for 6 years solid now and in that time I've
never had to use file io. Does this make me a bad developer, just
because I wouldn't be able to answer your limited question?

No, of course not.

If you asked me questions about CORBA, Design patterns, design
principles (LSP, SRP, OCP, etc) then I'd be able fully answer them.

Heck even after all this time, I still don't remember what methods the
String class has - but then again, as a developer its not my job to know
every detail of the J2SE, its my job to know where and how to find the
answers to help me design and implement.

 

[Mickey Segal]

I've been a Java developer for 6 years solid now and in that time I've
never had to use file io. Does this make me a bad developer, just because
I wouldn't be able to answer your limited question?

Even more generally, file I/O is the sort of thing for which you usually
look up how you did it last time and just do the same thing again. I do the
same even for an actionPerformed method. Life is open book. If you want a
good test of how someone would do in real life, have them come in with their
laptop, give them internet access and ask them to solve some problems. If
you develop an idealized model of what someone should remember you are
likely to come to silly conclusions such as there being a shortage of
qualified Java programmers.

 

[Patricia Shanahan]

My point exactly. It amazes me how some programmers are profoundly offended
by the idea that I might ask them to actually know stuff without depending
on a book or the Internet.

I am probably a little old-fashioned (15 years in the industry), but when I
was in college we took closed-book tests and were given programming
problems that would make my sample questions look like an absolute cake
walk.

....

As a student for the last few years I've been stuck with closed book tests.

I think the whole closed book testing business is the result of some
people combining a useful ability with a blind spot. There are people
who remember everything they understand. I meet a lot of them at UCSD,
but there are some in industry. It is a mildly useful ability.

The blind spot is that some people with that ability think that everyone
has it, and therefore assume that anyone who does not have the facts
memorized has no understanding and would have to study the topic from
scratch before being able to apply it.

My brain doesn't work that way. For example, I used JDOM in a program I
wrote last year. Given documentation, I could use it again, without
the practice programming I did first time round to make sure I
understood it. On the other hand, beyond broad outline, I could not
answer questions about it today without access to the documentation.
[Well, I could now because I just spent a couple of minutes looking back
to some of my JDOM-using code, and reminded myself of how it works.]

I think people with the remember-everything-understood talent tend to
gravitate to the academic world, because closed book tests do not waste
their time. Any closed book test costs me days of rote memorization,
regardless of how well I understand the material or how technically
demanding it is. I forget the memorized material within a few days of
the test, so the effort has no long term value. The understanding and
skills stick, and can be revived very quickly, but not the memorization.

Last time I was a student, in the early 1970's, when I only had a few
years experience, I assumed the professors knew best, and there was some
practical value to closed book testing. That value didn't show up in the
following 25 years as a programmer and architect.

Patricia

 

[Kevin McMurtrie]

[Kevin McMurtrie <[email protected]>]
|
| My opinion is that pounding out syntax-perfect code in emacs or a text
| editor is obsolete by 15 years.

that's what they said 15 years ago too. and 30 years ago. sure, we
have more tools now (within editors) to automate tedious tasks, but we
still write a lot of code manually.

| It leads to a lot of inefficient and narrow-minded designs because a
| person can only remember a small percentage of the classes needed in
| a large project. I look for somebody who can come up with elegant
| solutions to common but difficult problems, somewhat like your first
| question.

elegant solutions are invariably solutions that are simple. simple
solutions are easier to remember, usually have fewer corner cases and
are easier to verify as correct. however, there is nothing simple
about discovering simple solutions for problems.

if, by narrow-minded, you mean programmers who lack the imagination or
experience to, at each crossroads, evaluate several options for
solving the immediate problem at hand, I'd agree. this is partially
what I mean when I talk about "dogmatic programming style" -- people
who believe that there is a small number of rules and patterns that
can be applied universally to all problems, and good code will
result.

Yes, examples would be:

Hacking a Vector and Hashtable together to create an ordered map when
LinkedHashMap does it already.

Downloading a ResultSet into a Vector of Hashmaps, because that's easier
to use.

Shoehorning features into one's personal set of utilities when much
better solutions exist in the JFCs or application codebase.

"Copy & paste with changes" over and over again when an IDE could factor
out superclasses and interfaces with a few mouse clicks.

Dead code lying all over the place. Dozens of unused imports left over
from templates.

Grossly inefficient coding habits because of debugging with
System.out.println() statements rather than a source level debugger.

Abuses of APIs because the JavaDocs weren't read. Also, no JavaDocs in
written code.

Rethrowing exceptions as RuntimeException rather than fixing the
'throws' declarations and try/catch blocks.

Mangling the crap out of a piece of code to avoid having to change a few
simple references to it.


Doing the above work correctly is time consuming with a simple editor.
These tasks are part of why IDEs were created. They take the tedium out
of coding so you have a little more precious time to do it right.

 

[Chris Uppal]

Hmmm. I imagine if I had to use a system that didn't have a link to a
local copy of the standard library API documentation, I would use Google
to find it. Darned if I'm going to try to navigate java.sun.com until I
come across it!

Agreed that java.sun.com is not a nice place to have to rummage around in.

But all I was meaning was that /for the purposes of the interview/ the link to
the JavaDocs should be provided. Googling for sample code would be out.

-- chris

 

[Chris Uppal]

Wow, that's six minutes per problem, in a job interview setting, often
using stuff like java.util.Calendar.

Perhaps the idea is that they should attempt, say, two questions from the five.
That would be a lot more reasonable, and would also mitigate the problems
caused by different programmer's internalising different parts of the APIs.

The OP didn't sound like it, though.

That might even work quite well (assuming the JavaDocs /were/ available). One
point you could talk about is why the candidate chose not to answer the other
questions. "Well, I haven't worked with Calendars much, but I do know that
date calculations are easy to get wrong, and that the Java date API is
complicated, so I didn't want to get into a tangle in the middle of an
interview". "Oddly enough, I've never had to do any file IO in Java -- most
persistence is handled by the database, logging is handled by log4j, network IO
is handled at a higher level of abstraction, and so on. Frankly, I don't think
that IO is something that modern programmers should normally be doing 'by
hand' -- there is nearly always a better way." Whatever you might think of
such answers, at least they'd be informative.

-- chris

 

[Chris Uppal]

IMHO there is far too much emphasis placed on writing
code, and far too little on reading it.

Sensible point.

(BTW, that is a point in favour of looking for programmers who have
internalised large chunks of the API -- to the point where they can /read/ the
code without constantly having to look up details. Of course, when reading
the code, you don't need to have memorised the class and method names; you just
have to recognise them in context.)

-- chris

 

[Bjorn Borud]

["Chris Uppal" <[email protected]>]
|
| But all I was meaning was that /for the purposes of the interview/
| the link to the JavaDocs should be provided. Googling for sample
| code would be out.

it depends on how it is done and why. one of the first things I do
when trying to learn how some non-trivial API is used is to look for
implementations that make use of it. most of the time you can judge
by the overall appearance of the surrounding code if the author has a
clue or not, and even when the code is bad, you can learn something.

this is the programming equivalent of "use it in a sentence", and it
is something that most programmers routinely do as part of their
job. there is no point in trying to pretend it isn't so and there is
definitively no point in pretending that it isn't productive. it is.
it is *vital*.

why else do you think that O'Reilly publishes all these "Cookbooks".
I own a few of them, and I sometimes turn to them for ideas, but to be
honest, I can't remember having copied out code from any of them
directly.


what I would look at is how they evaluate the code they look at in
order to learn.

-Bjørn

 

[.]

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.

I agree with this. This is why I'm happy with vague answers and this is
only a small portion of the interview. I also try to put the candidate at
ease by letting them know that I'm a programmer and have been on the other
side of the interview process as well.

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.

One of the problems here is that some people will get someone else to give
them the answer. I actually had someone approach me (I went to school with
the guy; he never graduated) and offer me $500 if I'd answer a quiz for
him. His thinking was that he just need to get through the interview and
he could figure things out later.

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...

We pay more than this but we get bad candidates even without indicating
how much the position pays.

 

[David Alex Lamb]

Last time I was a student, in the early 1970's, when I only had a few
years experience, I assumed the professors knew best, and there was some
practical value to closed book testing. That value didn't show up in the
following 25 years as a programmer and architect.

Speaking as an educator, I think it's fair to say that closed-book tests are
often a way to make the grader's task easier -- one can ask a bunch of
easy-to-grade multiple choice or fill-in-the-blanks questions.

That doesn't seem quote fair to the OP in this case; I just meant to say what
happens a lot in academia.

 

[Patricia Shanahan]

Speaking as an educator, I think it's fair to say that closed-book tests are
often a way to make the grader's task easier -- one can ask a bunch of
easy-to-grade multiple choice or fill-in-the-blanks questions.

For my most recent batch of closed-book tests, that was definitely not
the case. None of them had more than a small multiple-choice component.
They were more about mathematical proofs, essays, diagrams of processor
pipeline states, and the like. All sorts of difficult-to-grade stuff.

Patricia

 

[.]

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

Even if we ignore the fact that exec() is not a static method, this
solution does not seem to work. I keep getting the message:

'uniq' is not recognized as an internal or external command,
operable program or batch file.

I guess the Windows operating system has a problem running commands that
don't exist on it.

 

[Stefan Ram]

For my most recent batch of closed-book tests, that was definitely not
the case. None of them had more than a small multiple-choice component.
They were more about mathematical proofs, essays, diagrams of processor
pipeline states, and the like. All sorts of difficult-to-grade stuff.

Not directly relating to the above quotation, but to the
thread in general:

"On an infinite, two-dimensional, rectangular lattice of
1-ohm resistors, what is the resistance between two nodes
that are a knight's move away?"

(Reportedly, an interview question of one of the large search
engine companies.)

 

[.]

[eglato <[email protected]>]

[snipped a number of detailed programming questions]

| 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 the article. It is a lot of common sense. I just realized that I
was assuming eglato asked more than programming questions. I ask
programming questions plus many of the things in the article. If eglato is
just asking programming questions then he is just looking for a code
monkey.

| 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.

My experience has been the programmers who cannot answer the simple
programming quiz also do not read books on their own time and do not see
anything wrong with badly written code (maintenance is a non-issue for
them; if it works but they don't know why that is good enough).

This has been my experience. It feels like 90% of the people applying for
programming jobs just want to make a lot of money and would just as soon
dig ditches if it paid as well.

 

[Phillip Lord]

Darrell> Even if we ignore the fact that exec() is not a static
Darrell> method, this solution does not seem to work. I keep getting
Darrell> the message:

Darrell> 'uniq' is not recognized as an internal or external
Darrell> command, operable program or batch file.

Darrell> I guess the Windows operating system has a problem running
Darrell> commands that don't exist on it.

I think that the OP is making the perfectly fair point that the
original question is heavily underspecified. The solution is a
perfectly reasonable one and does work. Just not in general.

Phil