
What Programming Languages Do You Struggle To Hire For? - AdamJBall
http://www.codingcupboard.com/blog/2014/01/29/programming-skills-needed-uk-businesses-grow/
======
Sukotto
Speaking as someone who has done a _little_ hiring (i.e. authorized to hire
two more people for my team at BigCorp) the answer is "All of them".

I'm not being facetious, I seriously mean that.

The skilled people you want are a scarce resource in a world of high demand.
The recruiters shotgun anyone whose resume buzzword-matches at least 25% of
the job posting. It just sucks.

Imho, your best bet is to develop relationships with the sorts of people you
wish you could hire and offer them something interesting when you hear they're
considering a move.

~~~
mrweasel
We're currently trying to hire one or two people in Aalborg, Denmark. Getting
anyone with skills beyond C# or Java for a smallish company is next to
impossible. We're looking for Python and/or Javascript skills, preferably
working knowledge of Unix. We've gotten may one real application, it's strikes
me as a bit strange, I would have loved to have had open positions like ours
when I graduated.

An open position in bookkeeping or warehousing however will get us 300+
applications. Skilled software developer ( and yes you can be newly graduated
) will get us nothing.

So yes, I would agree with: "All of them", there aren't enough people to go
around currently.

~~~
k-mcgrady
>> "Skilled software developer ( and yes you can be newly graduated ) will get
us nothing"

Maybe that's the problem. I'm a freelancer but anytime I've thought about
applying for a full-time software developer position I get put off by words
like 'skilled', 'senior', and a list of technologies the person needs to know
that no single developer in the world knows.

I've been coding for about 8 years, professionally for 5 and I consider myself
a good programmer. But I don't know if I fit your definition of skilled or
someone else's definition of senior as those are both too subjective. It puts
me off applying mainly because I don't want to embarrass myself.

Edit: I think a good way to hire would be a short coding test a person can
take online BEFORE applying. If they pass they know they are skilled enough to
apply for the position, if not they don't get laughed out of the room.

~~~
humanrebar
For good companies, laundry lists of skills are more like wish lists than
requirements, especially with niche technologies. Use the job description to
figure out what general kind of developer they're looking for (low level?
database? UI? enterprise? team lead?) and apply if you're interested.

Regarding the idea in your edit, huge companies like Facebook and Google do
have coding puzzles and competitions. People who excel in those surely gain
confidence to apply to all sorts of job openings.

~~~
vonmoltke
> _For good companies, laundry lists of skills are more like wish lists than
> requirements, especially with niche technologies._

No, for good companies requirements will be actual requirements and as such be
fairly short, the rest if the list appearing as "bonus", "preferred", or other
flexible adjective.

I'm a former systems engineer who used to do requirements analysis, so I am a
little sensitive to misuse of the word "requirement". Job postings like you
describe drive me up the wall.

~~~
humanrebar
I can relate to that. But I'm willing to give companies a pass on a crappy job
posting if the position itself is interesting.

~~~
redblacktree
Especially since it was very likely written, or at least mangled, by HR staff.

------
kolektiv
Or, to put it another way, why are you so averse to investing in people/your
company that you're looking for the finished article on the job market, rather
than finding good people and helping them learn the specific skills you need?

~~~
delinka
Because we need a solution _now_ and can't take time to teach you anything.
Can you start last week?

/s

~~~
LarryMade2
You forgot the part about saving the company...

[http://www.youtube.com/watch?v=CfxTc7_1UVE](http://www.youtube.com/watch?v=CfxTc7_1UVE)

------
nevir
Don't hire someone for their knowledge in a specific language! (Unless you're
doing some very core work in that language)

Hire someone who knows the concepts behind most languages, and can easily
understand new ones.

~~~
mildtrepidation
I don't understand how people believe this is universally good advice. Perhaps
if your company is large enough that you can reasonably pay new employees for
weeks or months before they're actually productive, I can see this being
feasible. But that's not most companies.

Keep in mind that this also likely impacts the productivity of at least one of
your current employees, and if it doesn't, your newbie's language acquisition
is not going to happen as fast, and their ramp-up time on your projects is
going to be longer.

