22

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?

Oak
  • 5,215
  • 6
  • 28
  • 39
  • 2
    You went to a job fair, so you must be a student ... – Job Jun 14 '11 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 '11 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. – Neil Butterworth Jun 14 '11 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 '11 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 '11 at 16:55
  • @jhocking I just noticed that recruiters asked more about my programming languages than previous experience, interests, projects etc., and I kept answering with "I don't really care about the language". Now I definitely understand if I'm too naive about people's ability to learn new languages, but still, it seemed like there was just too much emphasis on something which I consider very "learn-able". So I wanted to ask here. – Oak Jun 14 '11 at 17:57

13 Answers13

24

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.

red-dirt
  • 3,668
  • 1
  • 22
  • 26
  • 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 '11 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 '11 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 '11 at 15:18
  • @tdammers I think you got it most accurately. In this office building, I've seen at least four interviews done with the same company (not mine) that I presume failed, since I know that company was only looking for one person. – Tesserex Jun 14 '11 at 15:50
  • Oh yeah. I've seen people with impressive resumes fail horribly when tasked to implement a fully-specced web application - nothing fancy, just collect some data through a wizard and post it to a web service. – tdammers Jun 14 '11 at 15:52
  • 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. – Rein Henrichs Jun 14 '11 at 15:59
  • 1
    +1. Good at least someone else has said it. I've made similar experiences in Germany and Switzerland - although even state authorities regularly declare the shortage of programmers and the impact on local businesses a simple run through the published ads and a hands-on experience with hunting a job will give you a cold shower. Don't believe the propaganda. –  Jun 14 '11 at 16:15
  • 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 '11 at 18:39
  • Further, a "couple of months" was in relation to someone that already has several years of experience, coming into a new platform. – red-dirt Jun 14 '11 at 18:41
  • 1
    @elfuser your "simple econ" doesn't bear it out because it's flawed. There's no reason that their salaries should be the same. They're in different markets with different market forces. Even if the comparison were apt, it also assumes efficient markets and rational agents, both of which are known to be false. Employment is an extremely inefficient market. What I **meant** to say was exactly what I did say: it's a seller's market for competent programmers. If anything, the influx of incompetent programmers helps to make it so. – Rein Henrichs Jun 14 '11 at 18:58
  • @el fuser: Are you an employer? If so, on what planet do you live? – nikie Jun 14 '11 at 19:30
  • @Rein -- you didn't read correctly. I didn't say they would be the same, I said they would be *a lot higher*. Instead, what **the data** shows, is that tech salaries have stagnated or declined in the last few years: http://m.signonsandiego.com/news/2011/feb/16/tech-salaries-stagnant-second-year/ – red-dirt Jun 14 '11 at 19:40
  • Again, supply & demand: scarce resource = higher salaries. – red-dirt Jun 14 '11 at 19:42
  • 2
    @el fuser As I said, that is only true in an efficient market. This is an extremely inefficient market. For instance, if very productive programmers are 10x more productive than mediocre programmers, why are their salaries not 10x more? Because it's extremely difficult to evaluate programmer productivity during hiring. The buyers have very poor information. Thus, the extremely inefficient market makes your otherwise true statements about supply and demand far less applicable. – Rein Henrichs Jun 14 '11 at 19:46
  • @Rein: The market fundamentalist's answer is that the reason for the apparent inefficiency is that the market is not for good programmers, it's for programmers with good CVs. Perhaps because in the corporate hierarchy, there actually isn't a reward for hiring good programmers (because that's so hard to measure), but there is a reward for hiring a programmer who looks good on paper. But either way, as long as there isn't a tenfold difference in the value of their CVs, there won't be a tenfold difference in salary. – Tom Anderson Jun 14 '11 at 21:00
  • 1
    @Tom Yes, I'm perfectly happy to have a conversation (elsewhere) about why the programmer hiring market is or appears inefficient. What I'm not going to do is let someone with no evinced hiring experience or actual understanding of "simple econ" get away with bad economics, false analogies and non sequiturs. – Rein Henrichs Jun 14 '11 at 21:03
  • My understanding of econ is indeed limited by only having 12 undergrad hours in the subject... Of course the market isn't perfectly efficient, but you're way off base saying that it's totally inefficient. I have been on the hiring side for several years, as well as the interviewee side. Plus, I'm good friends with some guys I went to college with that are now recruiters, and we compare notes. The companies I've worked at have never had a problem finding good people. We always had stacks of res. Of course I've always worked at places that paid well and offered quite a bit of developer autonomy. – red-dirt Jun 14 '11 at 21:58
  • In addition, the **hiring** process isn't the only time evaluation occurs: The "10x more productive" crowd should be seeing an increase throughout their salary history, which should carry over into the market. – red-dirt Jun 14 '11 at 22:05
  • 2
    [Programmers chat](http://chat.stackexchange.com/rooms/21/programmers) move it in here guys. – Raynos Jun 14 '11 at 22:20
  • "you're way off base saying that it's totally inefficient" Good thing I didn't say that. – Rein Henrichs Jun 15 '11 at 06:25
15

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.

David Thornley
  • 20,238
  • 2
  • 55
  • 82
  • 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. – Tom Anderson Jun 14 '11 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. – David Thornley Jun 14 '11 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 '11 at 17:26
8

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.

Neil Butterworth
  • 4,056
  • 3
  • 23
  • 28
  • 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 '11 at 15:01
  • +1, maybe it's harder than what I think it is, but wouldn't you say you would have learned PHP faster if you were studying it full-time as part of your work day? – Oak Jun 14 '11 at 15:03
  • 1
    @el fuser Of course - no one expects a new hire to be productive on day #1 or even in month #1. But even Google are not going to give you the time to sit down and learn C++. – Neil Butterworth Jun 14 '11 at 15:05
  • 1
    @Oak No, I wouldn't. The work environment is the very worst place possible for learning a new language. – Neil Butterworth Jun 14 '11 at 15:05
  • 1
    Oh really? That's contrary to everything I've read about them. Their requirements postings only say they want you to have experience in **one of** java / python / c++... According to the infamous Steve Yegge post, they only care that you know **your favorite** programming language well, because you'll need to use it in the interview. – red-dirt Jun 14 '11 at 15:16
  • 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**.""" http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html – red-dirt Jun 14 '11 at 15:16
  • @el Fuser "This blog is not endorsed by Google." – Neil Butterworth Jun 14 '11 at 15:20
  • 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%. – kevin cline Jun 14 '11 at 16:37
  • 3
    @kevin Irony? Sarcasm? What? – Neil Butterworth Jun 14 '11 at 16:43
  • @NeilButterworth I believe he meant "A godly programmer" The kind of person who can skim read the g++ source in 24 hours and have a solid understanding of C++. – Raynos Jun 14 '11 at 22:24
  • @Neil - Totally serious. If you understand OO programming, but not C++, reading Effective C++ will teach you more than most people ever learn. – kevin cline Jun 14 '11 at 22:32
  • 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. – Andreas Bonini Jun 15 '11 at 01:29
  • @Krelp: yes, C++ has a lot of quirks. I used it for years and knew it quite well; I still have all the early literature on my bookshelf. But still, one can get along quite well by following the recommendations in Effective C++. When I was interviewing C++ programmers I was thrilled to find anyone who knew half the stuff in that book. – kevin cline Jun 15 '11 at 03:41
  • @kevin The recommendations make no sense if you don't know the basics of the language itself. Effective C++ is not a beginners guide. – Neil Butterworth Jun 15 '11 at 06:39
  • @Neil - It worked for me, transitioning from C to C++. I think it would work well for an strong programmer with a decent understanding of object-oriented programming. – kevin cline Jun 15 '11 at 22:50
  • 1
    @kevin Ok, whatever. Sheesh. – Neil Butterworth Jun 15 '11 at 23:00
8

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.

Paul Butcher
  • 2,817
  • 1
  • 18
  • 18
  • 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 '11 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*. – Carson63000 Jun 15 '11 at 02:04
4

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.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
4

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.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
3

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?

Morgan Herlocker
  • 12,722
  • 8
  • 47
  • 78
  • 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 '11 at 15:05
3

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.

Wayne Molina
  • 15,644
  • 10
  • 56
  • 87
3

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

2

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

ist_lion
  • 3,422
  • 1
  • 22
  • 23
1

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.

jhocking
  • 2,641
  • 19
  • 18
0

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

JB King
  • 16,795
  • 1
  • 40
  • 76
  • 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 '11 at 15:28
-2

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.

Satanicpuppy
  • 6,210
  • 24
  • 28
  • 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 '11 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? – Carson63000 Jun 15 '11 at 02:10