Over the past few years my clientele shifted from a mix of mostly mid-market companies and a few startups to almost entirely startups, and that shift has resulted in a wider palette of languages requested by clients.  Where my business was about 95% Java for the first 10+ years of my career, today it is closer to 25%.  As I’ve written before, my business veered naturally from a pure Java focus when a considerable amount of the Java talent I have represented in years past started to migrate and show interest in diverse languages and ecosystems.

Unlike the boom periods for startups in the past, it appears that today’s startup is much less likely to choose Java as the primary development platform.  Many developers who did Java work for startups in the mid 2000′s sought higher ground in the late part of the decade when small shops took a hit, and found themselves working for large companies and more corporate environments.

Flash forward to the past few years and the resurgence of startups.  Many of those engineers who took shelter in the larger firms are now interested in establishing themselves once again as a major contributor on a small team in a startup, and when I have represented some of these highly qualified developers to startups now, I’ve been met with the feedback ‘The candidate’s résumé appears too enterprisey‘.  As an aside, I don’t get that response nearly as often for Java engineers that stayed with small companies.

The enterprisey label, in my experience, seems to be used in two situations that can often (but not always) go hand-in-hand.  First, enterprisey is often used to describe candidates that come from large development shops regardless of the languages used (although Java and .Net platforms are the norm), where the bias is that the development culture and the broader company culture make that candidate less likely to succeed in the startup.  This is the result of preconceptions surrounding development methodology, possible unnecessary complexity in applications, a slower release schedule, or the impression that developers in these larger environments are sheltered from tasks related to data, devops, sysadmin, and QA that are frequently handled by developers at startups.  The label may be applied liberally to virtually any candidate coming from a company larger than the hiring firm.

The second common enterprisey tag is used on any developer using Java or .Net regardless of the employer size, due to the predominant viewpoint that other language communities have developed regarding Java/.Net being wrought with and plagued by dozens of frameworks and bloated stacks.  As someone who sees thousands of résumés a year, it is clear that résumés of Java and .Net developers are often significantly longer than those of developers in other languages, but there could be several factors at play there beyond just the number of potential bloat items (insert Java = verbose joke here).  At a distance, the résumés of Java developers can resemble an eye chart, with acronyms outnumbering actual words.  One hiring manager of a Scala shop provided this gem:

“The laundry list of legacy enterprise technologies (JMS, JMX, etc.) doesn’t do anything for me.”

The word ‘legacy’ seems particularly cruel there.

Sadly, many of those making hiring decisions in these startups are quick to dismiss a highly-skilled talent simply because of their experience working for a larger company or their primary language being in the Java or .Net worlds.  Whereas an interest in, say, functional languages is now often used by startups as an indicator of ability, the prolonged use of Java or .Net at a large firm can be a detriment when applying for work in any other language or polyglot environments.

So how can engineers labeled ‘enterprisey’ escape that bias and be accepted by  smaller shops with different languages?

Résumé and bio de-enterprisification – That’s not a word (yet), but the concept would be to go back and make sure your résumé/bio/LinkedIn profile/etc. doesn’t read like a corporate Buzzword Bingo card.  Eliminate or modify anything that may appear steeped in bureaucratic process and procedure, and be wary of any items that can be perceived as indicative of a glacial development pace.  References to project length and time between releases should typically be avoided.  Emphasize new development over maintenance tasks, and accomplishments over process.  Listing too many tools, frameworks, and specifications will often work against you and may be considered an indicator of your dependence upon them.  Shortening the résumé is almost always the way to go here, and three + page résumés generally smell of enterpriseyness.

Develop other language credibility – Any code that you can point to that does not run the risk of being labeled enterprisey is better than nothing.  As stated before, some startups perceive functional programming interest as a marker for ability, so even an implementation of a typical interview exercise in a functional language (or one different from your primary) has value.  Provide links to this code on your résumé and reference any personal projects that are applicable.

Stop calling yourself ‘LANGUAGE Developer’ – I do it too (all the time), but you should not.  Use whatever you feel is appropriate – Software Engineer, Programmer, Developer, Geek – but stop inserting a language when describing yourself on paper or verbally.  And perhaps more importantly, stop thinking of yourself as a LANGUAGE Developer.  Sometimes you may need to dumb it down so the clueless recruiter will find you, but try to minimize those instances the best you can (and do you really want that recruiter to find you anyway?).

Express your outside interests – Just because you get paid by some insurance company to write Java/.Net apps all day doesn’t mean that is who you are.  If you are exploring other languages through books, conferences, and self-study, make that known in whatever way may be discovered during your job search (résumé, blog, social media, etc.).  Hobbies like robotics, Raspberry Pi, and Arduino are probably unrelated to your job but not necessarily unrelated to your career.  Any technical interests beyond the primary function of your job demonstrate at least some level of versatility and the ability to adapt outside of your enterprisey 9 to 5.