There's a big gray area between well-funded startup and well-established
business where an entirely unproductive employee can have a non-trivial impact
on your cash flow.

~~~
falcolas
No employee is going to be productive on a new codebase for weeks or months,
regardless of the languages they knew coming in. And they're still going to be
a drain on resources while coming up to speed with the code base, even if they
know the language.

The sooner you realize this, the sooner you'll understand what your real
hiring requirements are.

~~~
logfromblammo
I once eavesdropped on some HR people talking shop, and heard the unsupported
claim that thanks to employment laws in the US, new employees are rarely
profitable until their second year with the company, which is why it is
important to hide the company's warts from the new employees.

After that first year, it isn't quite so crucial to keep you happy. That
explains why you never get the raise you were expecting after the annual
reviews. You are now profitable, therefore paying you more would reduce
profits and make you a less valuable employee.

And so we must go job-hopping.

------
jasonlotito
We don't struggle to hire programmers for languages. The struggle is find
programmers who understand the concepts we need them to understand.

That, and Android developers.

~~~
lportion
Out of interest, what concepts are you talking about?

~~~
jasonlotito
Different things depending on what we are hiring for. It also depends on how
people present themselves. Algorithms, protocols, software design, data
structures.

Hell, there are times I'd be happy if people just understood the difference
between TCP and UDP, or knew how to make an HTTP request. I guess it would be
a lot easier if we were just looking for code monkeys to follow orders.

------
reuven
It's true that certain languages are particularly hot, and thus particularly
in demand. The three that come to mind right away are Ruby, Python, and
JavaScript, for which there seems to be unquenchable demand, even if the
absolute number of such jobs is dwarfed by Java and C#. I'm sure that there is
a shortage of good Erlang, Scala, and Clojure developers, as well.

But no matter what language you're looking to hire for, you're likely to come
up short. That's because you don't just want someone who can write code in
XYZ, but someone who can write amazing code, _and_ interact well with the
others in the company, _and_ be sensitive to business needs, _and_ communicate
well. That combination is rare, no matter how popular and new (or unpopular
and old) the language is.

Heck, everyone's favorite punching bag, Cobol, is still used in a huge number
of businesses. I've seen in a number of places that if you want to make lots
of money doing un-sexy work, you should become a Cobol specialist. Believe me,
the businesses who need Cobol developers don't really care that Ruby is the
new hotness; they've got billions of dollars invested in existing code that
needs to be maintained and improved.

~~~
lectrick
There's also lots of money to be made in pivoting/combining your career
learned lessons to date and applying them to a different area.

For example, you could take all that great knowledge about unit testing you
learned in the Ruby space, and jump into Cobol and in all likelihood you will
not only be able to share a new thing or two to some Cobol folks, you might
contribute to far better maintained Cobol code.

The new ideas tend to congregate to the language-du-jour.

Of course, most of the "new ideas" were done on Smalltalk and Lisp years ago,
but I digress.

~~~
humanrebar
For the most part that's true, but (for example) unit testing isn't as
important in Haskell as it is in Ruby (due to stricter typing rules). Even
something simple like mocking an interface requires a lot of boilerplate in C.

That being said, there are probably some things that can be pivoted. The value
is in having attempted them in pilot projects so that you already know what
works.

------
robotic
For most programmers its not the new language, its the custom libraries,
obscure frameworks, legacy code, or tooling that is going to be an issue for
them.

~~~
Pxtl
Exactly. I can get a guy up to speed with C# in a matter of hours. The problem
comes up when we've got to deal with issues in IIS, Entity Framework, ASP.Net
MVC, etc. etc.

Most commodity programming languages are simple. Either they feel kinda like
Javascript, or they feel kinda like Java. Obviously there are a few shops out
there doing elaborate stuff with Clojure and they have a higher bar, but
probably 95% of the work out there is being done with "typical statically-
typed VM-based language" or "typical dynamically-typed language".

~~~
matthewmacleod
I don't really agree. While you can certainly explain the basic syntax of a
language in a few hours (assuming a developer who is at least familiar with a
diversity of other languages,) it take a lot of time for most developers to
become skilled at writing efficient, idiomatic code on a new platform.

