Enterprisey Developers, Acronyms, and Discrimination

Java eyechart

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.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful.  You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.

14 comments

  1. The Alchemist

    Thanks, Dave! Great article.

    On the flip side, from the perspective of the candidate, we usually have one resume which aims to please all companies–large, small, startup, and mega-bureaucracy. We’re just trying to cast a wide net.

    Another reason our resumes sometimes sound like ‘buzzword bingo’ is because these resumes must get past keyword-based HR search engines. I don’t wanna be rejected from a position because I don’t have JMS on my resume and the position uses a lot of JMS.

    Perhaps one approach to a solution that pleases both parties is more than one resume: one for mega-large, Java bureaucracies that still use JBoss 4 and one for fast-paced startups. And then the onus is on the recruiter to send the right resume.

    I personally have a few resumes, depending on the sector / position. But if a recruiter wants my resume, they get the default one unless I know what the client is.

    • fecak

      Your ideas are right on the money. The applicant tracking systems used by big companies make it somewhat necessary to include lots of buzzwords. This particular article was about a fairly specific circumstance of moving from larger to smaller companies, in which case the ATS is probably irrelevant. But you are correct that multiple resumes are advisable for most candidates these days, considering your audience will be varied (as will the level of position and role).

      Recruiters who know their job should be aware of what their clients want and which resume should be the best fit for any particular job, and when you are working with a recruiter they should be able to provide you advice on whether or not changes would be advisable. When a recruiter is not involved, you are somewhat on your own to tailor the resume and try to include and eliminate what is deemed most attractive and appropriate. Thanks for reading.

  2. Pingback: Geek Reading March 8, 2013 | Regular Geek
  3. Pingback: Links & reads for 2013 Week 11 | Martin's Weekly Curations
  4. Raj

    Nice article, Thanks!

    I am a Computer Applications Graduate from India,
    I am moderately good at programming (VB6, C++, JAVA), please advice me which technology should I choose for my career. I dont want to make quick money, but after say 3-5 yrs I should have become masters in that field and I must become an asset to my company.

    • fecak

      Thanks for the comment, and your question is not easy to answer. I might advise you to learn more about various languages and programming tools, both past and present, to see if there are any that you really connect with. Certain characteristics and paradigms might not seem natural to you, while others might just seem to make sense. Then try to see what demand is like for the things you choose. Once you have done some research and perhaps had a job or two, I imagine you will find something that appeals to you. Good luck.

  5. Pingback: Why You Didn’t Get The Interview, Part II | job tips for geeks
  6. Pingback: Escalate Digital Media | Why You Didn’t Get the Interview (Part Two)
  7. Pingback: Why You Didn't Get the Interview (Part Two) « bogdi dot com
  8. Pingback: Why You Didn’t Get the Interview (Part Two) | Binary Reveux
  9. Pingback: Why You Didn't Get the Interview (Part Two)
  10. Pingback: Why You Didn't Get The Interview (Part Two) | Lifehacker Australia
  11. Pingback: Why You Didn’t Get a Interview (Part Two) « Music RSS
  12. Pingback: Boot Camps, MOOC’s, and Jobs: A How To For Fresh Devs | Job Tips For Geeks

Leave a comment