How To Disrupt Technical Recruiting – Hire an Agent

NOTE: AFTER SEVERAL YEARS I DECIDED TO OFFER THESE AGENT SERVICES TO CLIENTS. SEE FECAK.COM FOR MORE DETAILS.

A recent anti-recruiter rant posted to a news group and a subsequent commentary on HackerNews got me thinking about the many ways that tech recruiting and the relationship between recruiters and the tech community is broken. I saw a few comments referencing that the community always says how broken it is, but no one tries to fix it. Here are some ideas on how we got here and directions we can go.

Why is the recruiting industry the way it is?

  • The high demand and low supply for tech talent creates a very lucrative market for recruiters. Many technologists might not be aware of this, but successful recruiters probably all make over 100K (some earn much more) and as a commission-based business your compensation has no maximum.
  • Recruiting is an easy field to enter. No formal training is required, although you will need some sales training and tech knowledge to truly make an impact. One can easily start with a computer, a phone line, and a basic website.

So we have an industry that can be very lucrative (for some much more lucrative than the tech industry itself) with almost no barriers to entry. Of course an industry with these characteristics will draw both talented, ethical professionals as well as carpetbaggers and bottom-feeders just as the gold rush did.

What are the biggest complaints about recruiters (and how can we solve them)?

First, complaints from candidates (tech pros):

  • Too many cold calls.  POSSIBLE SOLUTION:  Without some widespread changes from all three parties (candidates, hiring firms, and recruiters) in the industry, this one is probably impossible to solve. Simply mentioning that you do not wish to hear from recruiters is no guarantee that they won’t contact you, but if I see on a LinkedIn page that someone specifically doesn’t want to hear from recruiters I won’t contact them as it is clear they do not value the services I provide.
  • Dishonesty about the job description or salary.  POSSIBLE SOLUTION:  What if companies gave recruiters some form of ‘verified job spec‘ to share with candidates? Salary range, job description, location, whatever else might be helpful. A candidate could request this from the recruiter before agreeing to an interview.
  • Being marketed/used without their knowledge.  POSSIBLE SOLUTION:  Companies could require a ‘right to represent‘ email giving a recruiter permission to submit his/her resume for any or all positions, which would at least eliminate some of this. Of course, recruiters will still send blinded resumes (contact info removed) to client prospects. A better idea may be for candidates to have a document that they ask recruiters to sign – a contract where the recruiter agrees not to send their resume in any form to any company without the express written consent (the ‘right to represent’) of the candidate. I’m not a lawyer, but I assume there could be some financial penalties/restitution allowed if you were to break that trust, as you may damage the candidate’s career. As a rule, if I want to market a candidate to a client, I always get their permission first.
  • No feedback or follow-up. POSSIBLE SOLUTION:  Unfortunately there is little value that a company gets by providing specific feedback about a candidate, and it actually exposes them to substantial risk (ageism, racism, etc.). Likewise, taking time to give rejected candidates details provides nothing to the recruiter except goodwill with the candidate. This one is difficult to solve, but probably not as big an issue as the other problems.

And complaints from hiring firms:

  • Too many resumes.  POSSIBLE SOLUTION:  If you provide a very good requirement to a good recruiter, he/she should be able and very willing to limit the resumes. Telling your recruiter that you want to see the best five available candidates should encourage them to limit submissions.
  • Unqualified candidates.  POSSIBLE SOLUTION: Same as above.
  • Misrepresenting a candidate’s background. POSSIBLE SOLUTION:  Well for starters, stop working with the recruiter and that agency entirely. If you want to make a positive change for the recruiting industry, contact the recruiter’s manager and tell your side of the story. Having liars in an industry is bad for everyone except the liars and those that profit off of them.
  • Marketing cold calls.  POSSIBLE SOLUTION:  If you truly will not use recruiters for your searches, list that on your job specifications both on your website and the jobs you post publicly. I would rather not waste my time if a company has a policy against using recruiters, and if your policy changes perhaps you will be calling me. I will not call a company that specifically lists that they do not want to hear from recruiters, as it is clear they do not value the service I provide.
  • Price gouging.  POSSIBLE SOLUTION:  This could be when recruiting agencies mark-up their candidates’ hourly rates well beyond what is a reasonable margin, or when recruiters who receive permanent placement fees tied to salary will stretch every penny from the hiring company. Flat transparent fees work very well for both of these problems (a flat hourly mark-up on contractors and a flat fee for permanent placements), although recruiters would particularly hate a flat fee structure for contractors. The recruiter’s ‘sale’ to a contractor is, “If I can get you $300/hr, do you care if I make $2/hr or $100/hr?“. The answer is usually ‘no’, which is all fine until the contractor finds out that you are billing your client $300/hr and only paying the him/her maybe $50/hr. That is rare, but that is when things get ugly. Flat and transparent rates exposed to all three parties involved will solve that problem, but don’t expect recruiters to go for it.

To all the technology pros who claim they really want to disrupt the industry, I have one simple question.

Would you be willing to hire, and pay for, an agent?

I’ve heard the argument from some engineers that they would like recruiters to care more about the engineer’s career and not treat them like a commodity. Recruiters are traditionally paid for by the hiring companies, but only if they can both find the proper talent and get that talent to take the job (contingency recruiting). This can lead to a recruiter treating candidates like some homogenized commodity that all have similar value.

If engineers want true representation of their best interests, having representation from a sole agent would be one obvious choice. As your agent, I could provide career advice at various times during the year, making suggestions on technologies that you may want to explore or giving inside information on which companies might have interest in you. You might come to me to discuss any thoughts on changing jobs, how to apply for promotion, or how to ask for a salary increase (which I could negotiate for you directly with your manager). When you do decide to explore new opportunities, the agent would help put together your resume, set a job search strategy, and possibly market your background to some hiring companies. As the agent is making his living by charging a fee to the candidates, the agent could charge a much smaller fee (or potentially even no fee) to the hiring company, which would make hiring you much less expensive than hiring through a traditional recruiter.

If you were contacted by a recruiter from an agency or a hiring company, you would simply refer them to me for the first discussions and I would share the information with you (if appropriate) at a convenient time. You could even list my name on your LinkedIn, GitHub, and Twitter accounts. “If you are interested in hiring me, contact Dave at Fecak.com” How good would that feel? How good would it feel to tell your friends that you have an agent?

All of this assumes your agent would have some high degree of knowledge about the industry, the players, market rates, and a host of other things. Many recruiters don’t have this expertise, but some certainly do. An agent could probably represent and manage the career of perhaps 50-100 candidates very comfortably and make a good living doing it.

Would you be willing to pay a percentage of your salary or a flat annual rate to an agent who provides you with these services?

If the answer is ‘yes’, look me up and I’d be happy to discuss it with you further. But I’m guessing for many the answer is ‘no’ (or ‘yes, depending on the price’).