------
bliti
A lot of times it is the company's hiring process that is broken. I recently
did a phone interview for a company and it was an absolute disaster right from
the start. The interviewer started asking questions about specific Python
functions/methods without even asking me about previous work experience. He
was so adamant in trying to understand if I could program that he simply
forgot to ask about me. This turned me off instantly and I did not answer any
questions. I kept the interview short and politely declined through email for
any sub-sequent interviews.

Their product is APIs for the financial sector. I write APIs for a living, and
have done so for a while. Including APIs for the financial sector. I
understood their challenges, and the technology. But rather than try and get
to know about my experience a little bit first, he decided to test me on my
knowledge of some obscure explanation in the Python documentation.

In contrast, my current employer did the opposite. They got to know me a
little bit first and then asked me questions about programming. They brought
me in as a contractor for a short period of time and observed me work. Then
they did three more interviews including a technical one. Which was really
interesting to do because it revolved around the decisions made in the short
project I was given. The process was very smooth, and I have already shipped a
project for the company, and am in the process of shipping the second one. No
silly questions about coin flipping, no fizz buzz on a whiteboard. Just real
questions about my skills, and an opportunity to show them off on their own
environment. I wish more companies hired this way.

~~~
humanrebar
> They brought me in as a contractor for a short period of time and observed
> me work.

I'm glad that worked out for you, but for the time being, contract work is
much more complicated than it should be in the U.S. Expecting all future
employees to work through a contracting period while paying double payroll
taxes and sticker-prices for health insurance probably isn't reasonable.

But as an option for potential employees, that sounds great.

~~~
bliti
Yes, I agree. It is complicated, but ultimately worth it if you are able to
secure someone with my skill set/experience. It might not work for people
fresh out of college, but for those of us with years of experience the work
environment and insight into how management works is very important.

------
memracom
This is a fundamentally flawed way to hire. Once a developer has 7-10 years of
experience, they should be able to learn a new language in a couple of weeks.
If you need a Python developer then hire a Python or Ruby developer. If you
need a Java developer then hire someone with C# or C++ experience. And once a
developer has around 15 years experience, then their past languages don't
really matter any more. If they are good at what they do, then they can be
productive with new tools from day one. Sure they might be mostly doing code
review those first two weeks while they get up to speed, but an experienced
developer can provide valuable input to younger developers that provides value
to the employer.

Fact is that we really don't know how to build effective developer teams in
the long haul because we have been in an unusual time period where almost all
developers have only a few years of experience in their first language.

Times are changing.

------
logfromblammo
The answer to the question is "all of them," because it is the wrong question
to ask.

When you hire for experience instead of aptitude, it's like trying to
photograph Sasquatch with a macro lens.

I see company after company leaving postings open for months instead of just
hiring someone and giving him some books to read for two weeks. I thought that
was the point of brainteaser interviews--to find out how smart the interviewee
is, aside from specific experience.

It is very clear to me that the system for hiring skilled labor in software is
flawed at its foundations. There is plenty of supply out there. If you cannot
fill your demand, it is for one of two reasons: your requirements are too
narrow, or your offered amount is too low.

Is hiring someone fresh out of the diploma stamper and investing in a tiny bit
of training really that horrible from a management perpective?

------
rch
I'd like to come at it from the opposite direction, and help engineers build
out profiles of what they are looking for. Not another resume site, but a
forum for making anonymous declarations of what the the perfect job(s) would
look like. And something similar for potential employers. I probably wouldn't
even focus on making connections, but instead just provide scores and feedback
on availability, trends, regional factors, indirect costs, etc.

It seems like that sort of data would be worth something to new and
established businesses, who both have to sort through an increasingly crowded
forest of tools and technology.

~~~
humanrebar
Isn't this sort of what LinkedIn is for?

~~~
rch
I find linkedin to be relatively useless in this context. I need to be able to
supply scores and weights to the various things I'm looking for, and to
submitted job descriptions. I'd like to get at what candidates are looking
for, not just what they have done.

It makes sense to list Java and C# in a profile, but I'd give a bump to Python
and Haskell opportunities, personally (others might do the opposite).

Actual hiring is driven more by accomplishments anyway.

~~~
vonmoltke
What you are describing sounds more like OKCupid for engineering jobs.

~~~
rch
Maybe e-harmony, since it'd be double blind model-driven matching, but with
near real time feedback while one is refining a set of preference parameters.

------
eik3_de
> What Programming Skills Are Needed For UK Businesses To Grow?

[x] Being able to put up a survey and allow a visitor to receive notification
when results are available without faking input and pretending they're a
company

~~~
humanrebar
Yeah, I'm interested in the results, but not interested in junking up their
data in order to see them.

------
neverminder
Talking strictly about UK, but I'm pretty sure this applies to majority of
other countries as well. Recruiters are the firewall that surrounds absolute
majority of jobs and they won't let you through unless you follow their
bullshit protocols. They call you up and try to psyche you up with a position
in a modern company/startup which works with new technologies like Haskell,
Erlang, Scala, Clojure, etc. There's only one thing though, you have to pass
their online 2 hour IKM Java 6 test to be considered... Most of the recruiters
I've dealt with don't know the difference between Java and JavaScript. I think
this would be a good niche for a startup - providing a service that cuts off
the dead meat - incompetent recruiters.

------
inglor
JavaScript. So many bad developers, so few good ones. You get a lot of people
coming to interview.

~~~
logfromblammo
I just had an interview where the company passed because they wanted someone
with specific Javascript experience, and I had only useless unrelated
experience with Lisp, C++, Java, and C#. None of those could possibly help a
new hire be successful, when what they really need to know is the syntax of a
specific scripting language.

------
peterclary
I read the actual page as "Please tell us why you're prejudiced against hiring
Graduate Developers and give us your email address so we can name and shame
you/your company."

------
torbjorn
Does anyone know how in demand Perl skills are?

I am being asked to learn Perl by my employer and I am wondering how much real
value it will add to my CV down the line.

~~~
mooreds
what kind of Perl skills? sysadmin skills automating server tasks? web
framework skills like mason? something else?

------
pcvarmint
That they even focus on programming languages for candidates, seems misplaced.

When I tell people I am a software engineer, they inevitably ask me what
programming language I use. I use the right language for the job. In the past
5 years I've just happened to use C, C++, C#, Python, Perl, shell, AWK,
Fortran, m4, and several assembly languages. The language is just a way of
expressing something which needs to get done. If necessary, I could learn a
new language for a new job.

I'd rather hire a candidate who is able to find and use the right programming
language for a job, teaching themselves if necessary, than a candidate with
competencies in a given language.

It's always a matter of cost -- what is the quickest and most productive way,
now and in the future, to deliver what the customer needs? The costs factor in
the decision of which language to use.

The fixation with specific programming languages seems to be misplaced.

It also seems slightly insulting to say that if you haven't had prior
experience writing code in a specific language, then you are not a good
candidate for the job. Some of us can learn new languages quickly.

For example, I had over 20 years of C experience before I learned C++ on the
job through self-learning. I was not hired as a C++ expert, but for broader
experience. C++ just happened to be the best language for the project, so I
learned it, all the way to template metaprogramming. Before I left the
company, I was the goto person for C++ language questions, which is ego
boosting in a way, but is not where I wanted my career to go. I did not want
to become a language goto person where everyone sent their C++ template
compilation error messages. C++ is just a means to an end.

Even if the job requires competency in a specific language because it is the
best language for that job, or because there has already been a lot of code
invested in that language, a generalist who is able to learn a new language is
better than a specialist in one language.

The only time I'd want a specialist in a particular language would be if they
were working on a compiler or interpreter for that language, where expert
knowledge of the language, and not merely programming competence in the
language, is required.

The question should be: Are you hiring a translator competent in a specific
language, or are you hiring a problem-solver who can write in a variety of
languages and who can learn new ones appropriate for the problem at hand?

Most programming jobs are the latter.

------
tonydiv
GPU programmers who know CUDA

~~~
tomrod
You should get in touch with the Texas Advanced Computing Center at the
University of Texas. They have people teaching and learning CUDA/OpenCL in
large batches; and like any good academic program they want to ensure their
students are employed (and employable!). If you like, email me and I'll set up
an introduction.

------
kriro
Might want to change "Objective C" to "Objective C (because Apple told us we
couldn't)" /snarly_remark

