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.

  • 9
    why does it have to be a proprietary language? why can it not be done in a standard, commonly used language?
    – amphibient
    Commented Jan 8, 2013 at 17:13
  • 31
    I'd be less worried about learning a proprietary language and more concerned/confused as to why the company would have made that decision to go with a proprietary custom language in the first place.
    – DA.
    Commented Jan 8, 2013 at 18:08
  • 12
    I think you should scrap your BobX code and rewrite it in PHP.
    – zuallauz
    Commented Jan 9, 2013 at 3:10
  • 8
    "Clearly, there will still be significant opportunities for our new hires to develop transferable skills alongside the specific language and business domain" Care to name any?
    – user1389
    Commented Jan 9, 2013 at 4:50
  • 14
    Money will work, otherwise just stop using proprietary nonsense. Commented Jul 15, 2014 at 17:54

13 Answers 13


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.
  • 11
    +1: target developers who don't fit... Perfect. Lots good developers would love to get 1000-1800 hours/year of steady contract work at a good rate. Commented Jan 8, 2013 at 20:39
  • 3
    I love the idea of targeting older devs who are getting ready to retire in 5 years.
    – HLGEM
    Commented Jan 17, 2014 at 16:33
  • This is a really good answer. I am in/was in a similar situation. They gave you a decent starting salary, and then gave a promotion, with a 33% raise after 1-1.5 years.
    – bigdaveyl
    Commented Jan 28, 2014 at 15:13
  • Also developers from developing countries (remote or green-card sponsored) if your company is in a developed country. Commented Mar 21, 2014 at 20:31
  • This question just came up again (March 2019), and all the older devs you hired who were ready to retire in 5 years just left :-( I suggest: Bribe them!
    – gnasher729
    Commented Mar 17, 2019 at 18:08

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.

  • 13
    I think competitive is the wrong adjective. I would look for a generous compensation package before I even considered a position working with a non mainstream language. Commented Jan 8, 2013 at 17:03
  • 5
    "...you are asking them to effectively commit career suicide." Not necessarily, I've known developers who've taken jobs where they've worked with languages only used in house and they've found jobs using other languages afterward.
    – GreenMatt
    Commented Jan 9, 2013 at 16:43
  • 2
    Career suicide? Hardly. I would say that any developer that allows a single language or framework to define them is the one committing career suicide. Furthermore homegrown languages are common for many industrial applications where interfacing with complex machinery and robotics is necessary. Outside of that small area however, I agree there is no reason for a homegrown language if all you are doing is LOB applications, which is about 98% of software developers. Commented Jan 9, 2013 at 19:25
  • 6
    @maple_shaft Of course a dev should avoid being overly specialized. However, this isn't about that, this is about the perceptions of those hiring. They will judge a CV primarily on what the applicant was working with most recently. This is even worse if it goes through HR. Not having recent hands on experience with any language that the person hiring is familiar with will make it much harder to get an interview, let alone a job. "Career suicide" may be a needlessly colorful way of putting it, but taking this job would hurt anyone's career and the OP needs to acknowledge and deal with that.
    – Kris
    Commented Jan 9, 2013 at 20:01
  • 3
    @maple_shaft not everyone gets that choice. In the end, HR (and even hiring managers) will take a similarly skilled candidate which is 'less risky'. Having experience with a language (really the errors the language produces, its libraries & idioms, etc) is still worthwhile and unrisky. And to be honest, working with some homebrew domain specific language isn't going to help the employee become a 'high quality employee' as much as a more generally applicable environment.
    – Telastyn
    Commented Jan 14, 2013 at 1:13

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.


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.


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.

  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.

  • 6
    1 sounds like a recipe for disaster... Commented Jan 8, 2013 at 18:36
  • 3
    It's a disaster for the company, because if you're looking to train someone in a new langauge, you should be looking for someone who already has several langauges under their belt; they will already comprehend the necessary concepts, it's just a matter of learning the new syntax for them. And it's a disaster for the poor amateur developer, because it'll be extremely difficult for them to find work anywhere else in the future: "Looks like your only real-world experience is developing with the obscure language Robblefuzz? No thanks, we're looking for someone who knows C++." Commented Jan 8, 2013 at 18:50
  • 2
    There's a certain large company in the Midwest who loves to recruit right out of college for an extremely obscure language. The initial salary is high for a new grad, but there is little headroom and many developers there end up feeling "trapped" because there is little other application of their domain knowledge.
    – Chuu
    Commented Jan 8, 2013 at 20:24

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.

  • 4
    @Michael I'm always amazed that any company would think it is a good idea to write their own language. What was the reasoning for doing so in your company? Commented Jan 8, 2013 at 14:17
  • 6
    an MD who thought he knew better ...
    – Michael
    Commented Jan 8, 2013 at 14:24
  • 5
    I think you're being too dismissive of proprietary languages. I can't say anything about the one the OP is referring to, but domain specific languages in general can certainly be advantageous because they are designed to be better suited to the domain of a certain business. Commented Jan 8, 2013 at 15:40
  • 14
    -1 (metaphorically, since I lack rep) for giving the right advice at the wrong time. This strikes me as if the OP had said "Given that I've been in this car accident, what should I do?" and the response is "Don't be in a car accident." It's good advice, but it's probably not possible for him to implement. (And writing your own language is definitely like being in a car wreck.) Commented Jan 8, 2013 at 20:12
  • 2
    @BoofusMcGoofus - true, but if the company recognizes this as a problem, they could begin planning to transition to a mainstream language. Commented Jan 9, 2013 at 16:41

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.

  • 25
    A good developer will typically not agree to work on a "homegrown language" -- lack of documentation, tools, unable to find help on the internet or ask questions online, and in all likelihood it sucks since creating a good programming language takes huge effort.. I would also highly question the process that led the company to create its own language rather than one of the existing ones, as this is a huge red flag Commented Jan 8, 2013 at 15:53
  • 3
    @AndreasBonini I disagree that a good developer will run away screaming because they can't get help on the internet. Without knowing exactly what the language is, its age, its documentation, the knowledge of the senior level, it's entirely possible that google may not be the developers best friend. Commented Jan 8, 2013 at 16:05
  • 6
    @Jeremy1026 a good developer will run away because it's going to be a huge pain in the %@# to actually develop software instead of fight the things Andreas mentioned
    – enderland
    Commented Jan 8, 2013 at 17:41
  • 5
    Good developers are looking for something new to expand their horizons, sure. But why would they want to learn your proprietary language instead of one of the many interesting and broadly applicable technologies they could learn instead. Answer that question an you might be able to recruit them. Fail to do so and you're going to have problems.
    – MNGwinn
    Commented Jan 8, 2013 at 20:45
  • 1
    @Rachel: This is assuming the language was created by a big company with a huge budget, which is the 1 in a million case where it's somewhat acceptable. In the other 99% of cases new languages are created by small companies by a naive programmer who doesn't know better. Commented Jan 13, 2013 at 0:02

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


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.


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

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.

  • I've deliberately avoided naming both the language and my employer as I'm posting unilaterally, rather than with their permission, support and editorial guidance...
    – Xav
    Commented Feb 4, 2013 at 12:58
  • @Xav I do understand. That's why I did not spell out that language explicitly. I think the other answers are wrong if my guess was right. Good Luck!
    – Nobody
    Commented Feb 4, 2013 at 13:02

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .