How do I attract candidate developers willing to learn a proprietary language?

Question

At the company I recently joined, development for the product I'm now working on is done in a home-grown language with no applicability beyond this product team.

We're going to be advertising for new developers shortly, but I expect that this will take a long time because of the language.

Clearly, there will still be significant opportunities for our new hires to develop transferable skills alongside the specific language and business domain, but what can we do to make the roles more likely to attract candidates with a few languages under their belts already who are both willing to learn and capable of learning a new language quickly?

Some clarification for questions asked in comments and answers:

1. The product and language have been around for decades and are HUGE both in scale and complexity. Back in the day, the intention was for a whole suite of products to be developed in this language but for reasons lost in the mists of ancient history this never happened. Conversion to a mainstream language would probably be a five year project and new features must be developed in the mean time, so we need developers willing to learn the language.

2. It's not based on any other language I know of. It's a highly efficient way to express business logic for our particular domain. It's supported by an in-house tools team and we have people with decades of experience on both sides of the tools/apps divide.

3. Several people asked about transferable skills. To my mind, the language you use for software development, its syntax and grammatical quirks, are only one part of your job. Problem-solving, analysis, estimation, team-working, architecture, functional and technical design, peer-reviewing, refactoring, source code management discipline, defect analysis, debugging, self-testing, Agile working practices, resilience and professionalism are all transferable skills or attributes that the successful applicants will develop during their time in post. It's also my view that learning a second language makes learning languages three and beyond easier.

4. What attracted me to my role (I've not been a developer for some time) was the chance to help a product team get better at Agile and develop my own Agile expertise at the same time - very different set of issues and enticements from the developer recruitment question.

Answer 1

The traditional way of attracting developers (or anyone else) to do a job that isn't popular is offer to pay them lots of money (or the equivalent in benefits, training, vacation etc). That can be very effective. I knew someone who stayed working on IBM Assembler code for years, because each time they tried to transition to a more popular language, the company raised their salary to whatever they asked. You will probably find that even doing that you won't attract the cream of developers, and you should be prepared for this. That's obviously going to increase your costs, and you may want to offset that by find people for whom the disadvantages of the position aren't as bad as they might be for the average developer. Here are some suggestions:

• target younger developers. Even if they don't get experience with a know language, they will have picked up some real-world coding skills. Their career will have suffered less than a more senior developer. However be aware that they will probably only stay a year or two.
• target older developers. If you are five years from retirement it won't matter so much that your skills won't be as marketable - and anyway, they are probably proficient in several languages already. An older developer might appreciate a higher salary now rather than improved job prospects later.
• target developers who don't fit the standard work pattern Lots of developers have trouble finding jobs for reasons nothing to do with their competence. Those who want to work part-time to fit in with parental duties have it particularly bad, so they may consider any offer that fits their timetable. They also tend to be less worried about career progression.
• Another form of developer who doesn't fit the standard work pattern is the person who wants to work on their own project but needs a regular salary to pay the bills. Offer them a part-time position. However again, if they are good, they will probably leave after a bit.
• Nakedly pillaging from Kris' excellent answer, consider targetting distance workers.
• Borrowing again from Kris', you should also work on improving the long term potential for people taking the job.

Answer 2

The first thing you need to do is to acknowledge what you are asking of potential hires; you are asking them to effectively commit career suicide.

You say that "there will still be significant opportunities for our new hires to develop transferable skills" but you do not expand on that and I'm assuming that this will not include any significant time spent developing using more mainstream programming languages.

When hiring new developers the first thing that an employer will look at is if an applicant has been doing similar work. Preferably using not just the same language as is used in-house but also similar frameworks. Failing to find such candidates they may consider applicants that have used similar languages (i.e. hiring a C# developer for a Java position or a Java dev for a Ruby etc.) or one that has exposure the technologies that are considered up-and-coming (possibly hiring a Scala or Python developer for a Java role).

Since no other company uses the same language as your firm the developers will get little or no credit for it when potential future employers consider their CV. Even a niche programming language would serve them better as the person doing the hiring may be familiar enough with it to determine whether or not proficiency in it may in any way translate.

This may seem harsh, but this is how most managers will approach hiring. They either want good skill-fits or bring in new skills that are needed. If neither of those is available they're most likely to hire someone inexperienced who shows promise and can be trained without first having to be untrained.

So, at best, having worked for you for a couple of years I'd be looking at fairly entry level developers positions and probably being passed over as 'having too much experience' (of the wrong sort) for even those.

OK, so all of that is very depressing, what can be done?

Ideally, you'd plan a migration to a modern language and follow through with it. Assuming that is not possible you have to offer incentives that compensate for career suicide.

Some possible options:

• Offer distance working. There may be a good developer living (and unwilling to move) where there are few opportunities to be had. Such a person may view this as a godsend and be entirely unconcerned about the issues outlined above as they already have difficulty getting work without relocating. This also widens your pool of possible candidates.

• Offer very competitive salary/benefits. This includes things like flex time. Little/no overtime (appeal to those starting a family). Salary alone will not do much as those most motivated by pure monetary compensation are probably those most aware of the long term implications of accepting this sort of job.

• Show that the job has long term potential. Make a convincing case that this is not just a job but a career in itself. This requires showing that the company is likely to be around for a long time. That you promote from within etc.

• Start using modern languages wherever possible. Even if your core applications remains moribound to your proprietary language, starting using modern languages in every possible areas, interfacing with the legacy as needed.

Answer 3

There are two types of software developers:

1. Specialist Developers that have a thorough and complete understanding of one or more technologies, languages or frameworks. Employers that look for specialists in a given area are looking to pay a little bit more if the skill or knowledge is uncommon. They want to ensure quality and that the job is done as well as possible. The specialist may run into challenges in finding steady work from time to time.

2. Generalist Developers tend to be strong and reliable amateurs at just about everything. Given enough time they can always come up with a passable solution. They learn on their feet and get up to speed in unfamiliar situations quickly. They can be great consultants as they are adaptable and become modestly productive very quickly. Employers like them because they are more common, cheaper, and because the Employer may not have a firm technology decision for their projects.

Obviously you are looking for a Generalist type. Here are some ways to attract a high quality generalist type software developer:

1. Evaluate minor knowledge on a wide variety of technologies and frameworks.

2. Engage in conversations during the interview where you just talk about software designs. If they are disinterested or unengaged in design or general software development conversations then they may not be a good generalist.

3. Get a feel for the array of experiences the developer has had throughout his career. The more the better.

4. Judge their work ethic. A good generalist will work harder when they are in an unfamiliar situation.

How you can attract a good generalist:

1. Give them opportunity to grow and learn a wide array of skills

2. Possibly give them leadership roles that can carry well on a resume

3. Offering a bit more money can't hurt.

Answer 4

Consider open-sourcing your proprietary business language.

It may take a significant time to do it right, and reveal just so many library routines as to make the language constructs useful for other people and businesses, but without revealing truly proprietary information that makes your firm tick.

In addition, the process of open-sourcing the language will very likely make it more robust to your own application and the unavoidable improvements during the open-sourcing process will invariably increase the attractiveness of your positions and immediate productivity of any future new hires, curb down their learning curve, as well as enhance the likelihood that their skills at the job would be marketable and transferable.

I am personally familiar with a Russian web-design studio that has developed a CGI language called Parser, which with version 2 they've first decided to make available to the general public as a binary-only interpreter (with full documentation of the language itself), but then with version 3 they've decided to outright open-source, and the language is quite popular in Russia for web-site scripting (or at least it was very popular a couple of years back prior to the Ruby and Python invasion, with many outside companies requiring the knowledge of this language).

Likewise, the founders of GitHub have an excellent article about which exact parts of a proprietary system should be open-sourced; great advertising and attracting and retaining the talent are only a few of the number of reasons they cite for open-sourcing a lot of generic constructs and general-purpose libraries and tools, whilst still keeping unique big-picture primary-business apps as proprietary.

In my personal experience with open-source and proprietary systems, open-sourced code tends to be of a much higher quality than proprietary code that is maintained by a team for only in-house use. By open-sourcing your language correctly, you will very likely significantly improve your existing codebase to say the least.

Answer 5

Off-set this with other company/position benefits:

1. flexible hours
2. casual environment
3. maximize time spent on coding and not in meetings and other distractors
4. having a voice in decision making

For the benefit of your company and the growth of your people, you should sincerely be open to using other technologies if appropriate. You're using your own language, so you should be able to make it work.

Answer 6

1. Find some amateur developers that want to become professionals. Especially people who do not have a degree or any experience. You are looking for people who are not going to have preconceptions about programming languages so someone at this skill level is more likely to get excited about learning your language since they would have to learn a new language any way. This will require having someone take the time to mentor and teach them but that also builds loyalty if done properly.

2. Make sure your compensation for this position is above expectations. The last thing you want is when you get a developer trained and growing is for them to be lured away by more money. Be generous from the start. You are asking them to commit their career to a skill that will not provide much, if any benefit should they they leave. So commit to providing for them and their families from the start.

3. Provide a stable work environment. This does not just mean avoiding lay off cycles but a continuity of management and growth potential within the company. Do not create a meat grinder attitude about new recruits. Treat them all like members of the family. Go out of your way to make them feel valuable and important.

Answer 7

I think the best answer would be to NOT have a proprietary language. What advantage can you really get from writing your own? The people at Microsoft who developed C#, for example, probably knew a lot more about the topic than your employees would know, and they certainly knew more about the operating system it runs on because their company designed it. On top of the language probably having a lot of issues compared to any tested and proven language out there today, it will make it so much more difficult to hire new employees in the future given every one of them will have the initial learning curve of a new language.

If you really are going to stick with your own language, I would emphasize all other benefits of the position to try and downplay the disadvantage the candidate would be in from learning your special language. I feel as though you would need to give more for someone to work on projects with your language however, or you might just get stuck with people desperate for a job that they will take it because they have nowhere else to go. Spending your career on projects that are built on technology no one else will ever use makes it hard to convince future employers that you have useful experience.

Answer 8

I think you're just going to have to market it as a developer position, and find someone who doesn't identify themselves as a <INSERT LANGUAGE HERE> developer, but rather someone who is a developer.

A good developer will be looking to learn something new to expand their horizons and you have a new thing for them to learn. Should be a perfect match.

Answer 9

You can:

Make the job about the technology: Will you be working with a NoSQL database? on a cloud product? extensive http REST work? full life cycle? mentoring team members, scrum certification?

Make the job about the industry sector: will you become an expert in this sector? will the knowledge gained about how this sector be transferable? do you have many competitors, customers and suppliers? (yeah, risky i know..)

Make the job about the environment: flexible working, family friendly environment, starbucks delivered to your desk 10am every day

Make the job about the location: Here is a great location to work, convenient, parking space provided, great part of the country to relocate to...

Make the job about the compensation: We will pay you more, we pay more into your pension, we give big bonuses, share options, monthly company nights out...

Every job needs to market themselves to good candidates, using a combination of the above. If the candidate is worth having, then they will have several job offers, and you need to make your offer more appealing than the other offers. Just remember that most programmers will respond to money, but they respond better to other incentives.

Answer 10

You may want to tell them that:

• skills in mainstream languages are commoditised these days. I.e. for each near-shore Java developer there are 3*10^6 java developers waiting in low-cost locations.
• quantify the value of applied business field. I.e. gaining analytical skills in certain applied business area can open the individual opportunity for growth fay beyond mere software codder
• if corporate brand is known, try to quantify its value in conjunction with long term career prospect. I.e. he/she can get an enumeration up-tick by jumping around Java firms. But where she'll be after say 8 years of expertise in your place

Answer 11

I'll answer as one that just pretty recently took a position in a gigantic company that offered me the same choice. I'm a somewhat accomplished enterprise developer and integrator in the JEE space and I was interviewed based on my skillset and experience, hell the position was advertised as an enterprise developer role. Then came the interview

1. Do not lie about the nature of the opportunity. Advertise the role as is. The job ad was for a senior JEE developer with a strong finance background. Then came the interview and it turned out what they really wanted was to retrain me in the proprietary platform and use me exclusively for that. I looked around for job opportunities with that language and found exactly 6. On 3 major jobs sites. Don't misrepresent the position. I turned down the offer the first time and gave the above reasons.

2. Make sure you have an appealing and versatile platform. One major downside to the platform I was invited on was it's poor support for xml, among other things. I mean what kind of language doesn't let you manipulate xml? Work on your product,make it robust and truly deliver value, don't just concentrate on your effort to lock your clients into your platform (which is pretty much what these guys here have wound up doing).

3. Be very clear that the work environment will be balanced. They'll not be pigeon-holed into the proprietary platform. It was on this basis only that I eventually took the job and my manager has been true to his words. I'm primarily a Java developer and dabble in the proprietary platform

I'd personally be more disposed to picking more projects in the proprietary platform where I am right now if I saw some kind of value proposition or usefulness of the language. What they've done is try to duplicate(poorly) a well known and popular scripting language, and the only value it's delivered is to lock my employer into their platform with no hope of escape

Answer 12

I read the question, but I did not read through every answer.

I was trying to guess the language OP was talking about, so far no one has said it.(I tried to find that word on this page)

I believe I know what it is because I happen to be one using that language.(I am retired now)

High salary is not the solution. The candidate will ask a question, what if the project finishes in 5 years? My resume will have a 5 year experience I would have to explain to my future employer 5 years from now.

I believe the solution is to explain to the candidate why this language is good, why you use that language. Then you get the people who really want to do it. Those are the ones you want to hire.

If the language is the one I used before, you have plenty of ways convincing them to use it. It's still being used nowdays. Google for it.

Answer 13

There are lots of good answers here, so I won't restate them in my answer. Instead, I noticed an area that I didn't feel was adequately addressed by the other answers here.

Although you did not give an example of the language, my experience with in-house domain specific languages is that they are more like procedural languages instead of object oriented languages. Often when they support functionality that is an object oriented concept, it is still implemented in a way that is procedural. This is common, but of course your DSL could be an exception.

Assuming that your DSL is more like a procedural language, then I feel that you should target developers who primarily have a scripting background. Of course most major scripting languages have many object-oriented constructs implemented in their language, and many developers whose primary role is scripting utilize those object oriented constructs. My belief is that most scripting in the real world looks much more like procedural language development instead of object oriented development.

I suggest that you target developers with a PERL background and other older scripting languages such as mainframe JCL, DOS / Windows batch files, etc. I think that in general a developer who is performing scripting full-time might be less concerned with skill rot than other developers as well. Of course there will be plenty of script developers who are concerned with skill-rot and who use object oriented techniques as much as possible, so your selection process should probably work to weed out those people since they might not be as good a candidate as the developers that I am recommending.