Shortage of qualified Java programmers

[Bjorn Borud]

[[email protected]]
|
| 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.

so you have hard data suggesting there is a correlation between having
encyclopedic memory for APIs and being a good developer? I'd like to
see that, because nothing in my experience suggests that it is so. in
fact, I can't even remember any hiring manager I've known to share
your belief, but then again: it could be that it has slipped my mind
-- after all, I don't have an encyclopedic memory for the habits of
hiring managers I've known.

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

for what you test, yes. the problem with your tests is that they are
almost entirely irrelevant.

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

wow, poor management *and* no ambition to fix it. do you volunteer
this information to your candidates?

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

at "90 mph", with people who were picked mostly for their memory and
who are under poor management with no ambition to correct the faults
that lead to code being written in a state of panic.

they should put big signs up at these nuclear power-plants:

"the systems controlling the the neutron flow in this reactor were
made by people who were in a state of panic. minimum safe distance
is X miles. have a nice day"

I'll be watching for that mushroom cloud on the horizon!

-Bjørn

 

[Wibble]

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

You're questions are reasonable. The unrealistic environment you
place on the interview is just stupid. Its interesting to know
if somebody can juggle dynamite but it wont tell you if they can
code either.

That being said... I interview alot of people and they're mostly idiots.
Giving them tools wont make them any smarter.

Let them look at the api. Alot of bad programmers can't even do that.
It doesn't matter if they google, or randomly generate code, as long
as they do it fast, reliably and on command. Write a unit test and
have them write code that passes it, in a realistic environment. If
they're going to use an IDE everyday, you care that they do it well, not
that they can code without it. Thats just a silly "real men" test.

Its generally impossible to filter all but the worst programmers during
a short interview. If you have the luxury, try before you buy.

Joel has some good stuff to say about interviews (and most other things)

http://www.joelonsoftware.com/articles/fog0000000073.html

He has 2 rules for what to look for in a candidate:

Smart, and
Gets Things Done.

 

[Wibble]

You're questions are reasonable. The unrealistic environment you
place on the interview is just stupid. Its interesting to know
if somebody can juggle dynamite but it wont tell you if they can
code either.

That being said... I interview alot of people and they're mostly idiots.
Giving them tools wont make them any smarter.

Let them look at the api. Alot of bad programmers can't even do that.
It doesn't matter if they google, or randomly generate code, as long
as they do it fast, reliably and on command. Write a unit test and
have them write code that passes it, in a realistic environment. If
they're going to use an IDE everyday, you care that they do it well, not
that they can code without it. Thats just a silly "real men" test.

Its generally impossible to filter all but the worst programmers during
a short interview. If you have the luxury, try before you buy.

Joel has some good stuff to say about interviews (and most other things)

http://www.joelonsoftware.com/articles/fog0000000073.html

He has 2 rules for what to look for in a candidate:

Smart, and
Gets Things Done.

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.

 

[Dale King]

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.

If that is what you want, then why are you testing for memorization of
the API which has no correlation with any of that?

If you want to test familiarity with the API then ask general,
open-ended questions about the API. People have given you examples, but
some other examples:

- You mentioned Comparator, you might ask them to explain the difference
between Comparable and Comparator.

- What is the difference between InputStream and Reader?

- What is the difference between a String and a StringBuffer?

- What is the difference between an Enumerator and an Iterator?

- What is the purpose of such-and-such class? When would you use it vs.
this alternative?

Those are the sorts of questions that will show you whether the
candidate has familiarity with the API, without focussing on
memorization of details.

I don't care if a candidate has the method names and parameters all
memorized, but he should have understandings of particular classes.

 

[eglato]

- You mentioned Comparator, you might ask them to explain the difference
between Comparable and Comparator.

- What is the difference between InputStream and Reader?

- What is the difference between a String and a StringBuffer?

- What is the difference between an Enumerator and an Iterator?

- What is the purpose of such-and-such class? When would you use it vs.
this alternative?

These are questions that tell me nothing about the candidate's ability to
*use* the classes in question. I prefer "problem" type questions as I
think they are better at separating the men from the boys. For instance in
your Enumeration/Iterator question I would prefer to ask them to write an
Enumeration that wraps an underlying Iterator ala Jakarta Commons
IteratorEnumeration.

Again, I am not expecting a perfect recollection of the API. If they get
some method or constant names wrong I will not penalize them. But if they
make really stupid mistakes it tells me they don't have a clue. For
instance, if they are writing a Comparator and they declare their compare
method as:

public boolean compare(Object a, Object b);

or

public int compare(Object a);

then I know for a fact that they have absolutely no clue what a Comparator
is.

 

[christopher]

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.

Amen to that. This is what happens when you make managers out of
technicians -- the Peter Principle in action.

If the OP's goal is to hire someone with encyclopedic knowledge and
instant recall under pressure, maybe he ahould try recruiting someone
with military academy training who has some field experience setting up
tactical information system while under enemy fire. If his goal is to
hire a competent problem solver, perhaps he should read up on a
little-known field called interview technique.

 

[Kevin McMurtrie]

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

Same problem where I work. "Why would you synchronize a constructor?"
is now a phone screen question. Yeah, many applicants really are
putting the synchronized keyword on constructors.

What's your environment for the test? I can see that questions 2 and 3
involve classes that could be infrequently used by certain types of
developers. It should be trivial to code with an IDE looking up
Javadocs/source but it I know many couldn't write proper source code for
that on paper. I use reference queues more often than comparators.

My opinion is that pounding out syntax-perfect code in emacs or a text
editor is obsolete by 15 years. 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. I ask about the
advantages/disadvantages to using some JFCs versus others, but not about
things like constructors and method names that an IDE would tell you
instantly.

 

[Chris Uppal]

For purposes of an
interview, however, I expect the candidate to have "internalized" the core
language and API.

On the whole -- and more, apparently, than most respondents in this thread -- I
agree with this.

But you do have to be careful -- very careful -- about what you consider to be
"core". For instance I would /never/ consider date manipulation to be a core
skill. I have never once needed to do anything complicated with dates in 20
years of programming, and the Java date manipulation stuff is so baroque that
I'd question the sanity of anyone who /had/ internalised it (lack of sanity
could, of course, be either the cause or the effect of working much with dates
in Java ;-)

Actually, I wouldn't even consider the IO stuff to be core -- not in the sense
that I'd expect someone to be able to remember the names of the various
classes. I can't remember the bloody things myself, so why should I expect
anyone else to be able to do so ? I /would/ expect them to know how to /use/
the classes without a crib -- e.g. to know how to use the value returned from
the array form of read(), or how the classes all fit together in a Decorator
pattern.

I also would expect a competent programmer to know /where/ to look to find the
necessary supplementary data. For the semi-core stuff, I'd expect the
programmer to be able to go directly to the information that he/she didn't
choose to keep in his/her head. Using Google would be a complete no-no.

So, what would I consider to be "core" ? The language, to a fairly high degree
of detail (incidentally my experience is that knowing the language details
correlates rather well with being a "good programmer" in general -- I make no
claims as to why this should be true). As to the class hierarchy, unless I
was looking for programmers with a specific background (Swing, networking,
whatever), I'd pretty much stop at Object and String. I would very definitely
expect the programmer to have internalised /some/ of the hierarchy, but
exactly /which/ parts is not something I could specify in advance. E.g. I,
personally, have internalised a lot of the reflective stuff, but I don't think
I could legitimately expect another programmer to have done so (though I would
expect them to know that it existed, what it was capable of, and where to look
to find the exact method names and signatures).

-- chris

 

[Alex Buell]

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

Java is *not* certified for this sort of work. Sun says so.

I think you're a troll.

 

[Gerbrand van Dieijen]

(e-mail address removed) schreef:

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

There are a lot of reimplement DAO systems, because people didn't want
to learn about EJB or JDO.
There are also (probably lots of) reimplemented database-systems,
because people thought access a filesystem directly is faster than using
a database. Of course a databasesystem does that too eventually.

I'd say you would want someone who can estime, that buying a (say) $500
component is cheaper than creating it yourself even it will cost you
just a day.

Letting the candidates send their own code by mail doesn't seem such a
bad idea. You have to trust them eventually. It will come out eventually
if some candidate sends code he has not created himself.
Considering that being fired for fraud is a lot less worse for your
career than having a job for a short time, I doubt lots of people do that.

 

[Bjorn Borud]

[Dale King <[email protected]>]
|
| - You mentioned Comparator, you might ask them to explain the
| difference between Comparable and Comparator.
|
| - What is the difference between InputStream and Reader?
|
| - What is the difference between a String and a StringBuffer?
|
| - What is the difference between an Enumerator and an Iterator?

this is a step in the right direction, but it still is a bit off. for
instance I am more interested in how the candidate *reasons* to find
out when to use Comparator and Comparable. the *difference* can
easily be understood from the documentation.

| - What is the purpose of such-and-such class? When would you use it
| vs. this alternative?
|
| Those are the sorts of questions that will show you whether the
| candidate has familiarity with the API, without focussing on
| memorization of details.

how long does it take a competent programmer to familiarize herself
with, say, the JDBC API? or DOM? actually for both, it is usually
more important to understand the underlying technology than the APIs
themselves.

| I don't care if a candidate has the method names and parameters all
| memorized, but he should have understandings of particular classes.

I am generally more interested in whether the candidate will *produce*
good code or not. one thing that represents good code is when much
thought has gone into the internal APIs of an application so that the
system retains a large degree of plasticity. it is surprisingly hard
to design something for maximum flexibility with regard to change and
refactoring without, at the same time, making the code tediously
layered and bulky.

if someone is able to structure a software system and design good
internal APIs, chances are, this person will have a good understanding
of what parts of the Java Canon to use and which parts to avoid.

-Bjørn

 

[Bjorn Borud]

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

if, by narrow-minded, you mean people who tend to pick the same
patterns and paradigms for solving the same problem, I am not sure I
agree. for instance, I abhor the "there is more than one way to do
it"-philosophy that some of the Perl-"gurus" are so proud of because
it tends to reduce the readability of the code. it encourages
inconsistency.

(note *how* the two preceding paragraphs on the surface may look like
an inconsistency in my argument, but that they are in fact consistent)

-Bjørn

 

[Bjorn Borud]

[Alex Buell <[email protected]>]
| On Mon, 13 Jun 2005, (e-mail address removed) wrote:
|
| > We make the software that controls insertion and extraction of
| > Cadmium control rods in nuclear reactors
|
| Java is *not* certified for this sort of work. Sun says so.
|
| I think you're a troll.

indeed. from the licence:

3.RESTRICTIONS. Software is confidential and copyrighted.
Title to Software and all associated intellectual property
rights is retained by Sun and/or its licensors. Unless
enforcement is prohibited by applicable law, you may not
modify, decompile, or reverse engineer Software. You
acknowledge that Licensed Software is not designed or
intended for use in the design, construction, operation or
maintenance of any nuclear facility. Sun Microsystems, Inc.
disclaims any express or implied warranty of fitness for
such uses. No right, title or interest in or to any
trademark, service mark, logo or trade name of Sun or its
licensors is granted under this Agreement. Additional
restrictions for developers and/or publishers licenses are
set forth in the Supplemental License Terms.

-Bjørn

 

[Chris Smith]

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.

I give them half an hour to answer five questions of the same general sort
as I posted.

Wow, that's six minutes per problem, in a job interview setting, often
using stuff like java.util.Calendar. To put it bluntly, you're never
going to find anyone. If you do, their performing well on your test is
not going to have ANY relationship whatsoever to their doing well in the
job. It would be like hiring someone for a Maths professorship because
they can add really large numbers in their head.

Patricia, one of the most competent developers you'll find, has already
said she'd turn you down and walk out of the interview. I'm now joining
her. I might be able to complete your test, but I'd quickly reach the
conclusion that I don't want to work for someone as clueless as you.

Incidentally, Chris Uppal's response is very good. If you're ready to
actually listen, then go read it. Your responses to date, though, have
left me wondering why you bothered to ask anything here.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Bjorn Borud]

[[email protected] (Stefan Ram)]
| >>We make the software that controls insertion and extraction of Cadmium
| >>control rods in nuclear reactors
| >Java is *not* certified for this sort of work. Sun says so.
| >I think you're a troll.
|
| The "" (interpret as an abbreviation for ";-)") is sometimes
| meant to mark

I interpreted more as a sort of "I know I'm in over my head"-winky,
but hey, that's me.

or ;-) or > or ^_^ or whatever you prefer. interpretation is
left as an exercise to the reader.

-Bjørn

 

[Chris Smith]

On the whole -- and more, apparently, than most respondents in this thread -- I
agree with this.

I agree as well, in the general case. I haven't had the opportunity to
say so, though, because the OP clearly has no idea what constitutes a
"core" language concept in that sense. I'm still trying to imagine what
would cause someone to think that java.util.Calendar is fundamentally
important.

(Unlike you, I have had the occasion to use those classes. Most
recently I was working on an application that generates plates of a
planispheric astrolabe as PDF to be printed onto transparancies and
assembled. Of course, the dates had to be marked out in months and
days, and I also added the option to convert between LAT and clock time,
which required accounting for daylight savings time offsets. I didn't
think it was too incredibly difficult, but I wouldn't have wanted to do
it without API docs.)

I also would expect a competent programmer to know /where/ to look to find the
necessary supplementary data. For the semi-core stuff, I'd expect the
programmer to be able to go directly to the information that he/she didn't
choose to keep in his/her head. Using Google would be a complete no-no.

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!

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[eglato]

Java is *not* certified for this sort of work. Sun says so.

I think you're a troll.

Joke, okay? I work at a telecom company.

 

[Stefan Ram]

Java is *not* certified for this sort of work. Sun says so.
I think you're a troll.

The "" (interpret as an abbreviation for ";-)") is sometimes
meant to mark

;-) Winky smiley. User just made a flirtatious and/or
sarcastic remark. More of a "don't hit me for what I just
said" smiley.

http://members.aol.com/bearpage/smileys.htm

This might hint to not take this assertion serious.

 

[Alex Buell]

indeed. from the licence:

3.RESTRICTIONS. Software is confidential and copyrighted.
Title to Software and all associated intellectual property
rights is retained by Sun and/or its licensors. Unless
enforcement is prohibited by applicable law, you may not
modify, decompile, or reverse engineer Software. You
acknowledge that Licensed Software is not designed or
intended for use in the design, construction, operation or
maintenance of any nuclear facility. Sun Microsystems, Inc.
disclaims any express or implied warranty of fitness for
such uses. No right, title or interest in or to any
trademark, service mark, logo or trade name of Sun or its
licensors is granted under this Agreement. Additional
restrictions for developers and/or publishers licenses are
set forth in the Supplemental License Terms.

Yep.

 

[Alex Buell]

Joke, okay? I work at a telecom company.

OK, I'll bite. What is it that you really use Java for?