My business model

Most recruiters are contingency based, which means they only get a fee if they make a placement.  If they search for months and don’t find a proper candidate, they just wasted months for no payment. This places 100% of the risk of a search on the recruiter and 100% of the control with the hiring company.  Even if the recruiter finds a great fit, the company can walk away without making a hire. Contingency recruiting is cut-throat and causes desperation to make a placement, and this is where most of the problems arise for candidates. This is the ‘numbers game’ that tech pros talk about, where the recruiter’s main incentive is to get resumes and bodies in front of clients and see what sticks.

Some recruiters are retained search, which means that basically all their fees are guaranteed up front regardless of their results. This is great for the recruiter but places 100% of the risk on the hiring company.  The recruiter is working this search to save his/her reputation, which is obviously very important in getting future searches. This is not cut-throat, because it is not a competitive industry – recruiters have exclusive deals with a retained client for that particular job.

The model I use combines contingency and retained search.  I charge clients a relatively small flat fee upfront to initiate the search, which is non-refundable. When a placement is made, I charge my clients another flat fee (not tied to salary). When you combine the two fees, the percentage of salary is often about half what contingency recruiters would get for the same placement.

So you think I’m an idiot for charging much less than my competition. Perhaps. I see it as creating a true partnership with companies that continue to come back with additional searches and repeat business, often referring me to their friends and partners. When a company gives you a fee upfront, they are putting their money where their mouth is and you can be sure they are serious about hiring. It takes some degree of trust on behalf of the hiring company, but once you have been in the business for a while the references are there and chances are we have some business connections in common.

So far this model has worked well, with happy clients and lots of repeat business. I have already met my goal for 2012, and I’m hoping to double it in the coming months.

What else do I do differently?

  • I give it away (sometimes) – information, resume and interview advice, and any other kind of help you can think of are requested of me, and I rarely refuse a reasonable request. If I can’t help you find a job, I can at least take a look at your resume or evaluate how your applications look. I have known some engineers for over ten years without ever having made .05 in fees, and have helped them make career decisions for free. I’ll often introduce candidates to  start-ups or one-man firms with limited budgets who may end up hiring without using my services, with the hopes that they will use me for future searches.
  • I run a users’ group – I’ve run the local Java Users’ Group for almost 13 years. It is a volunteer job with no compensation, but it helps me stay in touch with the tech community and it also adds some credibility to my name. It is a lot of effort at times, but the success of the group is something that I’m quite proud of. I don’t recruit out of the group, but most of the group are aware of my services and come to me for my services when necessary.
  • I specialize – Historically I focused both geographically and on one technology (Philadelphia Java market). I’ve opened that up a bit as many of those Java pros are now doing mobile, RoR, and alternative JVM lang work, and I’m a bit more regional now. Staying specialized in one geography and one technology forces a recruiter to be very careful about his/her reputation, as the degrees of Kevin Bacon are always low.
  • Flat fees – A flat fee lets the company know that my goal is to fill the position and how much you pay the candidate is irrelevant. I inform candidates of this relationship so they are aware that my goal is to get them an offer that they will accept, and my client companies know that if I say I need $5K more in salary to close the deal that I am not trying to line my pockets.

CONCLUSION
Don’t expect my model to be adopted by any other firms, but I wanted to share it with readers as at least one alternative to the traditional contingency model that seems to be the biggest complaint for both candidates and hiring firms.  And I believe the agent model would work quite nicely for all parties involved if anyone would like to inquire.  If you truly want to disrupt the industry, let’s talk.

TALK! It’s An Interview, Not An Interrogation

Several times a year I will get a call or email from a hiring manager telling me that an interview never really ‘went anywhere’ because the candidate seemed either unwilling or unable to dive very deep into technical topics.  It can be impossible for an interviewer to accurately gauge whether the cause was a lack of tech skills or just an inability to communicate those skills, but it really makes no difference as the end result is a rejection.  This observation is probably a bit more prevalent during phone screens, where the parties do not have the advantage of proximity and body language to assist.

Whenever I hear feedback like this from clients, I imagine what the interview may have sounded like:

INTERVIEWER:  Have you worked with Ruby on Rails before?
CANDIDATE:  Yes, I have.
INTERVIEWER:  Could you elaborate on that a little bit?
CANDIDATE:  Yes, I could.
INTERVIEWER:  (VISIBLY ANNOYED)

It brings to mind the old joke (which of course reinforces gender and programmer stereotypes):

A wife asks her computer programmer husband, “Go to the store and get a gallon of milk, and if they have eggs get a dozen.”  A short time later the programmer returns with twelve gallons of milk.  She asks, “Why did you get twelve gallons of milk?” and he responds, “They had eggs.”

In the short two question interview scenario above, the candidate is answering the questions being asked, and the candidate is providing all the information that was being requested.  If you look at the questions in a literal manner (as many engineers tend to do), this candidate may not feel he/she is being dodgy at all.  Just as the programmer in the joke did what his wife asked (by his literal interpretation).

Let’s now look at a brief example of a police interrogation:

INTERROGATOR:  Where were you on the night of the 8th?
SUSPECT:  At home.
INTERROGATOR:  Were you by yourself?
SUSPECT:  No
INTERROGATOR:  Who was with you?
SUSPECT:  My husband.
INTERROGATOR:  WHO WAS WITH YOU??!!
SUSPECT:  My lover!  (CUE SCARY MUSIC)

These answers provide the minimum amount of information the interrogator requested, and a lawyer will probably advise you to keep your answers short and precise during questioning.  The interrogator’s job is to get a suspect to say something that he/she does not want to reveal.

A job interview is not an interrogation, and it is important for candidates to be sure they are not treating it as such.

Keep in mind that interviews, particularly in technology settings, can be awkward situations for participants on both sides of the table.  Most interviewers are at least slightly uncomfortable being placed in a room with a complete stranger for the sole purpose of judging him/her in order to reach some conclusion about whether he/she should be hired, a decision which could greatly impact the life of at least one party (the candidate) or even both parties (if the hire is made).  If an interviewer gives even a small consideration that this stranger may have a family that depends on the income that the job would provide, the potential for an awkward exchange is even more likely.

Most interviewers want to get a dialogue flowing, where the discussion will allow them to evaluate your technical and interpersonal skills.  They want to control and moderate the conversation, but they would like to listen more than they speak.  The candidate’s ability to communicate his/her thoughts will be apparent after a few questions.  At some point most interviewers have to ask themselves, “Would I want to work next to this person every day for several years?”  If the candidate answered their questions in a fashion resembling the Candidate or the Suspect in the samples above, the answer is always “No”.

Some candidates may argue that they have answered the questions as asked, and that if the interviewer wanted more details he/she should have inquired for them specifically (“Tell me about Ruby on Rails experience.”).  This is a valid observation, but it doesn’t solve the problem.  It’s purely a function of conversational English, and it is one reason that chatbots with artificial intelligence may give answers like our Candidate did in the example.

