Are specific programming language skills and experience important in a job candidate?

Question

This kind of relates back to the Specialist vs. Generalist questions, which I know that Both is the correct answer for, but I am coming at it from a different direction. I do the interviewing for new software development candidates, and we currently evaluate heavily for specific language skills and knowledge and look for specific language experience as one of the criteria for hiring. We also look for the candidate to be a well rounded generalist, but that is secondary to them be a great specialist. This is all fine and good and we have hired a number of really fabulous programmers and are not hurting to hire anyone else.

But I have been thinking. If I am presented with two candidates, the first being a specialist in our language, but very little other experience (poor generalist), and the other candidate being a fantastic generalist, with only passing knowledge in our language (but specialization in other languages with similar characteristics), while everything else is equal, which would be a better hire?

We have no plans of switching languages, so other language skills are not directly applicable. Generally I am leaning towards the specialist, because they have less to learn, but I am wondering if the fantastic generalist (with other specialties) might be as good of if not a better choice.

My thinking is that of the skills required to do the job:

1. Framework specific experience
2. Language specific experience
3. General software development skills
4. General software debugging skills
5. Good design skills
6. Domain specific knowledge (or target industry)
7. Understanding of the existing code base

The ones at the start of the list are documented much better (thus easier and quicker to learn) than the ones at the end of the list. So much more so, I would say a generalist who excels at #3, #4 & #5 would be much more valuable than someone only with skills in #1 & #2 (even if those are very deep skills) since those are easily discovered through reference documentation. Granted it seems unlikely that someone would have good skills in #1 & #2 without some of #3, 4 & 5.

With #7 & #6 being the hardest to gain, that makes existing employees way more valuable than new hires, no matter how good their skills are in the first few areas.

At my previous job they hired me in part for my specific language experience, but shortly after I was hired they got a new manager who decided he liked some new shiny Microsoft language, so we started rewriting everything. My specific language skills were no longer relevant, but I still found myself promoted to the lead developer over other developers with more specific language skills in the language du jour.

All things being equal in generalization, when there is a specific language in use it makes more sense to hire a developer who has specialization as one who does not.

The question:

Enough explaining my position. I am curious what the consensus is on Stack Overflow. Is it more important to hire for language specific skills? Should language specific skills even be a criteria in hiring? Is it better to have developers focused on development in one language once they are hired, or should they be moved between different projects (in the same domain) that use different languages? If you have a project in a different language, but the same domain, and it is canceled, should the developers be laid off, or retrained in another project that uses a completely different language that they don't have skills in?

Thanks!

Answer 1

I would always go with a fantastic generalist. If I could have both I would, but if only one, I'd take the fantastic generalist.

You want flexibility, out of the box thinking, ability to see problems from multiple points of view, and experience in different software environments.

That's my take at least.

---

Language specific skills should be important if a shop is devoted to one language/platform. If that platform changes, the developers should at least be given the option to migrate to that platform, and accept the learning curve. Don't forget that they have experience in your specific business. If they just don't want to go with the new platform they can make that decision themselves, or else you can review with them after a few months.

Answer 2

I would go with the fantastic generalist by far. I'd pay him twice as much.

I'm skeptical that anyone who is a "specialist in [one] language, but very little other experience" is actually writing really top-quality code in that language. I don't think that experience in one language is sufficient to develop the breadth and depth of problem-solving skills necessary for honestly fantastic work.

Answer 3

I would go for the fantastic generalist too. I think if the person is smart, within a month or so, he or she may be up to speed on the language and the platform, but if the person writes sloppy or messy code, he or she can introduce bugs that takes a few hours to find and someone else may need to fix it for him or her. Also, it might be a problem if he or she cannot adapt to other needs (such as needing to write some Javascript or jQuery while doing PHP work).

Answer 4

It depends too much on the technology and the other aspects of the candidates. No way would I hire a fantastic C# specialist if I needed hardcore kernal c++. Nor would I hire someone with lots Java, perl ruby and database skills.

You can teach a lot about a specific language to someone who is smart enough to learn quickly, but it is the "smart enough to learn quickly" that weighs in more than knowing a specific thing.

Answer 5

A skilled programmer is language agnostic. For example, if I was looking for a ruby programmer, I would favor a talented individual who knew C, python and java, but not ruby, over an 'ok' developer, who new ruby in and out.

Answer 6

Generally speaking, the fantastic generalist is more likely to gain specific domain knowledge quickly and have a better change of becoming a domain expert than a niche developer is in becoming a fantastic generalist. Also, it is not that the generalist will be better at thinking outside the box, but that the box within which the generalist is thinking is much larger than that of the specialist. The generalist brings more potential to the team. However, I agree that the two types compliment each other.

Answer 7

If you want the person to hit the ground (job) running then hire the specialist. You will get value for money from day one.

Answer 8

