Shortage of qualified Java programmers

[.]

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.

I think we are talking about different things. I wrongly assumed you had
other criteria for evaluating people. If all you are testing is the
ability to memorize the API docs then you actually are setting yourself up
for failure.

You might want to start off with a complex piece of code and ask them what
it does. If I see a piece of code I can give you the overall idea of what
it does. I cannot tell you if there are syntax error. For example, someone
wrote:

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

the reality is this does not compile. It should be:

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

but I would not hold that against a candidate. I look up the details so
why wouldn't I expect the candidate to do this as well. I tell them
straight out, if I want code examples, it does not have to have correct
syntax so long as they have the right idea.

Also, programming questions take maybe 5% of the interview time. More than
70% of the time is spent on things mentioned in an article someone
referred to (i.e. http://www.artima.com/wbc/interprog.html).

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 an incredibly poor attitude. Last company I worked at that was always
in panic mode, I found everyone felt demoralized and agreed this was not
the way to do things. A group of us formed a continuous improvement
program. We listened to everyone and what they felt the problems were
(they all pretty much knew what was wrong). We picked 3 items and fixed
them. Every quarter we picked the top 3 items and fixed them. The hardest
part was getting buy in from management. If you cannot get buy in from
management, start looking for a new job.

 

[Remon van Vliet]

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

It may have been said before, but perhaps you're simply quizing them on the
wrong things. I personally couldnt care less if they didnt know certain API
specifics, since in a working environment that information is a few clicks
away. I'd be much more interested to hear about how they'd solve certain
problems typical for what they'll run into at the company they'll work for.
"What are the methods of the Collection interface" somehow seems way less
interesting than "How would you go about indexing a large amount of emails
in such a way that the contents of those emails can be searched through a
search engine". And i'd be perfectly happy with a sound verbal explanation
as well. APIs and even languages can be learnt by good developers, whereas
insight and problem solving skills are harder to gain. My point being, i'd
focus on talent and insight more than raw knowledge.

My $0.02, good luck with the recruiting,

Remon van Vliet

 

[Paul Tomblin]

In a previous article, (e-mail address removed) (".") said:

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.

Don't whine to me because you chose an inferior platform. The original
problem statement didn't specify an OS, and so I assumed a moderately
capable one.

 

[.]

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.

How would this save them wasting their time? On online interview would
save YOU wasting your time. My company gives a multiple choice plus short
answer quiz. It is online. Actually, I just checked and it is totally
online. You have access to the internet. When I took the test it was
pretty simple stuff so I never checked to see if I had internet access.

Less stressful? I found the online quiz to be more stressful. When I'm
interviewing with a person and I feel stressed I can talk to the interview
and relieve my stress; I can get answers to those unknowns that are
creating the stress. An online quiz gives me no feedback so I find it far
more stressful.

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.

You are course adjust for the nervousness, right? If I had to do the quiz
now I could do it in 20 minutes. When I did it in the interview it took to
1 hour and 50 minutes.

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.

I know zero methods on Calendar. If you required me to write something
that required Calendar I could look up the APIs and figure it out. If it
turned into something I used on a regular basis then I would not need to
look them up again. Possible scenario: I can code twice as fast as you but
I never used Calendar before. You want X lines of code per week. The first
week I generate 0.3X lines of code. Second week I produce 1X lines of
code. Third week I produce 2X lines of code. The average for the three
weeks is 1.1X lines of code. I am exceeding your expectations. But you
never hired me because I'd never memorized the Calendar APIs.

N.B. I'd have a problem if you gauged me on number of lines of code but
it is the best example I can come up with on short noticed.

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.

When I programmed C I was incredibly proficient on the use of localtime,
gmtime, mktime and various fields of the tm structure. Not to mention
clock and time_t. But as I noted above, I would not have a clue about
Calendar in Java. When I programmed in C I was working on compilers,
assemblers, profilers and code analyzers. I had been programming C for
since 1986 (I pre-date ANSI C). I've only been programming Java since
1997. I am not a guru and therefore there are areas I don't know yet.

I remember one of my Math professors telling me a story about Pythagoreas.
Two scholars are out in a boat. One is a student of Pythagoreas and the
other is skeptical of Pythagoreas. Remember at this time irrational
numbers had not been discovered. The skeptical student points out that
using Pythagorean theorem to a triangle with sides 1 and 1 would give you
square_root(1*1 + 1*1) == square_root(2). He notes that there is no square
root of 2. The student of Pythagoreas believes this to be evidence that
Pythagoreas is wrong so throws the skeptic overboard and drowns him. The
moral, just because Pythagoreas didn't know everything (irrational
numbers) doesn't mean everything he knows is wrong.

