What's the deal with programming languages as strict job requirements? [closed]

Question

I went to a "job fair" recently and I was surprised to see how much emphasis workplaces seem to put on the programming languages candidates are familiar with.

From my (admittedly limited) experience, while truly mastering a programming language may take years, learning it to a reasonable level is a fairly simple affair to someone who already has experience with other languages, and can definitely fit within the timeframe employers usually allocate for the initial ramp-up.

I'd think an employer would care more about how many languages / paradigms I am familiar with, or what's my algorithmic / software design experience, as opposed to the specific technology I'm skilled with at the moment.

Say I already know Java, C++, Smalltalk and Prolog... should a workplace that relies on Objective-C really consider me unqualified because I lack experience in that language? Is this a flaw in recruiting methodologies, and if it is, what can I do to convince that workplace that my lack of experience with Objective-C should not matter? I'm asking hypothetically, not specifically about the mentioned programming languages.

Alternatively, my experience is limited and I admit I may be missing something. Is previous experience with a programming language more crucial than what I think it is? Does it make a difference if it's a junior or senior position? Should it make s difference?

Answer 1

Contrary to the press releases, it's an employer's market right now.

That means they can simply be picky about what their requirements are. It means they can demand .NET 4.0 experience, and not just 3.5 experience... It means they can demand experience with Django, and not just Pylons, etc...

Sure, you could learn all you need to know about Ruby in a couple of weeks, and Rails might take a couple of months (just guessing) to become proficient with...

But the employer can pick through resumes of people already proficient with Ruby & Rails.

TL;DR: Econ 101... Don't believe the hype about the shortage of programmers.

Answer 2

The main issue is that nobody really knows how to hire good programmers. The secondary issue is that programming jobs attract lots of applicants.

Given a large pile of resumes, it would be very nice to be able to comb through them and pick out the good programmers, but nobody knows how to do that. The way most companies work, the initial sort is typically by HR. The HR person knows nothing of Smalltalk or C++, except as listed on the requirements list, unlike a software person who might think "C++ AND Smalltalk - this guy will have no problems with Objective-C".

Even when the stack goes to the hiring manager, it's very likely much too thick to interview everybody, so the hiring manager has to throw out resumes for some reason or another. If it's a C++ job, and there are more people with 5+ years of C++ than the manager finds practical to interview, the manager may well toss all the resumes that don't have C++ on them. It isn't the way to get the absolute best people, but nobody knows how to hire the absolute best people, and if you're limited in decision-making by what's on the resume, the people with C++ experience are at least slightly better bets.

Answer 3

Let's turn it around - if you knew objective C, would you be any use as a C++ programmer? I'd say, no you would not, the languages are too different. For even simple languages like C, I would want to see 6 months experience before I hired someone, for C++ several years.

Some years ago, I taught myself PHP. I'd say it was several months before I got any good at it, could find my way around the library, understood common idioms etc. And I knew a lot of languages already.

Answer 4

It's dependent on various aspects of context. Not just the level of the role, but also the state of the project and company.

At the simplest level, any curly brace imperative language is pretty much the same as any other.

If you can code in imperative, you can code in imperative. Be it Java, C#, C, C++, or even javascript. Given a decent reference book (and possibly a bit of boilerplate), you should be able to knock out a small program in any of the others in an afternoon.

Whatever your history, you know about loops branches and functions, and the syntax is pretty much the same for all of them. If your history is OO you also know about objects, classes and interfaces.

However, I've seen too many imperative-only programmers struggle to write simple programs in declarative or functional languages. If I ran an Erlang shop, I'd strongly prefer someone with Erlang, or at least Prolog, experience over someone with C++.

---

How it depends on the level of the role:

Recruiting for a junior role:

If I were choosing a programmer for a C++ job, there are certain pitfalls that I'd want to be pretty certain the candidate is capable of avoiding, like the need to pay attention to memory or the lengths of arrays, simply so that they don't shoot themselves (and me) in the foot. If they've never done C or C++, then I'd have to work that out in the interview.

And for a senior role:

One of the keys to programming efficiently is knowing what you shouldn't write yourself. The key to that, is the standard (and de-facto standard) libraries. The key to that, is experience. You can't just sit down with "Teach yourself Java" for a week, and instantly turn yourself from a 10 year C++ programmer into a 10 year Java programmer.

