Learning a New Language on the Job

Question

I've seen some blog posts about software developers just being hired learning a new language so that they can build their companies' next program. Personally, I've always believed that developers should already know the language since they're new to the company (and know what language the program will need). To expand on that, it's not like an old employee who was hired for say, their Java skills, who now need to build a C# program.

So my questions is, why do some companies hire developers with no language experience instead of those with the specific language experience? Presume that all non-programming related factors are equal.

Related, what commentary can you share about learning a language on the job (if you have done so)?

Answer 1

Learning a new language isn't hard for a competent programmer. If you have experience with enough other, similar languages, you should be able to get a basic feel for things in a day or two, and in two weeks be proficient. As such, it's more important that the developer be well-grounded in the concepts that remain the same for all languages, and have exposure to enough different languages that another one can be picked up quickly.

Answer 2

Knowledge of a specific language is secondary to abilities like learning new things, getting along well with team members, and producing good code that others can work with.

Answer 3

I've noticed that they can usually hire the inexperienced but willing, and pay them less, train them, while continuing to pay them less. Meanwhile the value of the employee goes up. Especially if he's being taught by employees that they already have.

This is much more inexpensive than say, paying that guy that already has the skills, because he's going to want more money than they guy that doesn't know the language.

This is more common in the network administration field, or so I think.

Coming back to this answer, I've since noticed that places looking for interns usually want freshies, because they're 'uncorrupted' and can be taught 'the right way'.

Answer 4

It's far more important that a developer be able to adapt to his or her environment than to walk into a stream that's running smoothly and just go with the flow. I see the difference between developers in ambition evident in the number of languages or technologies they know, and the number of years that spans. A programmer with 10 years experience in one language may have an elevated title simply due to years of experience, but as soon as that language (in particular, FoxPro) is phased out, that person's in a real bind. A more ambitious developer will be ready and willing to learn something new, not just languages, but technologies and business systems, and can adapt to change more easily than someone who is an expert in just one language. To a business, that means the person is more versatile and easily kept and repurposed as a business asset.

I've learned several languages on the job and found the process made me a much better developer with an eye for the whole software engineering process. While some days frustrate me, most of the time I see the "job" as more of an adventure of learning; the developers who are stuck in one language are obviously tortured by their situation, because they've become the "go-to guy" for a particular project and can't get out. It takes a LOT of effort to learn enough to escape that rut, but it is very, very worthwhile.

Answer 5

When my company conducts interviews, we're more interested in finding good smart people rather than someone who matches bullet points. If they're smart and match bullet points, well, so much the better.

This is because that when you trust that someone is intelligent enough to learn new things, you don't worry that giving that person someone new will pose an insurmountable challenge.

IMO, a good team isn't a good team just because they happen to know all the skills required for a given task. A good team stays good because they trust their coworkers -- they believe in each other's ability to carry necessary weight.

That said, we do look for similar langauges.

Know C#? Java probably won't be that big a hurdle. Know Perl? PHP should be easy to pick up. Know Ruby? Python should present concepts you're already familiar with.

Honestly, the only time we truly do look for a specific language is when we hire front-end developers. In general, it's been my experience that HTML/CSS, funny enough, is something that typical back-end developers have the most trouble with.

Answer 6

Where I work there was a case where a couple of Java developers were hired for a C# project, as most of the developers in the company were Java developers and not C#. After the C# project wrapped up, new development was done in Java so it was a temporary situation.

A second situation is that some companies may have a proprietary programming language that I'm pretty sure it isn't fair to assume people will know it. For example if 99% of Visual C++ code is written in macros that a developer at a company created, is it fair to think others would know it? Same thing if there is an internal mark-up language for designing pages on the site. I did have both of these happen at my first place outside university and I just got used to using the macros and language, which I find to be common in most workplaces as there are usually various conventions that some places will use but not others.

Lastly, consider how diversely one could use a language. For example, do you know how many different ways one could have an ASP.Net page say "Hello World!" using C#? I can think of at least a few, ranging from a few examples in the code behind and a few in the .aspx file.

Answer 7

As a former colleague liked to say, "You can train a smart person, but you can't smart a trained person."

A lot of places emphasize hiring the best talent, with the assumption that the talent can learn whatever is required to get the job done.

Answer 8

I was hired by someone who had a degree in computer science, had been working since he was 14, participated in programming competitions and was basically an IT whiz kid. He knew about JOS and advertised on the job board there, and on Craigs list.

The job was for VB and .NET and he interviewed people for 2 weeks giving them a 3 hour interview process involving questions, class design, and programming on a whiteboard.

I had no VB or .NET experience, but 27 years experience, a M.Sc., ABD (all but dissertation), publications, and experience in Java/C/C++/Lisp and management experience.

In my code he thought there was an error, but we walked through an example and my code was correct.

I got the job, picked up VB .NET fast enough to complete my first project on time, and went on from there.

Answer 9

Simple truth that syntax is teachable and language is trainable.

Fundamentals like the ability to communicate with team members and customer (verbal and written), understanding the fundamentals of breaking down problems and solving them quickly in tech support and debugging, willingness to share knowledge with team members, has a personality that fits the team, and able to listen to a business problem and translating this into a technical design are not as easy to teach and learn.

Do they understand the fundamentals of object-oriented design and development? Can they take an problem and figure out how to solve it rapidly? Can they explain clearly what is going on with a specific situation at a customer site and come up with a potential solution? Can they explain the scientific method of solving problems?

The difference could easily be 10 times the effort to bring someone on who knows the language and tools, but has nothing else.

I would not hesitate hiring someone who has all the non-language qualities and train them on the coding part. The language and syntax and the best practices are not a ten day and go thing as suggested elsewhere in this thread, but certainly with experience in other languages and approaches the learning curve is significantly shorter.

Answer 10

I would say that the most important thing that a programmer or engineer should know is how to solve a problem. The tools are less important, but knowing the process of solving the problem at hand is something any employer should value.

In fact starting at current job, my programming experience was pretty limited to embedded environments, so assembly and c, mostly. Over the years it has been necessary to learn a some java, some c#, some python, some perl, and some php. Each has its place, each neccessary depending on the situation of where the application will be deployed, who is the end users, what is the user's platform, etc.

Luckily, many languages have similar syntax, c, java, c#, perl, and php are all similar in their syntax, so it becomes easy to transition from one to the other.

And all of these mentioned languages are all well documented, which makes function lookup a bit easier. The bottom line, a good engineer knows the situation and which language will best suit it, a basic understanding of how to attack the problem, then the details would be trivial.