Knowing Java is not knowing much. Knowing C is not knowing much. Same for Javascript ECMA 262. The same is true for many other languages. Not all of them, but many of them.
What am I talking about? Well, I am a little frustrated at the moment at the common industry practice of simply requesting expertise in a particular programming language - like Java or C++ - as if that knowledge had a whole lot of meaning. It doesn't, and it is often dangerous to read too much into language knowledge when searching for expertise.
What am I talking about? Well, most mainstream programming languages are split into three pieces: the core language, a finite set of bundled libraries and the potentially infinite set of third party libraries. Generally, when I need to find programming help, I work backwards through that list. For example, lets say I need Eclipse RCP talent. First and foremost I need people familiar with Eclipse RCP. This implies knowledge of a huge set of Eclipse APIs, which brings with it the need for SWT knowledge - itself a huge API. Oh, and somewhere down there in the bowels of all of that expertise, is the Java language itself.
Do you see what I'm getting at? A developer who "knows Java" but does not know Eclipse or SWT is not very close to meeting the need. Running an advertisement that asks for Java experience is not going to cut the mustard. It can take literally years to become comfortable with some of the big ticket Java APIs. The same goes for C++ APIs. The same goes for Javascript APIs.
To see this - starkly - in the case of Javascript, it is worth perusing ECMA 262 a formal expression of what it means to know Javascript. Not much there huh? What you really need (probably) is expertise in JQuery or YUI or XUL ...
I think part of the problem is that sometimes simply naming a language does carry with it, implications of knowledge of the surrounding libraries and application stack. Visual Basic is a good example. It goes without saying that a VB programmer is skilled in the arts of wielding the Microsoft Windows APIs. A Visual C++ programmer is almost guaranteed to have important skills that go way beyond the C++ language.
Bottom line, if in doubt, spell it out. If you really need someone to program in C++ against an Oracle back-end, spell out the Oracle bits. The C++ bit on its own probably will not get you what you want.
Oh, and finally. Don't underestimate the amount of time it can take to "pick up" a new library or application stack. I have heard hiring conversations that go like this "We need an SWT app. Joe has worked with Java before, so he can pick it up.". Danger. Danger. Joe can most likely pick it up for sure but it is highly unlikely to be a wet afternoon's work. Not by a long shot.
To paraphrase John Maynard Keynes: APIs can stay impenetrable longer than your schedule can stay acceptable.
Build your tech library with our book giveaways.
Hacking Exposed, Sixth Edition
By Stuart McClure, Joel Scambray, George Kurtz; Published by McGraw-Hill/Osborne
The original Hacking Exposed authors rejoin forces on this tenth anniversary edition to offer completely up-to-date coverage of today's most devastating hacks and how to prevent them. Using their proven methodology, the authors reveal how to locate and patch system vulnerabilities. The book includes new coverage of ISO images, wireless and RFID attacks, Web 2.0 vulnerabilities, anonymous hacking tools, Ubuntu, Windows Server 2008, mobile devices, and more. Enter now!
Agree, but that's seldom how business entities see it
We had this come up at work recently with a computational geometry solution I wrote in IronPython.Project Manager: OK, so we'll need a C# programmer to port this to our standard, C#.
Me: No, we need a computational geometry programmer to program this in C#.
Not sure why, but corporate IT and Human Resources tend to see things in terms of high level tools and languages, as opposed to specific disciplinary or subject matter expertise. I suspect it's because that approach is simpler and easier, although, IMO, seldom more effective.
My 2 cents.
A good programmer is always a good programmer.
Unfortunately, most programmers are no damn good. I've given the "FizzBuzz" challenge (Google it) and similar simple tests to interviewees for several years now. Most can't pass it, despite in some cases years of working with J2EE, biz rule engines, and other high-level APIs. When even pressed to produce pseudo-code logic that shows they can think, they can't do it. They literally cannot think.This is because requirements like yours, for just banging out straight-line code in high-level APIs, make it possible for morons who can't think or program to get jobs "programming".
Knowing the core language is just a trick, but it's a tool that's only heavily used by people who can think, and therefore makes an excellent test of whether they're just some API monkey or a good programmer.
Being able to discover and analyze an algorithm on the spot is worth far more than years of experience with of any specific API. A real programmer can learn any API in a few weeks. I've jumped from Swing to EJB to JSF to SWT to Spring & Hibernate to whatever I'm doing this week more times than I can count. It's nothing.