I read somewhere (Code Complete, I think), that it usually a person needs about 2 years to master a programming language. I was once hired to work in a company that used the .NET platform (C# language) and I had only Java and C++ background - in my first week I took an ASP.NET class (which was pretty good), and after a while I was delivering as much as my other fellow developers, although I did some mistakes that are typical to a newbie in a new language/ platform.

But, anyway, I would hire the generalist - but it will work MUCH better if your company has already people fluent in the language/ platform that you are using, and if you have a code review/ tutoring process that's efficient and will help the new person to be up with the team fast. I think specialists will struggle with anything new - a new development paradigm, a new source control repository, a new library repository, a new way to access databases, etc...

As Jeff Atwood pointed one time at his blog, there are no experts.

Answer 9

I would love to say 'go with the Generalist' but I have this lurking issue in this decision. Excuse me for going against the general grain of this thread...

A mastery over the language is the most valuable asset in any form of communication. It is the means of communicating ideas clearly to the audience/user. I would not employ a Generalist as a dedicated coder just as I would not employ a great thinker as a speech writer. I would employ the Generalist as my ideas/prototype person but I would look for someone who can communicate ideas through exceptional code as my end-product asset. Language is the art of communication after all.

Faced with this decision I would ask - is the Specialist someone who can take an idea and realise it in exceptional code. What use is a Generalist if they can't communicate their ideas in the 'common' language? If they struggle to communicate their ideas in the language of choice, value is lost. Just as in the spoken language, a good word-smith is the person who is responsible for communicating the message.

Answer 10

I would think that a team would need both Generalists and Specialists but not in equal measures so which one you pick depends on what the current balance of Generalists to Specialists in that particular team is.

A Specialist will be able to drop straight into your codebase with less mentoring and teaching required, this makes him/her an excellent ROI hire because they are immediately productive.

A Generalist might require a little bit more coaching but is likely to have a much better all round experience and may be able to bring in a different perspective on a problem as a result of his experience in other languages/environments which those programmers who have only used your primary language may miss.

As with any team you need a mix of different personalities to get the best out of the people involved. However you don't want to be training every single new-hire on a new language as this takes time away from other developers who could be being productive otherwise so I think it is very important to have both Generalists and Specialists but in the right proportion.

There is probably a most-efficient proportion to be found but as a guess, it could be, for example, that hiring 70% Specialists and 30% Generalists would give you enough outside experience to be beneficial but without spending too much time training the Generalists up.

Answer 11

Skills with particular languages or technologies don't matter as much as recruiters and HR drones seem to think they do.

I've literally had a conversation with a recruiter that went something like:

Him: I see you have 8 years of Java experience. Do you have any J2**S**E experience?
Me: J2SE, not J2EE?
Him: That is correct.
Me: Uh... 8 years.

That being said, skills and experience aren't irrelevant either. Thing is, technology is constantly changing and programmers will probably always be required to pick up new skills on the job. It's been like that probably as long as computers have been around.

As for your question about a technology change, retain the team unless they're useless, which might be the case. If the new version replaces the old or the new project is even just in the same industry, the domain knowledge invested in that team is immense and far exceeds any language or technology gaps.

I've seen a successful recipe used previously where contractors were brought in to basically impart skills onto the existing team (I was one of the contractors). There was no more than about 1 in 8 contractors and that actually worked really well.

Throwing away extensive domain knowledge over a little thing like knowing Java instead of C# is, well, pure insanity.

Answer 12

Speaking as a fantastic generalist (I wish :P) I can tell you that in practice it's the specialists who get hired. Blame language tests. Blame recruiters.

Somebody who understands what they're doing is looking for a good programmer, and a good programmer thinks in meta-languages not actual ones. All else being equal, a good programmer who also has experience in your toolset is of course going to get hired before a good one without the experience, but in my experience hiring is more frequently a case of ticking boxes and letting probation periods sort it out.

Answer 13

I'd consider how senior is the position that you are hiring. If it is a junior position, then the language specific skills may not be worth that much as you could expect the person to not be as aware as someone that has been developing for many years. On the other hand, in senior positions you may want someone with deep language specific skills as there may be code optimization challenges to be solved quickly.

In regards to shifting a developer around, this depends a little on how broad can a domain be. For example, within my web world I have classic ASP in VBScript, ASP.Net in C#.Net or VB.Net, Javascript, CSS, HTML, and XML that I am somewhat expected to have some knowledge in each of them, but then I have been developing for enough years that it makes sense for me to know most of these from within the Microsoft stack.

As for the last question, my suggestion would be that this boils down to the tradeoff of whether or not the retraining is more expensive than rebuilding the developer group which depends a little on external factors as if a company is going to create their own language then it may not make sense to lay off the developers as noone has skills in the new language being used.

Answer 14

Attn Developers ....

Other than this being a really BS question.

Id like to put this in a future tense ... as this is a really bad way for this industry to be thinking.......100% TOTALY NO question at all.

Who here is still able to make a living writing Borland C++ 5.0/6.0 using OWL 4.5 anymore...anyone anyone?

Ok more to the point as a .net developer 1.x 2.x... who is still doing this... are they still specialists? We now have 3.0 3.5 4.0 and silver light or whatever is going to be the next "great" version. IS this still a specialist?

I could understand this question if we all "could" work on a single language/library for more than 10 years. But these products don’t have that kind of lifespan. And those of us who have been going this long enough realize this.

When you get down to it many most devporducts are really similar in concept and function.

Just vocabulary and mechanics are different. Heck you can get tangled up just between different codebases even if the tools are exactly the same. There is some weird stuff out there that many shops are really proud of... I have seen this MANY times and as a highered gun "consultant" I have to sit there and either "Agree" or crush the dream gently.

So really bottom line.... exclusive Specialists are noobs or chumps. But, normally they are cheap. Get 20 years experience coding then call me if you want to argue this. I promise that there isn’t an argument because not a single developer will be a specialist in 20 years...COBOL and JCL excluded.

Also the managers that are looking at just getting specialists for staff positions are normally not the right "Sort" of folk to work for. They don’t want growth or expansion... of their people. Just code and leave me alone. Work cheap, don’t make me think, don’t innovate, don’t do things better ...just code these boxes. Until I outsource you. Nope Specialists are not going to have a future.......

Nope,

But if you are going to be a specialist .... Better choose wisely. Dont pick the wrong tool. If /when it fades away in 5/10/15 years, you wont be a specialist and wont be gainfully employed. Ask Borland, Business objects, clipper, DBIII developers. You won’t want be a specialist at all.

Remember, it's your living not your managers. And your responsibility to keep skilled and employed. Be Productive, Make excellent product, Make it Fast, Make it accurate.