No one has to die just because I don't know anything about the Calendar
class. Just because I don't know anything about Calendar class doesn't
mean I don't have something to offer your company.

 

[.]

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

I think you're a troll.

Note the smiley on the sentence. He is being sarcastic.

 

[.]

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

Good point. In the short answer section of my company's quiz the manager
reads your answers and gets clarification on anything that is not clear.
So the process is, ask a short answer. Indicate there is no right answer
and you must supply your reasoning. Input it into a form. Manager receives
an email and reads over the answer. Creates a set of questions based on
your answer.

 

[.]

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

This is the sort of answer I look for when I ask programming questions.

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.

Isn't that the case most times? Everytime I've had an interview and they
didn't like my answers/attitude it turns out I didn't want to work for
them anyways.

 

[.]

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've never gone through a recruiter. I find I can figure out what company
a recruiter is hiring for and apply directly to the company. Occasionally
I find I cannot but then I just apply to the recruiter.

I have heard that sometimes the ads from recruiters are really just a game
some employers play.

I left my last job because I didn't like the site I was at. I was actually
really sad but as a whole the company was great. I was talking to someone
in the US office and they said they could get me a position at the US
office. I was doubtful. They explained the game. Create a job description
that matches my resume exactly. Hire a recruiter to find someone. The
recruiter is almost guaranteed to fail (people will be either not be
qualified or they will be overqualified). The company has put forth an
'honest' effort to find a candidate in the US but failed. They can now get
me a VISA to work in the US.

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.

Woody Allen once said, "I'd never be a member of a club that would have me
as a member."

Closely related, I'd never work for a company that wasn't smart enough to
catch me in a lie.

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.

Yes. The purpose is to weed out the liars. Once it seems like they have
some general knowledge I switch to seeing how good they are.

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


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.

After reading a number of messages in this thread I get the feeling that
you expect them to know more than I expect them to know.

I've taught Java and reviewed a number of teaching texts on the subject.
BufferedReader and FileReader is in pretty much every book I looked at
(good and bad books). I'd expect Java programmers to know BufferedReader
exists and have a vague idea of what it does.

Only some texts have Calendar. This means that some Java programmers
(myself included) have not used Calendar.

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.

I've always thought this was stupid. Closed book tests on basic
programming occurs because faculty aren't creative enough to properly
evaluate students. When I taught I was very sympathetic to students'
complaints about closed book exams.

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

Hmm, earlier you wrote how people have to lie to get through a recruiter's
screening process. We don't use recruiters. It is more likely people who
know how to lie are going to get past your recruiter and the people who
are good programmers are going to write crappy resumes and not even get a
call from the recruiter.

A recruiter wants to find you a candidate but with the least amount of
effort. Maybe your recruiter thinks the first step is to toss all the
resumes that don't list all the must have requirements. The recruiter
might be throwing out the ideal candidate just because they don't write a
good resume.

 

[Bjorn Borud]

[[email protected] (".")]
|
| When I programmed C I was incredibly proficient on the use of localtime,
| gmtime, mktime and various fields of the tm structure.

ah, yes, those were the days. I never did get the hang of the tm_wday
field, though. or the tm_month field. the time of month is best
tip-toed around and never mentioed. I did love the tm_min field.
indeed, the various fields of the tm structure has brought me much
pleasure!

:*)

*ducks*

| I remember one of my Math professors telling me a story about Pythagoreas.
| Two scholars are out in a boat. One is a student of Pythagoreas and the
| other is skeptical of Pythagoreas. Remember at this time irrational
| numbers had not been discovered.

they had, but Pythagoras got really pissy if they popped up in
conversation so it didn't come up much in polite conversation. they
mostly talked about how to bling up their chariots, threw rocks at
empty wine-jars and made whooping-noises at female passers-by.

-Bjørn

 

[Bjorn Borud]

[[email protected] (".")]
|
| When I programmed C I was incredibly proficient on the use of localtime,
| gmtime, mktime and various fields of the tm structure.

ah, yes, those were the days. I never did get the hang of the tm_wday
field, though. or the tm_month field. the time of month is best
tip-toed around and never mentioed. I did love the tm_min field.
indeed, the various fields of the tm structure have brought me much
pleasure!

:*)

*ducks*

| I remember one of my Math professors telling me a story about Pythagoreas.
| Two scholars are out in a boat. One is a student of Pythagoreas and the
| other is skeptical of Pythagoreas. Remember at this time irrational
| numbers had not been discovered.

