Only 32% of Java developers really know Java

prostoalex writes "Research firm Gartner draws attention to the fact that less than a third of people who put Java on their resume actually know their stuff. The knowledge gap between someone who can successfully write a System.out.println() and someone capable of designing and implementing a complex Java system brings to companies being back-logged with pending projects."

Comments

How shocking...

[davegaramond]

How shocking this news is to me, because it confirmed a survey report I just read yesterday: that 68,015% people lie in their resumes!

They all know Java

[davegaramond]

Actually, the report is wrong. They just don't read the resumes carefully. The other 68% actually know *Javanese* Java, not Sun Java.

Only 0% of editors proofread their articles.

[Anonymous Coward]

"The knowledge gap between someone who can successfully write a System.out.println() and someone capable of designing and implementing a complex Java system brings to companies being back-logged with pending projects."

We also would have accepted: Only 26% of submitters to Slashdot can create proper sentences.

Re:Only 0% of editors proofread their articles.

[saden1]

Was I the only one that got the feeling that they were trying to sell me OptimalJ? Although I agree with the lack of "skilled" Java develoeprs I really can't their numbers seriously as they are quite lacking in the credibility department.

Re:Only 0% of editors proofread their articles.

[mrlpz]

I agree, I have stopped taking the Gartner group seriously because too many of their reports in the past are highly skewed, and wreak of funding from some party interested in the "findings" leaning in their favor.

And as for the sales pitch, you could almost tell it was coming from the moment they brought up Compuware.

In other news...

[sepluv]

Researchers suggest that "less than a third of people who put something on their resume know anything about it". News at 11...

Also "99% of researchers and statisticians have no idea what they are talking about and don't know what research means"

Sad but true (in my case, at least)

[FricassedMonkey]

It really is sad.. I've been dealing with Java for years, and I know that I couldn't bring myself to bother messing with a 'complex' project... Of course, I'm not going to be putting 'Java' on my resume anytime soon, either...

Not at all suprised

[smari]

Java was the popular thing of it's time. If you didn't know it at the apogee of the internet bubble, you didn't get a job in the computer idustry; it's a lot easier to say that you know it, and hope that you never have to use it. I for one hope that I don't have to write Java code again...

Now things are pointing similarly towards C# and .NET - buzzwords rule the market from the big business' point of view.

However, those who really know their stuff normally stick to the older languages... hype is good in some ways, but in the grand scheme of things, it's the older, better stuff that will prevail.

Re:Not at all suprised

[pfraser]

hype is good in some ways, but in the grand scheme of things, it's the older, better stuff that will prevail.

Yes, just like MS-DOS has prevailed...

Re:Not at all suprised

[4of12]

those who really know their stuff

More than buzzword compliant resumes, I've been more interested in people who could show me nice looking code and explain it intelligently to an audience that includes people with varying levels of expertise.

I figure that anyone sharp enough to have picked up one language and set of libraries and used it well can just as well do it again.

That said, I can see the temptation to use stupid HR tactics to try to screen out smokeblowers. Problem is that it's difficult to devise a system that simple, where a non-expert in HR can turn a crank and cull the dolts from the field with perfect accuracy (it's like defending against spam). You're likely to let posers through the gates (false positives) and cull out an occassional gem that looks unpolished (false negative).

There's a good reason people resort to informal social networks for recruiting (that is, asking around if anyone knows anyone that's good and looking for a new position) - it's because the crank turning procedures are so unsatisfying.

Re:Not at all suprised

[AJWM]

I figure that anyone sharp enough to have picked up one language and set of libraries and used it well can just as well do it again.

Close but not quite. You're as likely to find that they end up using whatever new language you throw at them as if it were some weird dialect of the only one they know well.

My rule of thumb if I'm looking for someone that needs to be able to pick up a new language is to find someone that knows at least three different ones (and I wouldn't count C++, Java and C# as three -- one and a half, maybe), or two if they're different enough.

My first two computer languages were Algol and APL, I've since been paid to write programs in about a dozen other languages and written toy programs in another ten or so. Heck, except for short term contract jobs, I've often ended up developing software in some language other than the one I was originally hired for.