So, I’ll just keep talking and talking to solve the problem?  NOPE.  There is also the possibility that if a candidate answers every question with a long-winded response, he/she may be rejected for not being able to provide succinct answers.  Managers are often unwilling to hire someone who they feel is unable to express themselves efficiently, and in the case of software engineers you may hear, “Being that chatty, I can’t imagine what his/her code (comments) looks like!‘

How do I appear to be open, honest, and transparent without sounding chatty?  How do you avoid being labeled as unable or unwilling to answer interview questions?

  • Don’t take every question literally – Remember that a good interviewer is trying to engage you in a dialogue and an exchange of ideas.
  • Pause before answering – Some candidates seem programmed to immediately start talking after a question is asked, and then find that they haven’t really answered the question.  Taking a moment to reflect on the question and to organize your thoughts gives the appearance that you are making an effort to supply a strong answer and that you are not impulsive.  A little white space does not have to be an uncomfortable silence.
  • Pause after answering –  If the interviewer does not respond with a follow-up after a few seconds, he/she may be waiting for you to go deeper.  Ask if he/she is satisfied with your answer and offer to continue with more information if necessary.  “Would you like some more details on that?“
  • Ask questions to clarify what type of answer is expected – If you are asked a question where there could be both an acceptable short answer (yes/no) or a longer answer (details), give the short response and offer the interviewer more.  “Yes, I have used Ruby on Rails.  Would you like me to discuss my experience further?“
  • At the end of the interview, ask the interviewer if they have any other questions that will help them make their decision. Invite them to contact you in the coming days if any additional information is required or if they would like any clarification on the answers you provided.

Go into the interview with the goal of having a conversation which should put the interviewer at ease.  Be willing to follow the interviewer into any direction the discussion may take, and ask questions so you know that you are on the same page.

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

How Hackers Choose Tools (thoughts on Paul Graham’s Java’s Cover)

Recently, a 2001 blog post with the title Java’s Cover written by Paul Graham (of Y Combinator fame) spread across Twitter and was linked by all the other usual tech site suspects.  The piece was about what Graham called ‘hacker’s radar‘, which he describes as the ability of hackers to ‘develop a nose for good (and bad) technology‘.  For his description of hacker’s radar, he decided to cite Java as an example of a technology that smelled bad at the time.  Java’s popularity in 2001 made it a pretty big target for critique.  The title Java’s Cover is a reference to judging a book by the cover, and Graham argued that Java’s cover was a stinker.

Graham admits in the article that he had never written Java and his main exposure was when he ‘glanced over reference books‘, though Graham does have substantial tech credibility as a hacker.  He lists 12 reasons why he didn’t like the look of Java, and mentions that he had a hunch that Java would not be a very ‘successful language‘ (but he ‘may turn out to be mistaken‘).

The commentary on the aforementioned usual suspect sites seems, predictably and unfortunately, to be centered on the accuracy (‘is Java truly successful?’) or inaccuracy (Java is everywhere) of the prediction itself.  I feel it is a much more interesting exercise to take the opportunity to go into the author’s opinions as representative of an advanced technologist, and to see what factors would lead a like-minded and influential technologist to potentially have the same negative reaction to a new tool/language based on relatively non-technical factors.  Every day we read articles that are highly critical of languages, frameworks, design patterns, and anything else you can imagine, and it can be difficult to tell how much experience the author may actually have (or even need) to make such assertions.  When an industry voice writes an opinion on a topic based on the factors listed by Graham, what weight is given to the conclusions by the community?  Graham’s article is somewhat unique in that he was willing to list the ‘smell’ reasons for his suspicion.

Looking at each reason Graham gave individually may give us some insight into how technologists yesterday and today may form opinions about a variety of topics, and whether or not we can use these tests to determine future success.

1. It has been so energetically hyped.

While it is certainly true that excessive hype can be a sign of any potential product’s weakness, that certainly isn’t always the case.  Graham mentions notes that ‘A real standard tends to be already established by the time most people hear about it’.  You will find that almost every technology that is highly criticized has been blessed/cursed with a fair amount of hype, either generated by marketing people with profit motive or evangelists that may have much smaller (or even zero) financial interests.  I’m not sure that hype alone should make technologists wary about a new offering, but people who are naturally skeptical will surely be wary of over-the-top hype efforts.

2. It’s aimed low.

This one seems to have some merit.  In this case Graham is saying that Java is intentionally dumbed down, and that ‘Java’s designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.‘

When people create a product/tool for other people to use, they obviously want their audience to be able to learn it, and Graham seems to argue that by ‘aiming low’ and focusing on ease of use you are probably placing unnecessary limitations on the product you are building.  If you were creating based solely on the need to solve specific problems, ease of use would not be as great a factor.

3. It has ulterior motives.

In this case Graham is speaking of Sun’s plan to ‘undermine‘ Microsoft.  We could certainly apply some tests of ulterior motives to several new developments in tech over the past several years, but I’d imagine it would be a difficult task to find similar motives in the overwhelming majority of new products.  This one is probably, in most cases, not applicable.

4. No one loves it.

Ouch!  Every language, every tool, is loved by someone.  Remember all those people in #1 above that make up the hype machine?  Perhaps by saying ‘I’ve never heard anyone say that they loved Java‘, Graham meant that that no one of any influence or importance loves it.  If a product is eschewed by the most widely respected folks in industry, that is a warning sign.  When some thought leaders begin to endorse tools they become viable for others to adopt (see alternative JVM programming language adoption by big firms today).  Some former Java evangelists professing a love for Scala comes to mind.

5. People are forced to use it.

Being told that you have to use a tool does not make it questionable, but in Graham’s brief description he infers that the anecdotal evidence includes smart people that would have used the tool voluntarily if it were good.  This is probably better said as ‘Outside forces with potentially differing objectives force technologists to use it against the techie’s own better judgement.’  It’s hard to argue with that.

6. It has too many cooks.

This one is quite interesting, especially with the changes that have occurred in the industry since 2001 and the emergence of open source as a dominant player in the market.  Graham went on to write that ‘the best programming languages have been developed by small groups. Java seems to be run by a committee. If it turns out to be a good language, it will be the first time in history that a committee has designed a good language.‘

Issues with the JCP over the years have been written about ad nauseam.  But what would Graham make of other open source developments over the years?  I imagine the rebuttal would be that only the highest level members of an open source project are truly the ‘cooks’ he refers to, with the rest of the members merely relegated to chopping and slicing.  Maybe not.  Being suspicious of multiple decision-makers pandering to multiple masters would be natural, and warranted.

7. It’s bureaucratic.

In this case Graham is referring to the language structure itself and not the leadership.  This can be perhaps lumped into #2 It’s aimed low although not in every instance.  If a language is ‘aimed low’, you might expect that the designers would try and limit the types of mistakes users could make (see #9 as well).

8. It’s pseudo-hip.

Interesting perspective.  I’d argue it was hip.  Graham continued, ‘Sun now pretends that Java is a grassroots, open-source language effort like Perl or Python. This one just happens to be controlled by a giant company. So the language is likely to have the same drab clunkiness as anything else that comes out of a big company.‘

I couldn’t help but notice the words Graham uses to critique Java in 2001 are very similar to how Democrats paint the modern day Tea Party (an observation on the language, not a political statement).  The real meat of this criticism seems to be that the product is controlled by a large organization, which per Graham would by default make it ‘clunky’, but posing as a much more community-friendly and open option.  I’m guessing this element of Graham’s opinion would have been amplified dramatically after the Oracle acquisition.  Would hackers feel differently if a big company tool wore the corporate badge proudly?

9. It’s designed for large organizations.

Graham specifies that Java was designed to limit large teams of mediocre programmers from causing damage.  This seems very much like reasons #2 It’s aimed low and #7 It’s bureaucratic above.  This is probably more accurately categorized as ‘designed for mediocre programmers‘.  I would assume that any advanced technologist would probably be less interested in a tool that seems to be created for a lesser engineer.  Graham wants only languages for big boys and girls, and most advanced and even intermediate hackers would probably agree.

10. The wrong people like it.

Graham lists the wrong people as ‘suits’ tuned into the hype from #1, big company programmers from #9, and college kids looking to get a job.  He feels that all three of these groups change their minds regularly.  I’d say the college kids of 2012 appear to be interested in newer technologies (Ruby, Python, functional programming, mobile) that are probably not the core of their curriculum (Java), and in 2001 they were also interested in newer technologies (Java) that were also not the focus of their education (C/C++).  Does the interest of college grads in Ruby and Python make those tools the wrong tools, or do today’s college grads have a bit more of a sophisticated hacker palate?  What do the suits and big company programmers love today?  Tools with ample talent supply, maybe?

11. Its daddy is in a pinch.

Java’s OLD daddy was, but Java’s new daddy buys islands!  But this isn’t about Java.  The financial standing of the steward of a language or product is certainly a valid consideration to make when evaluating the future viability regarding use in developing a product.  But who would be deemed the daddy of open source tools?  Individual project owners perhaps?  The vendor ecosystem that supports them?  The landscape has changed enough since 2001 that this criticism might be less of a factor now.

12. The DoD likes it.

Guilt by association, and Graham calls DoD culture the ‘opposite‘ of hacker culture.  In some recent discussions about Java and alternative JVM languages, I’ve seen this discrimination used in reverse, where Java supporters claim that the use of the alternative JVM languages by start-ups is a strike against using the alternative options.  The argument is that start-ups are all run by kids and cowboys, so any choices they make can’t be grounded in solid technical judgment.  Interesting how two groups, who both probably feel they are above-average technologists, can come up with opposite interpretations.

CONCLUSION

If you made it to the very bottom of Graham’s post, there is a link to an article called Trevor Re: Java’s Cover, which refers to comments by Trevor Blackwell (also a YC partner) about the post.  Blackwell classifies programmers as either ‘brilliant hackers‘ or ‘corporate drones‘ with most tools being written for the drones, so hackers need to know the smell tests to decipher quickly which tools are meant for the hacker and which were designed for the drones.  Of course, very few of the people Blackwell calls drones probably feel they are in that camp, which just complicates the issues even more.

I feel that Graham’s article is interesting as a time capsule to compare how hackers thought about new tools in 2001 and how they may come to conclusions about languages today.  As an investor, I’m sure some of the same smell tests Graham listed would apply to how he evaluates start-ups for potential funding.  Whether Graham was right or wrong about Java doesn’t matter at all, but getting a glimpse into his thought process then is quite valuable.

How would the current batch of popular and emerging technologies fair today, using Graham’s microscope?

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

Overqualified is Overdiagnosed

I’ve been inspired by comments on prior articles to discuss the sensitive topics of ‘overqualification’ and ageism. My Why You Didn’t Get The Job and Why You Didn’t Get The Interview posts were republished on a few sites, resulting in some active debates where at some point a participant states that the real reason that they weren’t hired was that they are overqualified for all the jobs out there, or they were victims of ageism. In my opinion and experience recruiting in the software engineering world, the term overqualified is used too widely by companies (and then inaccurately cited by rejected candidates), and  claims of alleged ageism are often something else entirely.

Before we begin, I acknowledge that companies want to hire cheaper labor when possible, and some shops care less about quality products than others. And for the record, I’m over 40.

By saying you are overqualified for jobs, what are you really saying? “I am more skilled or more experienced than the job requires.” That feels kind of good, doesn’t it?

SPOUSE:  How did the interview go?
JOB SEEKER:  I didn’t get the job.
SPOUSE 1:  Oh, I’m sorry.  What happened?
JOB SEEKER:  Unfortunately, it turns out my skills are simply too strong.

Of course rejection hurts, but to tell your spouse (and yourself) that you were turned down because you were too skilled or too experienced is much less bruising on the ego than the alternative. For companies looking to eliminate candidates, using the word overqualified may take some of the sting and fear of retribution out of the rejection. But is it true?

Think about this scenario for a second.  You are trying to hire a software developer and you estimate that someone with say five years of experience should be able to handle the duties effectively. A candidate is presented with fifteen years of experience that has all the attributes you are seeking. This person should theoretically perform the tasks quicker and even take on some additional workload. Do you really think a company would not hire this person simply because he/she has those additional years of experience? I would argue that is rarely the case.

Question:  Is ‘overqualified’ a code word used by managers/HR to mean other things?
Answer:  ALMOST ALWAYS

What can overqualified actually mean?

(listed in order from most likely to least likely, IMO)

  • Overpaid/over budget – If your experience > what is required, it generally becomes a problem when your salary requirements are above what is budgeted. It’s not that you are classified as overpaid in your current role, but that you would be overpaid for the level of responsibility at the new job. I list this as the most likely culprit because I often see companies initially reject a candidate as overqualified, then hire that same person because of a lack of less experienced quality talent.
  • Stagnant – Candidates who have worked for many years as a developer in a technically stagnant and regulated environment will often not thrive in less regulated, more technically diverse firms. The conventional wisdom, right or wrong, is that you can’t release the zoo lions back into the jungle once they’ve been tamed.
  • ‘Overskilled’ – If your skills > what is necessary for the job, an employer may fear that the lack of challenges provided will bore you into looking for more interesting work in the future. Hiring a tech lead to do bug fixes could lead to a short stint. There is emerging evidence that shows skilled workers do not exit less challenging jobs quickly or in high numbers, but hiring managers are not quite ready to abandon the traditional line of thinking.
  • Threatening – If your experience > those conducting the interviews, there could be some fear that you could be a competitor for future opportunities for promotion. If a start-up is yet to hire a CTO, the highest geek on that firm’s food chain may be jockeying for the role. This may sound a bit like a paranoid conspiracy theory, but I genuinely believe it is prevalent enough to mention.
  • Too old – Ageism is a real problem, but in my experience in the software world, ageism is also widely overdiagnosed by candidates who think the problem is their age when in actuality it is their work history. Most of the self-diagnosed claims of ageism that I hear are from candidates who spent perhaps 20+ years working for the same company and have not focused on keeping their skills up to date (see stagnant above). I can’t say that I’ve ever heard a claim of ageism from a candidate that has moved around in their career and stayed current with technology. The problem often isn’t age, it is relevance.

Some of the best and most accomplished/successful software engineering professionals that I know are over 50, which is older than some of the candidates I hear claiming possible ageism. One trait that the overwhelming majority of these engineers have in common is that they didn’t stay in any one place for too long to stagnate. I don’t think that is a coincidence.

If you are an active job seeker that is continuously hearing that you are overqualified, what can you do to improve your standing?

  1. Rethink – Try to investigate which of the meanings of overqualified you are hearing most often. Is your compensation in line with what companies are paying for your set of qualifications? Do you present yourself in interviews as someone who may become easily bored when your work is less challenging? Are you making it clear in interviews that you want the job, and you explain why you want the job?
  2. Retool – Make sure your skills are relevant and being sought by companies. Invest time to learn an emerging technology or developing some niche specialty that isn’t already flooded.
  3. Remarket – Write down the top reasons you think a company should hire you, and then check to see if those reasons are represented in your job search materials (resume, email application, cover letters). Find out what was effective for your peers in their job search and try to implement new self-promotion tactics.
  4. Reboot and refresh – Take a new look at your options beyond the traditional career paths. Have you considered consulting or contracting roles where your guidance and mentoring skills could be justified and valued for temporary periods? Are there emerging markets that interest you?

Terms like ‘overqualified’ and ‘not a fit’ are unfortunately the laziest, easiest, and safest ways that companies can reject you for a position, and they almost always mean something else. Discovering the real reason you were passed up is necessary to make the proper adjustments so you can get less rejections and more offers.

Blind Dating for Geeks: Questions Candidates Should Ask (and when to ask them) During Interviews

After a few ‘Questions Candidates Ask In Interviews’ themed articles appeared in my Twitter stream, I was reminded of an article I wrote two years ago called ‘Best Questions To Ask The Interviewer, And When To Ask Them‘.  I think one key element missing in the new articles is the ‘when to ask them’ detail that I feel is incredibly important.  Also, being that JobTipsForGeeks is aimed at technology professionals, there are some nuances that do not apply to other industries.

Why is the timing of when the questions are asked important?  An interview is nothing more than a blind date, with the goal on both sides being to find out if you want to start seeing each other in a somewhat committed fashion.  You want to discover as much as you can about the other party, but first you have to set a positive tone and build trust. We surely would want to find out if our blind date is, say, a serial killer – but leading off with the ‘Are you a serial killer?’ question would seem rude, and we probably wouldn’t get an honest answer anyway.

Below is a list of the best questions to ask in chronological order.  Please keep in mind that you would need to restart from the beginning for every new person that you meet in situations where you meet with multiple participants individually.  You may not be afforded the opportunity to ask all the questions based on time constraints, so use at least one question from the first section for each person and try to use all the questions at least once at some point in the process.

Setting a positive interview tone
OR
Cocktails and light conversation

Question: “What is your background and how did you come to work for COMPANY?”
Reason to ask it:  Most people genuinely like to talk about themselves (those that do not share this trait will probably not be in the interview), so give them a chance to do so. Don’t be afraid to toss in some remarks and perhaps a follow-up question regarding their background if appropriate.  You may learn that you have some shared history with this person that could give you a potential ‘in’.

Question: “What do you like best about your job and about working for COMPANY?”
Reason to ask it: This question serves two purposes. First, it gives the employee the opportunity to speak well of the company, which again will give an initial positive vibe to your dialogue. Secondly, what the employee chooses to say they like best can be quite telling. If their answer is ‘environment’, ‘work/life balance’ or ‘the people’, that is a universal positive. If the response is ‘the money’ or ‘vacation time’, you may want to dig deeper to find out why.

BONUS Question:  (If possible, find a fairly recent newsworthy item about the company that is both appropriate and positive, and ask an insightful question about it)
Reason to ask it:  This shows that you have done your homework before the interview and that you want to be taken seriously as a candidate.  This is something that you want to fully research to prevent making a huge mistake that would make recovery impossible.

Discovery
OR
Gentle interrogation of your date during dinner

Question: What are the biggest challenges you face?
Reason to ask it: The reason for using the word ‘challenges’ is that it does not have a negative connotation, whereas asking someone for the ‘worst’ element of their job will not give a positive impression.  The answer here will start to create an image of what this company is going through today and what the landscape is for tomorrow.  At a start-up, you may hear answers about financial challenges, limited resources and a fast pace.  Some industries are known for heavy regulation getting in the way of progress.  This is all valuable information.

Question: What would the typical day be like for me at COMPANY?
Reason to ask it: You may get an answer that gives you tangible insight into work/life balance (‘I usually get home in time to watch Jimmy Fallon’), how much of your day may be spent coding or doing other duties, how many meetings you may be pulled into, etc.

Question: What was your career path here and what is a typical career path for my role at COMPANY?
Reason to ask it: Find out if they promote from within and if there are separate technical and non-technical/pure management tracks.  Will you be forced into a management role?

Question: How would you describe the environment?
Reason to ask it:  Asking an open-ended question like this could lead in several directions.  You should be able to ascertain if it is cut-throat or cooperative, how much support is given to technologists, and whether you will be expected to work with teams or as a solo entity.

Question: Management styles? Development processes and methodologies in place?
Reason to ask it:  Engineers preferences for structure vary greatly.  Be sure to drill down to get the best understanding of whether their practices are aligned with your views.

Question: Tech stack?
Reason to ask it: If their answer is a list of products and technologies that are severely dated, it could mean the company doesn’t invest in or even investigate the latest and greatest.  Conversely, if they seem overly concerned with bleeding-edge, perhaps they are making tech decisions based on cool factor more than quality.  Be sure to listen for what can be telling patterns, such as an abundance of tools from a particular vendor or a wide variety of open source tools.  This question also gives you an opening to discuss your experience (and preferences) relevant to their stack.

Question: Why is this position open?
Reason to ask it: Growth or promotion are the two most desirable answers. Perhaps this position is a launching board into higher level positions, or maybe it is a dead-end that will burn you out.

Closing the deal
OR
Last call and the drive home…

Question: What qualities/background do you think would be key to making someone successful in this position?
Reason to ask it: During that last set of questions, some negative topics could have surfaced.  This gets things back on the positive side before the end, as well as giving you more info on whether you would be hitting the ground running or may require some learning curve. (NOTE: This question could also be used as an ice breaker early on)

Question: What projects are just getting ramped up or are on the horizon?
Reason to ask it: Interviewers will enjoy discussing new endeavors that they think you will find most interesting. If they talk about fixing bugs and maintenance, chances are that is what you will be doing in this job for the foreseeable future.  Ideally, the interviewer’s excitement should be palpable.

Question: Where do you see yourself in five years here at COMPANY?
Reason to ask it: This question is generally asked of candidates, so turning that around should provide insight into how he/she really feels about the firm and their prospects. Again, it lets the interviewer talk about himself/herself again in a positive fashion, and if the interviewer has a sense of humor expect an attempt to use it on this question.

The Conclusion
OR
Goodnight

Question:  Is there anything else I can answer for you or any more information I can provide to help you in your decision?
Reason to ask it:  It shows you are forthcoming and trying to be helpful.

Question:  I am very interested in this opportunity (or similar sentiment).  When do you expect COMPANY might be making a decision?
Reason to ask it:  Showing interest is vital, and asking about their timing could lead to information on other candidates.  It also may prompt them to ask about your availability to start, which is an obvious buying sign.  You want to do this is with as little pressure as possible.

Close by thanking the interviewer for taking the time to speak with you and tell him/her that you look forward to the next steps.  Good luck.

Why You Didn’t Get the Interview

After reading the tremendous response to Why You Didn’t Get the Job (a sincere thanks to those that read and shared the post) I realized that many of the reasons referenced were specific to mistakes candidates make during interviews. At least a handful of readers told me that they didn’t get the job because they didn’t even get the interview.

With a down economy, most of us have heard accounts of a job seeker sending out 100, 200, perhaps 300 résumés without getting even one response. These anecdotes are often received by sympathetic ears who commiserate and then share their personal stories of a failed job search. To anyone who has sent out large quantities of résumés without any response or interviews, I offer this advice:

The complete lack of response is not due to the economy.  The lack of response is based on your résumé, your experience, or your résumé submission itself.

My intent here is to help and certainly not to offend, so if you are one of these people that has had a hard time finding new work, please view this as free advice mixed with a touch of tough love. I have read far too many comments lately from struggling job seekers casting blame for their lack of success in the search (“it wasn’t a real job posting”, “the manager wasn’t a good judge of talent“, etc.), but now it’s time to take a look inward on how you can maximize your success. I spoke to a person recently who had sent out over 100 résumés without getting more than two interviews, and I quickly discovered that the reasons for the failure were quite obvious to the trained eye (mine). The economy isn’t great, but there are candidates being interviewed for the jobs you are applying for (most of them anyway), and it’s time to figure out why that interview isn’t being given to you.

If you apply for a job and don’t receive a response, there are only a few possibilities as to why that are within our control (please note the emphasis before commenting). Generally the problem is

  1. a mistake made during the résumé submission itself,
  2. problems with the résumé, or
  3. your experience

Qualified candidates that pay attention to these tips will see better results from their search efforts.

Your Résumé Submission

Résumés to jobs@blackholeofdeath – The problem here isn’t that your résumé or application was flawed, it’s just that nobody has read it. Sending to hr@ or jobs@ addresses is never ideal, and your résumé may be funneled to a scoring system that scans it for certain buzzwords and rates it based on the absence, presence and frequency of these words.  HRbot apocalypse…
Solution – Do some research to see if you know anyone who works/worked at the company, even a friend of a friend, to submit the résumé. Protip:  Chances are the internal employee may even get a referral bonus. LinkedIn is a valuable tool for this. Working with an agency recruiter will also help here, as recruiters are typically sending your information directly to internal HR or hiring managers.

Follow instructions – If the job posting asks that you send a cover letter, résumé, and salary requirements, this request serves two purposes. First and most obviously, they actually want to see how well you write (cover letter), your experience (résumé), and the price tag (salary requirements). Second, they want to see if you are able and willing to follow instructions.  Perhaps that is why the ad requested the documents in a specific format? Some companies are now consciously making the application process even a bit more complicated, which serves as both a test of your attention to detail and to gauge whether applicants are interested enough to take an extra step. Making it more difficult for candidates to apply should yield a qualified and engaged candidate pool, which is the desired result.
Solution – Carefully read what the manager/recruiter is seeking and be sure to follow the directions exactly. Have a friend review your application before hitting send.

Spelling and grammar – Spelling errors are inexcusable on a résumé today. Grammar is given much more leeway, but frequent grammatical errors are a killer.
Solution – Have a friend or colleague read it for you, as it is much more difficult to edit your own material (trust me).

Price tag – As you would expect, if you provide a salary requirement that is well above the listed (or unlisted) range, you will not get a response. Conversely and counterintuitively, if you provide a salary requirement that is well below the range, you will also not get a response. Huh?

Suppose you want to hire someone to put in a new kitchen, and you get three estimates. The first is 25K, the second is 20K, and the third is 2K. Which one are you going to choose?  It’s hard to tell, but I’m pretty sure you aren’t going to use the one that quoted you 2K. Companies want to hire candidates that are aware of market value and priced accordingly, and anyone asking for amounts well above market will not get any attention.
Solution – Research the going rate for the job and be sure to manage your expectations based on market conditions.  Another strategy is trying to delay providing salary information until mutual interest is established. If the company falls in love, the compensation expectation might hurt less. There is some risk of wasting time in interviews if you do not provide information early in the process, and most companies today will require the information before agreeing to an interview.

Canned application – By ‘canned’ I am referring to job seekers that are obviously cutting and pasting content from previous cover letters instead of taking the time to try and personalize the content.
Solution – Go to the hiring firm’s website and find something specific and unique that makes you want to work for that company. Include that information in your submission.  If you are using a template and just filling in the blanks (“I read your job posting on _____ and I am really excited to learn that your company _____ is hiring a ______”), delete the template now. If you aren’t willing to invest even a few minutes into the application process, why should the company invest any time learning about you?

Too eager – If I receive a résumé submission for a job posting and then get a second email from that candidate within 24 hours asking about the submission, I can be fairly sure that this is an omen. If I get a call on my mobile immediately after receiving the application ‘just to make sure it came through‘, you might as well just have the Psycho music playing in the background. Even if this candidate is qualified, there will probably be lots of hand-holding and coaching required to get this person hired. Reasonably qualified candidates with realistic expectations and an understanding of business acumen don’t make this mistake.
Solution – Have patience while waiting for a response to your résumé, and be sure to give someone at least a couple/few days to respond. If you are clearly qualified for a position, you will get a reply when your résumé hits the right desk. Pestering or questioning the ability of those that are processing your application is a guarantee that you will not be called in.

Your Résumé

Your objective – If your objective states “Seeking a position as a Python developer in a stable corporate environment“, don’t expect a callback from the start-up company looking for a Ruby developer. This applies even if you are qualified for the job! Why doesn’t the company want to talk to you if you are qualified? Because you clearly stated that you wanted to do something else. If you put in writing that you are seeking a specific job, that information must closely resemble the job to which you are applying.
Solution – You may choose to have multiple copies of your résumé with multiple objectives, so you can customize the résumé to the job (just be sure to remember which one you used so you bring the correct résumé to the interview). As there may be a range of positions you are both qualified and willing to take, using a ‘Profile’ section that summarizes your skills instead of an ‘Objective’ is a safer alternative.

Spelling and grammar (again) – see above

tl;dr – To any non-geek readers, this means ‘too long; didn’t read‘. To my geek readers, many of you are guilty of this. I’ve written about this over and over again, but I still get seven page résumés from candidates. I have witnessed hiring managers respond to long-winded résumés with such gems as ‘if her résumé is this long, imagine how verbose her code will be‘. (Even for non-Java candidates!  #rimshot) Hiring managers for jobs that require writing skills or even verbal communication can be extremely critical of tl;dr résumés.
Solution – Keep it to two or three pages maximum. If you can’t handle that, get professional help.

Buzzword bingo – This is a term that industry insiders use to refer to résumés that include a laundry list of acronyms and buzzwords. The goal is to either catch the eye of an automated search robot (or human) designed to rate résumés based on certain words, or to insinuate that the candidate actually has all the listed skills. Software engineers are probably more guilty of this than other professionals, as the inclusion of one particular skill can sometimes make the difference between your document being viewed by an actual human or not. When candidates list far too many skills buzzwords than would be reasonably possible for one person to actually know, you can be sure the recruiter or manager will pass based on credibility concerns.
Solution – I advise candidates to limit the buzzwords on your résumé to technologies, tools, or concepts that you could discuss in an intelligent conversation. If you would not be comfortable answering questions about it in an interview, leave it off.

Your Experience

Gaping holes – If you have had one or more extended period of unemployment, hiring managers and recruiters may simply decide to pass on you instead of asking about the reasons why. Perhaps you took a sabbatical, went back to school full-time, or left on maternity leave. Don’t assume that managers are going to play detective and figure out that the years associated with your Master’s degree correspond to the two year gap in employment.
Solution – Explain and justify any periods of unemployment on your résumé with as much clarity as possible without going into too many personal details. Mentioning family leave is appropriate, but providing the medical diagnosis of your sick relative is not.

Job hopping – Some managers are very wary of candidates that have multiple employers over short periods of time. In the software world it tends to be common to make moves a bit more frequently than in some other professions, but there comes a point where it’s one move too many and you may be viewed as a job hopper. The fear of hiring a job hopper has several roots.  A manager may feel you are a low performer, a mercenary that always goes to the highest bidder, or that you may get bored after a short time and seek a new challenge. Companies are unwilling to invest in hires that appear to be temporary.
Solution – If the moves were the result of mergers, acquisitions, layoffs, or a change in company direction, be sure to note these conditions somewhere in the résumé. Never use what could be viewed as potential derogatory information in the explanation. Clearly list if certain jobs were project/contract.

Listed experience is irrelevant/unrelated – This could be a symptom of simply being unqualified for the position, or it could be tied to an inability to detail what you actually do that is relevant to the listed job requirements. I would suspect that most of the aforementioned people (that received no responses to 100 submission) probably fall into the unqualified category, as job seekers tend to feel overconfident about being a fit for a wider range of positions than is realistic. Companies expect a very close fit during a buyer’s market, and are willing to open up their hiring standards a bit when the playing field starts to level.
Solution – Be sure to elaborate on all elements of your job that closely resemble the responsibilities listed in the posting.  Instead of wasting time filling out applications for jobs that are clearly well out of reach, spend that time researching jobs that are a better match for you.

You are overqualified – The term ‘overqualified’ seems to be overused by rejected applicants today, as there is no real stigma to the term. It’s entirely comfortable for a candidate to say/think “I didn’t get the job because I possess more skills at a higher level than the employer was seeking“. When a company is seeking an intermediate level engineer, it isn’t always because they want someone earlier in their career than a senior level engineer (although in some cases this could be true). Rather, they want the intermediate level engineer because that is what their budget dictates or they expect that senior engineers would not be challenged by the role (and therefore would leave). There are also situations where companies will not want to hire you because your experience is indicative that you will only be taking this job until something better comes along. A CEO applying for a job as a toll collector will not be taken seriously.
Solution – Be sure that your résumé accurately represents your level of skill and experience. Inflating your credentials or job titles will always work against you.

Conclusion

The time you spend on your job search is valuable, so be sure to use it wisely. Invest additional effort on applications for jobs that you feel are a great fit, and go above and beyond to be sure your submission gets attention. As a general rule of thumb, you want to be sure that whoever receives your résumé will get it into the hands of someone who has a similar job to the one you want, not just someone trained to look for buzzwords. Employees that have similar experience will be the best judges of your fit. If you aren’t getting the response you want, do not keep using the same methods and expecting a different result.

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

Advice From A JUG Leader II – Debate Breakdown

It’s been a week since I posted “Advice From A JUG Leader – Learn a Different Language” and it seems to have ruffled at least a few feathers in the Java community. As the article has been re-posted and bounced around on Twitter, I have had some opportunity to interact with some members of the Java community who have strong feelings about the content. None have called for my death, and the debate has been almost entirely polite thus far.

I think and sincerely hope that the Java community understands that the impetus for writing this article was an observation that many in the Java community are simply not aware of the trends in the industry, and by the time those trends become standards it is too late. These are the people that, if the train does come, never heard it approaching. My purpose is not to predict or encourage the demise of Java, as that should not and will not happen. The Java community is deeply loyal to Java, perhaps even to a fault, and I hope these articles serve as a wake-up call that the most important loyalty should be to your career as a software professional and to neither an employer or language.

I have noticed from these mini-debates is that defenders of Java, at least in my interactions so far, seem to primarily be highly experienced developers that perhaps have the most invested in Java. As I mentioned in my original article, I don’t expect known Java experts to feel any changes. At least a few of the comments seem to come off as rants against youth (“go play your Xbox“?) and startup culture and not a defense of the language’s health itself. I haven’t seen the younger generation of Java pros, but I know they are out there. I don’t seem to see Java enthusiasts attacking faults in the alternative languages or praising Java for a superior feature set.

Some comments seem to admit that Java has some shortcomings just like other languages, but it’s what we have for now. That is good enough for some people – particularly those that have been in Java for a long time – but not good enough for many developers who want to work with the best available. The arguments so far have been, in no particular order:

Argument #1 – Don’t Use Alternative Languages Because The Languages are Unproven, and/or Only Startups Use Alternative Languages

“And, don’t forget, 70% of startups will fail within the first ten years. So, I’m not inclined to base my decisions on the faulty and unproven ability of start-ups to make sound business decisions for themselves.” – Comment from TSS reader, click for full context

Some of the languages are more proven than others obviously, but we can’t ignore the fairly regular news regarding established firms transitioning to alternative languages and platforms or taking a polyglot approach. I would hardly call companies like Twitter, YouTube, foursquare, LinkedIn and Google immature startups at this point. If you are going to argue that there are plenty of other shops that use Java, we all know that. The point is some startups (those most apt to use these alternative languages) have made bad decisions (as have large firms), but to call the languages themselves ‘unproven’ at this point would not be accurate. No guilt by association here.

Businesses don’t make decisions, people do. I don’t think we should fall into the trap of lumping together the decisions made inside of some startups as any proof of language relevance at this point. When a host of startups fail due to their language choice alone, that conversation can be had.

If you were around back in the late nineties there were a lot of technology startups with funny sounding dot-com names. Many of these companies were using a three or four year-old programming language called Java. They could not have predicted that Java would grow to be as popular as it is today.

Note:  Python is older and Ruby is about the same age as Java, Scala has been around for 9 years, Clojure for 5 years.

Argument #2 – If You’re Bored With Java, That Is No Reason To Branch Out

“Becoming “bored or frustrated with Java” is a pretty poor excuse for branching out. As a professional, I’m not paid to feel entertained and broadened in my horizons. I’m paid to get things done as efficiently and as well as I possibly can… Go home and play your Xbox to relieve boredom. Don’t make your employer pay for yet another language learning curve so that you feel less bored and frustrated.” – Comment from TSS reader, click for full context

Simply being bored with Java could be enough for someone to look for other alternatives. I think the bigger issue is that technologists who pay attention to developments in other languages are envious of the features that other languages provide. Today, I feel that a smaller percentage of the Java community explore alternative languages based either on less curiosity or less opportunity. As the Java community at large is exposed to these other languages more and more, I would expect you will see many more defectors. The early adopters of Java were the most curious C++ or C developers who were looking for something different and stumbled on Java, and the most curious of Java pros stumbled on these other languages over the past few years.

Argument #3 – The Assumption That Most or All Of These Alternative Languages Will Be Dead In 5-10 Years

“If I’m off learning optional languages, I’m falling short of what I get paid to do. What’s more, I may have decided to do some development in one of the latest and greatest languages that, in a few years, will fall by the wayside, and now I’ve left my employer with a bunch of projects that will have to be re-written into a language that is currently active and supported.” – Comment from TSS reader, click for full context

Many of the early adopters of Java, as I mentioned in my article, have already been exploring some of these alternative languages for some time now. Often they were not initially paid to do so.  Could some of these languages be dead in 5-10 years? Sure. Most of the languages I’m thinking of when I talk about alternative languages are already 5 years old, and some much older. Even the young Ruby/Rails combo has been around for over 5 years.

Did people make the same assumption about Java back in the late nineties?

Argument #4 – Look At The Evidence That These Alternative Languages Are Not Being Adopted/Used/Sought After

Some defenders of Java have been pointing me to various statistics as proof that these alternative languages are not being used, not being sought after by employers, or not being adopted. I would cede that none of the current crop are even close to Java in terms of popularity today. I was sent to this link from Networkworld.com that says Java developers are the “most difficult tech pros to land, followed by mobile developers“. I wonder where the demand for mobile developers was three years ago? Would mobile development be a valuable skill to learn at this point?

As a recruiter, I’m also having a bit of a harder time finding Java developers now. One of the main reasons for that is pretty simple – a lot of the people that I know that used to do Java work aren’t interested in doing Java work any more. Over the years I’ve met a fair amount of experienced Java developers that were dying to get a job doing mobile work, Ruby work, Scala work, etc., but I’m not finding too many Ruby or Scala programmers with five years out of school looking for their first Java job. Maybe it’s just me, but I don’t see that…ever.

Another link was given to the Tiobe Index, which is pretty widely used to highlight trends of language popularity. It is based on search engine hits.  All indexes like this have some obvious flaws. If you read Tiobe’s Definition, the phrase “Java programming is dead” will actually improve Java’s position in the rankings. So absorb these ratings with that in mind.  They measure chatter, which could be positive or negative.

Tiobe Index July 12

Tiobe Programming Community Index for July 2012

Well, the takeaway from this graphic, for me anyway, would be that Java dropped significantly and Objective-C seems to be gaining popularity dramatically. But this could be some anomaly in a given month.

Tiobe Long Term Trend

Tiobe PCI 10 Year Trend

“Java has slid only recently and barely while the much touted JVM languages aren’t even on the radar” – Comment from Dzone.com reader, click for full context

The green line that is Java seems to be trending downward on a fairly regular basis since ’02.  I’m not sure I’d refer to a 10 year decline as ‘recent’ in the technology industry. Again, I don’t think the Tiobe index is the ultimate indicator, but I wouldn’t point someone to this statistic to support an argument that Java is healthy.

Objective-C wasn’t listed in 1997, was ranked #46 in 2007, and now stands at #3 on the index. If you had picked up Objective-C a few years ago, say in ’07 when it was not entirely popular, you would probably be doing well today as the demand for iOS work is quite high and the supply of developers is quite low. In ’97, Java was #5 – one spot behind VB and two spots behind COBOL.

Conclusion

The arguments against learning a new language or using a new language in production were probably the same back in the late nineties when Java was still new. People surely came to the defense of C and C++ saying that we didn’t need a new language then. It’s progress and subsequent resistance to change, and in the technology industry change can sneak up on you pretty quickly if you aren’t paying attention.

I feel that many in the Java community may not be paying close attention. 

If you were a C++ programmer messing around with applets back in ’96, you’ve already been through this transition once. What I’m hearing now from experienced folks is that these alternative languages are for start-ups, “Trix are for kids!“. I know quite a few gray haired former Java developers that are getting paid to write code in other languages now, and I think they would tell you that the alternative language market isn’t just for kids. Were you using Java in a start-up back in the day – were you one of the kids?

My purpose in writing these posts is to make a certain element of the Java community aware of what is out there, and that in my opinion now is an opportune time based on external market forces to explore other languages. This is not an attack on Java as a language or on the people that choose to write in Java. I’ve dedicated much of the past 12 years to the Java community and I don’t intend to change that now. I expect that I will be involved with Java professionals for several years, helping them to find jobs and scheduling great events for my JUG. I chose to change the focus of my business beyond Java, and my suggestion to Java professionals would be to at least consider and research doing the same.