---

How it depends on the state of the project/company

Given a Java project that is pretty much a clean slate. I'd want a new senior hire to have a lot of knowledge about the Java ecosystem, and be able to advise on the different available technologies.

Given a mature Java project, I'd happily consider an experienced C++ developer, with little or no Java experience for a senior Java role. Most of the ecosystem decisions will have already been settled, and the new hire will be able to gain experience with the Java libraries whilst the company leverages the programmer's experience in OO software development.

Answer 5

It depends on the workplace. If they are very busy, they might not have time to wait for you to catch up to a point where you can function in Objective-C - they might want someone who can hit the ground running.

Some workplaces might be willing to take a risk on you if they see you are familiar with other languages, as well as having strong fundamentals, and knowledge of the business domain. That will really depend on how open they are, and how good you are at convincing the recruiter to take that risk.

Answer 6

Hiring is hard; hiring good people is even harder. I've done hiring where I was faced with a stack of over 500 resumes. Of cousre we filtered out the people with the least experience in what we wanted to get the stack down to a reasonable size. Is that fair to the excellent candidate who doesn't happen to know that language, probably not. But if I can find 100 people who do have the qualifications I'm looking for, I'm really not going to spend a lot of time on the 400 who didn't - no matter how good they are.

Now in hiring, I may have long list of requirements but usually only one or two are deal breakers. And if you don't find anyone with the initial list of qualifications that you want to interview (or later if they all fail the interview which I have seen happen), then usually they will go back and look at the people who are missing some of the less critical qualifications or people who have something simliar but not the same. In those cases you are often looking for something about the person's experience that will make them better for your job than someone with all the technical qualifications. For instance, I would consider a data analyst with experience in a different enterprise database if she had experience in my business domain (in fact that person would probably make my first cut if I saw all the resumes). Same thing with something like C# and Java. If the person is doing work of a similar level of complexity and especially in a similar business domain, they might be a very good candidate even if they have the other language.

However, unless I had a fairly formal training program for entry level people, I would be less likely to hire from the people who didn't meet my minimum skill set of languages. And almost never from a group who had none of the things I was looing for. People with no experience have less to bring to the table in terms of some offsetting qualification and less of a track record to prove they can do professional level work in any language. They have enough to learn with their first professional gig without some understanding of the most important language we use. And hiring them is more of a risk that it may be months before you can get useful work from them.

A further point comes into play if the hiring official is moving the team into a new technology. If no one on the team is truly expert in the technology and I have to hire someone new as well, I'm going to look hire someone with as much expertise I can find in that technology because they have an idea where the "land mines" to avoid are.

Finally, apply for the jobs you are interested in even if you don't meet all the stated requirements (but do try to meet some, hiring officals don't like to waste their time on people who would never be hired). You never know what competition you are going to have for a job or what will most impress the people screening the resumes or doing the interviews. What might get you an interview at company A might be exactly what prevents you from getting the interview at company B even if they have simliar requirements on paper. Further, they might have a job that better meets your qualifications that they haven't advertised yet. But you will never get considered for the job if they don't know about you.

Answer 7

While I think the OP is dead on about how a programmer who is experienced with many paradigms can easily add one more, it all comes down to the employer's aversion to risk. A potential hire who is not familiar with their tools is a wild card; they could be really great, but they could also be a flop, and it will be harder than normal for the interviewer to tell the difference if they cannot ask in depth questions about the technologies they use.

I am definitely not saying this is the correct way to look at this, but it is how some employers do. The smart ones exploit this and scoop up the awesome programmers with 30 years of experience in C++, while the stupid ones turn them down because they lack the required 15 years of Ruby on Rails experience. Programmers can exploit this as well though, by avoiding employment with employers who are so ill-informed. After all, who wants to work for a place that systematically makes bad hiring decisions?

Answer 8

Should it? No. Does it? Yes, sadly. This is the "purple squirrel" syndrome: The company wants to have their cake and eat it too, and get a candidate that can do everything under the sun they need or may need. Often, but not always this is because they either A) Have no clue what development really entails and just assume somebody meeting all of their criteria can do the job, B) They are being picky because they can get away with it, or C) They plan on filing an H-1B/Green Card/Promote from within but have to make it look like they are advertising a real job.

Answer 9

"Say I already know Java, C++, Smalltalk and Prolog... should a workplace that relies on Objective-C really consider me unqualified because I lack experience in that language?"

If you have 20+ years experience in 3 or 4 languages that have similar features to Objective-C then I would probably hire you to do Objective-C and expect you to be productive in 6 - 8 weeks. ( this is based on my personal experience with learning Objective-C a few years ago ).

If you are green right out of school with no real tangible practical experience in any thing, then you probably won't get hired to do something you are completely un-familiar with.

Objective-C is an interesting straw man here. It requires you know C very well, it requires you know Object Oriented Analysis and Design very well, it in most cases requires you to know C++ to an non-trivial extent because there are C++ libraries that you will probably want to interface with.

It requires you to understand manual memory management as well as how automatic memory management/garbage collection works and when to use each technique in the same program.

It isn't just Objective-C you need to know Cocoa and POSIX as well, because face it Objective-C is for all practical purposes useless outside the Apple environments and you have to know Cocoa then as well.

And when Cocoa fails you, you need to be able to know which POSIX APIs to use when you can't do what you want with the Cocoa wrappers.

It also implies that you should know Unix to some non-trivial extent as well.

Answer 10

Depends on the language/individual.

If I'm a C# place and someone with JAVA/J2EE experience applies, I'll give'm a shot. The syntax between C# & JAVA isn't THAT different. Coding is coding and I figure once they get accustom to some of the differences they'll be fine.

Same goes from JAVA -> C#.

Now, if you were a C# person and you apply for a C++ job I want to see experience. There are too many differences.

So yea, it depends on the situation

Answer 11

In part this is about HR throwing buzzwords into a job description since they don't really understand the role. It's why you'll occasionally encounter the comical situation of a job description specifying 3 years of experience in a technology that's only existed for 6 months.

As for whether or not it should make a difference, that really depends on the role and the individuals involved. Just about all managers doing hiring (certainly all smart ones) will instruct HR to pass them candidates that have a lot of strength in most areas even if they are lacking in one or two bullet points in the job description. However that generally doesn't apply to a recent graduate; I'm talking about like people with lots of great work experience interacting with clients or leading teams or something.

Answer 12

I'd think an employer would care more about how many languages / paradigms I am familiar with, or what's my algorithmic / software design experience, as opposed to the specific technology I'm skilled with at the moment.

Have you ever looked at all the elements that make up your development stack? For example, what IDE, testing framework, continuous integration, version control, development methodology, and code paradigms that make up an environment that someone uses to create software. This can be a number of tools that some companies may want someone to already know rather than have to pick up from scratch. ironcode's point about an employer's market is another factor here as there may be some cases where there is a lot of competition for a position and so companies can aim for the sky and possibly get it.

Just to give a more concrete example about that environment, here's what I have where I work: Visual Studio 2008 doing ASP.Net using C# mostly, nUnit, Cruise Control.Net, Subversion, Agile/Scrum, with a blend of procedural, OO, and functional depending on where one is looking. If I wanted to switch over to Java, this may mean getting used to new tools for a lot of these functions that may not be what an employer wants to absorb as a cost of hiring me in that role. There can also be some tricky points that those with experience in that version may know better than others and avoid some pitfalls that may otherwise make someone go, "Why did they build it that way?"

Answer 13

No, look. These requirements aren't put together by the IT guys. They're put together by the HR people. And the way the HR people get the requirements is by shouting questions at the IT people as they stagger back and forth to the coffee machine.

So they say "What do you need?" and the random shmuck who ends up answering says "A programmer. Needs a few years experience. Like, I don't know, 4? And it'd be good if he knew .Net." A reasonable response.

But it gets translated into "4 years experience in .Net 4" and it's .Net 4 because, when you Google .Net, the first link will take you to a page talking about .Net 4.

There is also the possibility, and I've run into this a few times, that they have a specific language requirement because they want to move in that direction, and they think it'll go smoother if they have an experienced person on staff.