they had, but Pythagoras got really pissy if they popped up in
conversation so it didn't come up much in polite conversation. they
mostly talked about how to bling up their chariots, threw rocks at
empty wine-jars and made whooping-noises at female passers-by.

-Bjørn

 

[Stefan Ram]

Woody Allen once said, "I'd never be a member of a club that would have me
as a member."

quoting Grouch Marx

 

[Pete Barrett]

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

Sometimes it has to be. There's one particular server I have to
connect to and send XML via an HTTP request. If I assemble the
request, headers and body together, and then flush the stream, it
doesn't work (reading the response times out); if I write the headers,
then flush, then write the body, then flush, it works. Don't ask me
why - it's their server!

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.

Why not? It's healthier than sitting at a desk, and it gets you out in
the open air. I never heard of anyone (other than Edward II) having a
passion for digging ditches, but you never know till you try. <g>


Pete Barrett

 

[eglato]

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.

The Java questions are aimed at assessing programming ability only. The
other part of the process is an in-person interview that focuses on design
skills, OO, and J2EE. Usually I will give them a design problem like
"explain how one could use design pattern X to solve the following
problem".

In our experience candidates have at least as much trouble with those type
questions as the programming problems. They might be able to recite a
description of the Bridge pattern, for example, but are completely unable
to explain how it would be used to solve a particular hypothetical problem.

 

[Bjorn Borud]

[[email protected]]
|
| In our experience candidates have at least as much trouble with those type
| questions as the programming problems. They might be able to recite a
| description of the Bridge pattern, for example, but are completely unable
| to explain how it would be used to solve a particular hypothetical problem.

I am not the least surprised. there is a pattern here: you are
repeating the same type of mistake in that you end up measuring the
wrong thing. in this case you a) measure encyclopedic knowledge of
patterns and b) give them a problem to solve and severely constrain
the solution space before they even get to think about the problem.

if the candidate doesn't remember the pattern and is more comfortable
with a different solution of the problem than your pattern of choice,
she might be qualified for the position, but you'd be unable to
discover this.


-Bjørn

 

[Chris Uppal]

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.

Sure, and that's a perfectly reasonable thing for a "competent programmer" to
do in general, but not in a context where the only point to the exercise is to
investigate the programmer's familiarity with core APIs.

-- chris

 

[Daniel Dyer]

The Java questions are aimed at assessing programming ability only. The
other part of the process is an in-person interview that focuses on
design
skills, OO, and J2EE. Usually I will give them a design problem like
"explain how one could use design pattern X to solve the following
problem".

In our experience candidates have at least as much trouble with those
type
questions as the programming problems. They might be able to recite a
description of the Bridge pattern, for example, but are completely unable
to explain how it would be used to solve a particular hypothetical
problem.

Alternatively, you could try this guy's approach to interviewing:

http://news.bbc.co.uk/1/hi/scotland/4091636.stm

Dan.

 

[.]

In a previous article, (e-mail address removed) (".") said:

Don't whine to me because you chose an inferior platform. The original
problem statement didn't specify an OS, and so I assumed a moderately
capable one.

I prefer not to make assumptions. I would either get clarification or I
would give a solution that works without making any assumptions. This is
after all a Java newsgroup and Java does run on Windows.

 

[David Alex Lamb]

I prefer not to make assumptions. I would either get clarification or I
would give a solution that works without making any assumptions. This is
after all a Java newsgroup and Java does run on Windows.

While I agree with your sentiment, I think he may be reacting against some of
the people who post here assuming Windows is the only OS worth programming
for.

 

[nuklea]

quizzing job candidate on java syntax, language semantics, data
structure, or debugging code segment is valid. but to expect java
programmer to remember api to get a job is not a good way. most
developers now aday use ide that have code complete capability so
remember all class name and its method is not an effective approach. if
your company still force programmer to use vi or wordpad to code...you
are loosing out.
what i recommend is that you pull five subjects from couple of books
such as effective java book, etc. most experienced or well trained java
programmer would have read this kind of book and know what is good to
do and not to do. i see many senior or lead java developers who fail to
know why they need to override hashcode method when they overide the
equals method. until i give them a pointer to a website or a book then
they will quietly do it. for experienced developer, they will know this
kind of subtlety. you can only find qualify candidate by testing them
using this technique instead of asking them to solve five problems that
has only to do with remmebering the api.

 

[Chris Smith]

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

Not an interview question. Google sent out a bunch of "pseudo
applications" which included this and and a lot of other questions
(others include "write a haiku describing how to optimize search result
relevance" and similar stuff). It is really a thinly veiled
advertisement claiming that they are a fun place to work, which I hear
they probably are.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation