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?

  • 2
    You went to a job fair, so you must be a student ...
    – Job
    Jun 14, 2011 at 14:48
  • @Job correct, I am a graduate student. I do have a few years of experience in the industry, but I'm definitely just starting my career now.
    – Oak
    Jun 14, 2011 at 14:57
  • 6
    I'd just like to make a general point on all those blaming HR. In no company that I have worked for (which is quite a few) have HR had any hand in the hiring of technical staff, except to send out the final job offer. particularly, they have never performed CV screening. Jun 14, 2011 at 15:59
  • In my case, when I said HR in my answer I really meant more like "someone who doesn't really understand the technology who is writing the job description." That could be a secretary delegated to typing up a job description from the notes, or that could be a hapless manager who doesn't really understand what it is he wants.
    – jhocking
    Jun 14, 2011 at 16:52
  • @oak Incidentally, could you explain what you mean by "emphasis"? Do you simply mean the languages are listed on the job description, or that the people you met at the job fair were being pushy about it? If it's only the former, then I think you're being a little over-sensitive.
    – jhocking
    Jun 14, 2011 at 16:55

13 Answers 13


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.

  • 3
    I have to point out that the market for programmers is very dependent on location. Where I am (coincidentally in a big university town) the places I interviewed all said it's difficult for them to find candidates right now.
    – Tesserex
    Jun 14, 2011 at 15:14
  • 16
    Tesserex -- that should be translated as "We can't find programmers that know all of our alphabet soup of technologies, at a price we are willing to pay.
    – red-dirt
    Jun 14, 2011 at 15:18
  • 22
    There's programmers aplenty; what's hard to find right now (as has always been the case) is good programmers.
    – tdammers
    Jun 14, 2011 at 15:18
  • 10
    On the contrary, as an employer I can tell you that it is definitely an employee's market, at least for for talented individuals. For great programmers, as always, supply is greatly exceeded by demand. On the other hand, I don't consider someone who has "a couple months" of experience to be a programmer (or a carpenter, or a doctor, or any other skilled trade) so your figures are likely far different from mine. Jun 14, 2011 at 15:59
  • 2
    @Rein -- you can say that all you want, but simple econ doesn't bear it out. If it did, then you would see the salary of the top programmers a lot higher. A top doctor or lawyer will clear 500,000 USD per year... A senior software engineer at google has an average salary of $130,000 (glassdoor). I think what you meant to say, was that you couldn't find someone 3x as productive for the price of an average engineer.
    – red-dirt
    Jun 14, 2011 at 18:39

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.

  • 2
    Great answer. Minor niggle: i don't know if it's that nobody really knows how to hire good programmers, or that HR departments and recruiters don't, and most companies have HR-led hiring processes. I would agree that nobody really knows how to hire good programmers without spending a lot of time on it, though. Jun 14, 2011 at 16:48
  • @Tom Anderson: The best I've heard of is techniques to avoid hiring bad programmers. Given a surplus of applicants, and reasons for good programmers to apply in numbers, this works well enough. All of Joel's suggestions I've read, for example, work that way. Jun 14, 2011 at 17:07
  • 4
    @Tom Anderson I would say no one knows how to tell a good programmer from a bad one by looking at a resume, and no one knows how to interview more people than they have time to talk to. It doesn't matter whether HR leads it, or a technical recruiter or the hiring manager themself.
    – Jeremy
    Jun 14, 2011 at 17:26

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.

  • 2
    Good companies in general invest in employees, and taking a few months to get up to speed is quite common in most industries. Unfortunately, only a few software companies follow this practice. It also (coincidentally ???) seems that they're among the best companies: Google, facebook, Microsoft, etc...
    – red-dirt
    Jun 14, 2011 at 15:01
  • 3
    """You should know at least one programming language really well, and it should preferably be C++ or Java. C# is OK too, since it's pretty similar to Java. You will be expected to write some code in at least some of your interviews. You will be expected to know a fair amount of detail about your favorite programming language.""" steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html
    – red-dirt
    Jun 14, 2011 at 15:16
  • 2
    An experienced programmer can learn C++ in about eight hours... just read "Effective C++", and understand it. That puts you above 90% of the C++ programmers on the market. Understanding the STL puts you in the top 3%. Jun 14, 2011 at 16:37
  • 3
    @kevin Irony? Sarcasm? What? Jun 14, 2011 at 16:43
  • 2
    @kevin: it's clear that you don't know what you're talking about. C++ is one of the most complex languages with more quirks than you can even imagine. There is no way anyone can learn it in 8 hours (a day's work!!!). You can't even learn languages like PHP in that time. Jun 15, 2011 at 1:29

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.

  • I think you raise a very important point mentioning the ecosystem. This is something that can play a huge role, and I'm guessing it usually takes an experienced developer on platform X to get a good familiarity with X's ecosystem; just learning the new syntax and a few new paradigms will probably not cut it.
    – Oak
    Jun 14, 2011 at 16:04
  • I'm with Oak - you make an excellent point that being a good X programmer requires a lot of ecosystem knowledge on top of just picking up language X. Jun 15, 2011 at 2:04

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.


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.


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?

  • 1
    +1 for "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", that sounds like a pretty good reason.
    – Oak
    Jun 14, 2011 at 15:05

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.


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


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

  • 3
    Syntax is such a small part of learning a language.. Jun 14, 2011 at 16:36
  • @Boris that is true, but what he says still applies at some level, whether it is style or libraries or something else…
    – tylermac
    Jun 14, 2011 at 18:09

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.


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

  • But, interestingly enough, usually experience in a source control solution / IDE / Testing framework will be secondary to experience in programming languages (though it can certainly help you get the job).
    – Oak
    Jun 14, 2011 at 15:28

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.

  • 1
    This is a pretty bitter answer. There are probably a few companies where the scene you described is true, but the majority aren't that dysfunctional.
    – jhocking
    Jun 14, 2011 at 17:06
  • Disagree. The last few companies I've worked at didn't even have HR people. And when we advertised for new employees, we required commercial experience with the language and platform we developed on. Why? Because unless there are no candidates with that experience (and there were), why take the extra time to talk to people that don't have the experience, in the hope that you might find someone so good that you're willing to wait while they learn? Jun 15, 2011 at 2:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.