It's tough being on the hiring end too -- if I've got project deadlines looming and I'm given a foot-high stack of resumes to look through to pick out a few candidates to interview, I'm sorry but my first pass through the stack is to going to be to find any reason at all to not look at a given resume any further, so I can shrink the pile that I actually have to read and think about. I may end up throwing out a gem but as long as there's still one left in the pile I look at, that doesn't matter. (Well, not to me, I know it matters to the one I threw out.)

Yeah, the whole resume/HR/interview process sucks, and it's one of the least efficient ways to find a job (or a good candidate), but alas most tech types are even worse at social networking, at least with the kind of people one needs to to get the job.

Re:Not at all suprised

[AJWM]

I've seen some people do a skills matrix -- list each language (or other computer related skill, like system administration or particular packages) and give a level of experience for each, sometimes also with a "last used" date.

I used to categorize them in groups, something like:
Highly skilled in: C, C++, Java
Experience in: Python, PL/SQL
Some exposure to: Ruby, Coral 66, BF

If I'd just done a couple of classes, it'd be in the "some exposure to" category. Anything less I wouldn't bother mentioning. (Hey, I've done the equivalent of "hello world" in a lot of obscure languages, and (like a lot of programmers) I can read more than I can write code in.)

These days I have enough trouble cramming my resume into just three pages, so I don't bother listing anything I'm not prepared (by both knowledge and inclination) to immediately sit down and start coding in. If there's some other language that might also be relevant to the job, I'll mention it in the cover letter. And there's stuff I leave out -- I've been an APL resident expert, even taught courses in it, but I don't mention it on my resume because (a) I'm very rusty and (b) I have no particular desire to do develop in APL again (and I guess (c), there's no demand for it). Now, if someone were looking to convert an APL application to Java, say, I might be interested.

(And on one job, despite never having claimed any knowledge of COBOL and even actively denying any knowledge of it, the boss stuck me with extending a COBOL application, over my protests, saying "it's easy, you'll pick it up". (Fortunately I managed to put it right back down again after that project ;-)

Well, I'm relieved...

[Green Light]

I see that I'm not the only one!

It's True.

[dmorin]

I am the first line interviewer at my company. I ask Java programming questions that I consider easy (like tricking people into trying to store a primitive in a collections object, or knowing how to determine if a bit is set). Sad to say most people fail. Some fail spectacularly.

For the record I do NOT ask those boring certification style questions that you'd only know the answer to by memorizing the spec. All the questions we ask start with "here's a problem, now solve it with real Java code, please." If I've learned one thing, it's if somebody groans and complains that writing code is so trivial you shouldn't even ask it, then sit there and force them to write code because chances are they can't.

Re:It's True.

[GypC]

The real skill is recognizing and choosing the best ways to solve problems with a computer in a given paradigm (OO, Functional, etc). Languages are easy to pick up, and almost all programmers (except maybe C) have a manual on their desk.

Memorizing the nitpicky details or anything more than basic syntax is worthless. I'm sure Dr. Knuth would fail your little test. He wouldn't bother memorizing stuff that is easy to look up.

I managed to get a job doing BASIC programming with little knowledge of BASIC. I knew C, C++, PASCAL, Perl, Python, and sh. It took me maybe 2-3 days to become comfortable with BASIC. Now I'm one of the best programmers they've ever had, and I'm cleaning up a lot of their old crap code written by people who sure knew BASIC, but couldn't design a readable program to save their own lives. I'm talking GOTOs every other line.

Every good programmer with a background in OO languages worth hiring would be able to pick up Java in a very short time. You're probably weeding out a lot of real talent.

Now go back to pretending you're a real programmer and getting your jollies mocking people who can't write a bunch of Java code off the tops of their heads without a manual to look at, yet dare to apply for a developer postition!

Re:It's True.

[Jmstuckman]

Now, I'm assuming that the original poster was giving this test to people who put Java on their resume. (Otherwise, why bother?) The first example he gave (testing a bit) could be done with simple boolean operators that are the same in many other languages. (there might be a better way but this is one...) The second problem (boxing/unboxing) is something that any Java developer with experience should be able to do in their sleep, because it is a VERY common operation.

If I'm appling for a C++ development job and I put C++ on my resume, isn't it fair to ask me to, say, write a simple class definition without looking up the syntax? If I can't do it, then I must not have programmed in the language much at all, and I have no business putting C++ on my resume. In theory, the resume's supposed to be for languages you know, not languages that you could learn.

Re:It's True.

[humblecoder]

I have been on both sides of the interviewing table, and in my experience, the best technical interviews are language-agnostic, regardless of what language is used in your shop. All of the questions that I ask start with "here's a programming problem, now solve it in whatever language you want". I am more interested in seeing a person's thought process as they go through the steps of solving the problem than their syntactic recall for a particular language.

My rationale is that a software developer who has excellent problem solving skills can transfer their skills to any language. However, someone who knows the syntax and tricks of a language cold may or may not be a good problem solver.

The only exception to this is that if I want someone with OO skills, I will ask language-agnostic questions about OO design and development concepts (ex: define polymorphism, state why it is useful, and give an example of how it can be used).

Also, a question that "tricks people into trying to store a primitive in a collections object", doesn't seem like a very useful question. First, you are testing for knowledge of a Java syntactic quirk. Secondly, even if a person didn't know about this quirk right off the bat, any developer worth their salt certainly would figure it out the first time they tried to compile the progam.

In fairness, I do like the question about determining if a bit is set, although I wouldn't hold it against the person if they didn't have the Java bit operators memorized. As long as they understood the CONCEPT of bit manipulation, I'd be happy.

It's worse than this

[dhk42]

My real world experience tells me it is much less than 32%. 15% at best (though another 15% THINK they know java - this is where the real danger lies).

If you require knowledge of complex topics like sensible J2EE architecture or multi-threading it falls into the single digits.

The second half of the article recommends Model Driven Architecture for the masses as the solution. This amounts to putting complex tools into the hands of idiots. Tools that go out of their way to keep people ignorant, while simultaneously giving them the power to commit their sins on a grand scale. Brilliant.

dhk

32% are any good?

[bluGill]

Knowing Java is very different from knowing programming. If you can't do a complex project in Java you can't do a complex project in any language. If you can do it in any language, you can do it in Java. The first step might be learning Java, but any good programmer can handle that in a short time. Now granted I'd want someone who knows all the tricks on the team so I don't re-implement the wheel, but a complex project by definition requires many people so that isn't an issue.

HR is far too hung up on what you have already done, not realizing that the data structures and algorithms are what counts, and they are the same in any language.

Re:32% are any good?

[peterdaly]

I agree with your statements if a distinction is added between procedural and object oriented languages.

I have seen too many "old school" developers who havn't the foggiest idea about OO who think they can code in Java because they know the syntax.

All languages are not equal.

Re:32% are any good?

[Haeleth]

I am a C coder by trade... I like functional programming because its what I do 5 days a week eight hours a day

Um, if you're a C coder, then you are not doing functional programming, you are doing procedural programming. Functional programming means languages like Lisp, ML, and Haskell.

Code-completion interviewer

[Latent Heat]

I am of the mind that asking technical questions are fair interview questions -- I mean what are you supposed to ask in an interview for a technical job?

On the other hand, most of us mortals don't store all the details of API's in our heads. Back in the Stone Age we used manuals and in the Information Age we use the SUN Web site. If your interview objective is to see how someone would get the information to solve the problem, that is fine, but if your objective is to see if that person already has some narrow set of information, you are going to exclude some capable people.

I am mainly a Delphi developer (I should say a Delphi component developer), and my Java experience is only 4 months old, and gee, my Java experience is limited to using JNI to allow a Delphi ActiveX component to invoke an extension module written in Java and using a class loader so that extension module can be reloaded while the ActiveX component is still running.

I don't know the answer to your question about Java collection objects without looking it up, although I have enough sense to know that you have to use Object wrappers for value types in collections and then have to cast those objects back to their original types when you pull Object references out of collections -- I know that from "wasting" time reading Slashdot.

I guess I would fail your interview.

This article is just an advertisement...

[tcopeland]

...for Compuware's software. For example, from the article:

"Highly skilled and experienced Java developers are quick to recognise the value of MDA..."

where "MDA" is Compuware's acronym for "buy our software and generate all your code". And since "highly skilled developers recognise the value", anyone who doesn't "recognise the value" and buy their product is an unskilled dolt.

Resume

[illuminatedwax]

This brings up the point:
What do you have to know to put a computer language on your resume? Let's say that I put "Java" on my list. Am I expected to, say, know all of the built-in functions for a vector, or string, during my interview? If I put Python down on my resume, am I expected to know the names of built-in function overloaders for classes or the functions and parameters for the re module?

Basically what I'm asking is, if I put a computer language down on my resume, should I be expected to code something at an interview immediately without looking at any references? This doesn't seem unreasonable, if the program were simple, but I could imagine employers asking for more complex things. How complex is too complex and how much specific information should a computer programmer retain about a certain language, say, after not using it for 3 years (he was doing VBScript just until he could pay off his debt, I swear)?

I think it's more important to know "how to program" rather than "how to program in X" because the skills you learn in one language are usually easily transferrable to another, as long as you have lots of experience in different kinds of languages: functional, procedural, OO, assembly language, etc.

As a side-note, it looks in the article like by saying that 68% of employees don't understand Java, he really means that 68% of employees have never heard of MDA and have no idea what the hell it is, or don't quickly "recognise the value of MDA," since, of course, all highly-skilled Java programmers do.

--Stephen

Re:Resume

[metamatic]

I've been writing code for (thinks) over 20 years now, and whatever the language I always need to make extensive reference to documentation for simple things like names of API calls and order of arguments. For instance, in spite of writing C for over 20 years, I still need to refer to the man pages to check the parameters for fopen. Any employer who expected me to write code at an interview and get the syntax correct would be in for a big disappointment.

So I have a big problem with syntax. That's why I like Scheme and hate C++. To me, syntax seems like a silly arbitrary distraction. I wish more languages took the Smalltalk approach to function arguments, too.

I'd have no problem with questions about architecture, abstraction, the development process and design trade-offs though.

Whooha! Gartner is right this time!

[KamuSan]

This is exactly my experience. I've been developing in Java for about 8 years and I think I met just 10 other people who really know their Java. And of those 10 people just about 2 or 3 are able to design an enterprise class application.

It's not just Java developers, in the booming years a lot of people were hired by IT consulting firms here (NL) that shouldn't be near any computer at all. I've seen system engineers who studied politicology and got an MCSE who don't know the most basic thing about Windows and are not able to solve any problem at all. I've met tens of 'project managers' who don't know anything about IT and even less about software development and are too stubborn to listen to people who do know their shit.

The worst of all are VB 'programmers' who are just able to point and click a basic application, but don't have any feeling for what a programmer should be able to do.

The worst is title inflation. Every donkey is a 'software engineer' these days, and if you are able to actually design a piece of software you should call yourself 'architect', otherwise people won't take you seriously.
Because 'programmers' are seen as monkeys that type and are doing a trick that every other monkey can do. :-(

there is technology underneath it all

[hak1du]

buzzwords rule the market from the big business' point of view.

Java did represent an important step for industry beyond C++: it was the first widely accepted language with runtime safety, garbage collection, and reflection. Those aren't just buzzwords, they make a real difference.

On the other hand, Java has failed to keep up: Sun's irrational insistence on insulating programmers from the underlying platform, their intellectual property claims and licensing strategy over Java, and their failure to evolve the language mean that Java has remained a poor choice for many applications.

C# improves over Java in several of these areas: it is "just" a language (Microsoft actually doesn't seem to want you to use third party .NET implementations they don't control), it is an open standard, it has excellent facilities for interfacing efficiently with native code, and it addresses some serious limitations of the Java language. This is progress. However, even C# is still years behind the state of the art in programming language technologies.

However, those who really know their stuff normally stick to the older languages... hype is good in some ways, but in the grand scheme of things, it's the older, better stuff that will prevail.

You mean, older languages like Lisp, Modula-3, CLU, Smalltalk-80, Algol-68, Prolog, and Scheme?

Or do you mean older languages like Visual Basic, C, and Fortran?

There are good, well-designed older languages, and there are poorly designed older languages. Many people seem to stick with poorly designed older languages out of habit and because they don't know any better.

If you are referring to C and C++, they are, in fact, relative newcomers as far as languages go, and they represent a significant step back over the languages that preceded them. And both C and C++ were enormously overhyped at their time.

Troll? You must be joking...

[Graelin]

Java is a very strict OO language. You cannot get anything done in Java without a myrid of class extensions and "implementations." This has the great benefit of allowing lots of developers to work on very specific parts of a project and not run into eachother very often. This has the very negative effect of discouraging creativity in the individual programmers work since so much is set in stone.

Most Java programmers end up as class monkeys, taking very specific directions from a select few who determined the entire arcitecture of the system. This is not programming as an art. This is monkey work. Put them in a position where they need to use Java (or any language) to solve a real problem and they will fail.

Java has had the misfortune of a gigantic hype machine pushing it. Because it could not live up to the hype in some areas a lot of people have dismissed it. This is probably less Java's fault and more the fault of those who consider it "dead." For they should look at the language and realize where it's strengths are.

Java in the browser - DOA. It sucked. Still sucks. And nobody uses it anymore (or nobody SHOULD...)

Java as an App - So it turns out that the whole "corss-platform" thing was a joke. Multiple JVMs across multiple OSes made for far too many variables. Write-once, run-anywhere it most certainly is not. And these days you have multiple GUI implementations and their VM/OS-specific quirks.

Java on the Server - Ok, this has a future. Cross platform doesn't matter. Speed isn't an issue nearly as much. And there are a slew of components already available (J2EE) that do the hard part for you. ...Yes, that was two rants in one. It's twofor day here on /.

Was this an article...

[azuroff]

... or an advertisement for OptimalJ?

This has resulted in a tremendous backlog of projects," says Aad Van Schetsen, Compuware sales director for application development and integration solutions in the Europe, Middle East, Africa region.

Ben van Niekerk, Compuware SA product manager, says locally the backlog is mainly in projects to integrate new applications into Java legacy code.

Van Schetsen says the key to the success of tools such as Compuware's OptimalJ is their use of a model-driven architecture

Tools like OptimalJ ensure best practices and standards as well as enable companies to leverage the core capabilities of their developers by allowing them to focus on applications and not the underlying technologies.

"Although we are still in the education phase, particularly with less experienced Java developers and development companies, momentum is gradually growing with OptimalJ sales increasing threefold in the past financial year."

Re:Imagine the statistics for C++

[Screaming Lunatic]

The studies I'm familiar with showed that it took 5 years to become competent in C++, and that was before they added STL. So I suspect the statistics for the number of alleged C++ programmers who actually know the language would be even worse.

I have been programming with C++ for 6 years now and I am competent with it and very productive. I would say 5 years is an overshoot if you're trying to gauge competence.

I'm not sure what your definition of "knowing the language" is. If someone asked me to rate my C++ skills from 1 to 10, I would give myself a 4 or a 5. Anyone that rates themselves a 7 or higher is either named Sutter, Alexandrescu, Glassborow, or Stroustroup. Or is either grossly unfamiliar with the scope of C++ or flat out lying.

Their were people that thought they new the language cold until Alexandrescu wrote Modern C++ Design and turned the C++ on end.

I'm still trying to add policy-based design, template metaprogramming, and generics for more than just containers to my C++ arsenal.

Give me 6 more years and I'll "know the language cold" until someone else writes a book on how to exploit a language feature of C++ in an absolutely different way.

However, that is not a bad thing because C++ does not punish you for features that you don't know.

This is nothing new...

[tsvk]

As long as there are people putting "I know CHMOD and Upload/Download" on their resumes, I guess anything is possible....

Why just JAVA?

[vatsal]

#) Isn't this true for every langauage....

#) Building complex systems requires experience(on large projects and exp in a particular domain),no matter which language you are using....

#) One good way to identify someone's love for a langauge or platform is to check for his participation and contribution to FLOSS. that loves ensures his personal interest and can be a pointer to the fact S/he is inquizitive and likes exploring more (not just learning the basic sytax required to do the job).