Hire talent, not five years with Java

Too often we see job requirements for development positions with a long series of bullet points:

  • General Tech X everyone has heard about, 5 years
  • Specific Tech Y that came out last year, 3 years
  • Specific Framework Z that few people use and only takes 5 days to learn, 5 years
  • General thing you were taught in college, 10 years

I can understand this practice from a recruiter’s or HR’s point of view. It is difficult to gauge the skill level of something you have no clue about and you want to filter out as much candidates as possible before having them for an interview. But I do not feel the practice is worthwhile, it’s just lazy.

The skills dilemma

First of all, a specific number of years does not imply skill. You could have written Java code for dead-simple CRUD programs for 5 years, not knowing 50% of what the average Java developer knows and still qualify.

The following phrase I encountered on Programmers StackExchange sums it up nicely:

five times one year of experience

Some people for various reasons will have matured in 5 years, others will have repeated the same experiences and be no farther after five years then they were after one.

Second, what does it mean when a candidate says he has 5 years of experience with said tech? Did he intensely use it for 5 years or did he first start using it five years ago? Is he even still using it? If he lists C#, ASP.Net and JavaScript for 5 years all for the the same job, did he do all equally or did he just do some light JS from time to time to complement his ASP.Net pages?

Finally, while general experience will teach a developer invaluable lessons, prolonged experience with a specific technology will net diminishing returns after a few years. As more and more features are added to a framework or language, experiences gained five or more years ago will have been with a product that was very different from what it is now. Thus some of these experiences might not even apply today.

The “we feel we need someone yesterday” mentality

What baffles me most is when I see this hard “requirement of experience with certain technologies” coming from someone amongst the more tech inclined crowd.

Hiring talent will be better in the long run. A talented individual will learn the tech faster than an average developer anyway, and when he does, he will be doing a better job. Some common reply to this is: “we need someone to be productive right now”.

If you feel you need someone to be productive right now and don’t care about hiring the best candidate for the long term, maybe you should be hiring a temporary consultant rather than a permanent employee.

Besides, no matter how experienced with said technology, most people will need a ramp-up time to attain maximum productivity when joining an existing project. A smart person will be able to start mastering a new technology while learning all the other intricacies of the project at the same time.

I have seen a company hold out on hiring because they wanted someone with a very specific set of skills and level of experience and couldn’t find one. Suggestions to hire based on talent were dismissed with claims that they couldn’t afford the training time, they had to find someone who would be productive right now.

Months later, they still hadn’t filled the position. Sure, they had tried out some rare candidates who filled the prerequisites; X months with technology Y, X years with framework Z, but none had worked out.

Instead, had they hired someone with skills, intelligence and the right mind set, that person could have learned said framework and have been a productive member of the team by then.

In another situation, I remember doing a phone interview a few years ago for a company developing UI controls for a certain application framework. I was told I was a great candidate and they would have hired me if it wasn’t for my lack of experience with said application framework.

About two or three years later, said framework was pretty much discontinued. I wondered what that UI company was doing since it’s main products were UI controls for an abandoned application framework. Sure enough, they had converted their offerings to HTML 5 / CSS 3.

In such a situation it pays to have a team that is quick on it’s feet, learns quickly and stays up to date on various parallel technologies. Even if your current tech stack doesn’t get abandoned, having a team of quick-learning generalists will allow you to use the right tool for the job for each project, rather than make another Rails app because that’s all the team has ever did.

Conclusion

Smart, determined, result-driven people will get the job done. They’ll also turn around pretty quickly when you suddenly need to change framework, platform or language.

Why settle for someone who fills check boxes on a requirements list? Hire the best possible candidate. If you can do both, excellent, if not prioritize talent.

I’m not saying years of experience do not have a great value. Years of experience have great value. I’m saying talent trumps years of experience with a specific technology.

51 thoughts on “Hire talent, not five years with Java

    1. I think what the commenter is saying is that you say ‘compliment’ when it should be ‘complement’.

    2. > “did he just do some light JS from time to time to compliment his ASP.Net pages”
      I think the parent meant that you have a typo here, and that you should have written “complement”

    3. jQuery(“.entry-content”).html( jQuery(“.entry-content”).html().replace(/compliment/g, “complement”) );

  1. I never really understood the whole process of requiring 3-5 years of experience and then quizzing the person with coding puzzles anyway. This was so common when I graduated college (2009). Things are changing, however. More and more employers are giving out small assignments or mini-projects to filter candidates rather than using “years of experience” criteria.

    “Smart, determined, result-driven people will get the job done. They’ll also turn around pretty quickly when you suddenly need to change framework, platform or language.”

    +1

  2. Hiring is downright impossible. Deep dive experience in certain technologies can take years and can also be valuable for some positions. Everyone agrees that the best candidates don’t need any java experience to be a great java developer. A smart developer is a smart developer. That said, hiring and finding a smart developer with that criteria as an interview process is awful. The only successes I’ve ever had are through luck or through connections. Connections make hires.

  3. Really enjoyed your blog post, just tweeted it out to the world, and would love to follow you. @skillsheet

  4. I don’t disagree with you, but the problem you usually run into is that the entire technical recruiting industry is run by HR people and not developers and trying to explain to your local HR drone how to tell if a candidate has “talent” is nearly impossible. At the end of the day you’ve got 5000 resumes you need to par down to 50 or so you actually want to follow up on and all you’ve really got to go on is a handful of bullet points. Once it actually gets to the interviewing stage and someone technical takes over, we usually do try to screen for talent (plus we grill candidates about technical knowledge to find out of they’ve been BSing on their resume), but by that point we’ve already screened out a lot of candidates, probably quite a few of whom have serious talent but didn’t meet the arbitrary experience requirement the recruiters use to trim the pool down. The best we’ve been able to do so far is to train our recruiters to look for total years of experience and a diversity of technologies rather than some specific number of years in a specific technology, or some specific set of frameworks/languages, but that’s still a very rough list and we end up interviewing a lot of poor candidates that way as well.

    Ultimately your going to have to make a tradoff, do you screen less for specific technology and “experience” and spend a lot more of your technical staffs time on phone screens, or do you go the checklist route and potentially miss out on a lot of talent that doesn’t look very hot on paper. Either way the system sucks both for those with talent who can’t ever seem to land an interview, and those looking for talent that can’t ever seem to find it in a sea of mediocrity.

  5. Well said! I’ve been saying this for so long! It drives me crazy when people won’t give me a chance because I don’t have a degree or X years experience. I’ve always been passionate about programming and I’m a self learner. My current company at least understood that when they hired me. I told them I hadn’t used the particular framework they were using but I was confident I could pick it up quick. They agreed and haven’t regretted it. I wish more employers were interested in skill/talent than arbitrary qualifications.

  6. Well said! I’ve been saying this for so long! It drives me crazy when people won’t give me a chance because I don’t have a degree or X years experience. I’ve always been passionate about programming and I’m a self learner. My current company at least understood that when they hired me. I told them I hadn’t used the particular framework they were using but I was confident I could pick it up quick. They agreed and haven’t regretted it. I wish more employers were interested in skill/talent than arbitrary qualifications.

    1. I totally agree with Justin. I am the same way. I do a lot of learning on my own. I will spend my free time learning a new framework or a language if I need too. Actually, I already do that. Thanks Justin for your response.

  7. Gilles, great post! Also I think what you wrote calls for a better way of framing interviews – people on both sides of the table go in expecting to test someone’s ‘talents’ far more often and intensely than they probably should. Potential good interviews get ruined by nerves or expectations. I would think a hard-working, mission aligned, bright person would serve Company X better than that unicorn they are waiting for.

  8. I totally agree with your post. I ran head-long into this exact situation after I was hired for a job as a Data Analyst. I had “the right stuff,” but after a week the President told me that he was concerned I wasn’t “getting up to speed fast enough.” I assured him that I would get up to speed, but that I was learning their business, their methods (they had a very much hack-the-days-report-together-in-filemaker mentality), two new and entirely disparate database technologies, trying to figure out how to bring data together from completely separate systems, receive and process numerous data/reporting requests daily, make some headway on a list that was well over 100 reports desired by various departments the day I was hired (and there was only one of me), and so on and so forth. I told him that he’d be hard pressed to find someone with the combination of traits who could pick things up faster than me. But after a week he had the gall to tell me that he couldn’t give me three months (and I was putting in 12 hour days and working weekend) to get up to speed. I recognized a lost cause when I saw one and turned in my notice the next day. Apparently they’d had previous data analysts who also hadn’t lasted very long… And my thought was similar to yours: how serious are they about meeting their immediate needs? Because if they’re really truly serious then they’ll invest in the right people–even if it means giving them some “ramp up” time. Is it better to allow someone three months to “ramp up,” or spend three months searching for someone who can ramp up in a week?

  9. +1 It’s annoying to see companies asking for experience as opposed to talent. Asking for 5 years experience in JS when I have started working on Node.js in 2012 and am already contributing to open source projects, sound ridiculous!

  10. Requiring a certain number of years of experience is incompatible with uk age discrimination law in any case. Its basically illegal, and has been for some time.

  11. I understand what you’re saying, but you’re not really proposing an alternative. I think no one from HR will disagree with you that a talented person is probably going to pay off more in the long run, but how would you search for talent? What would you put in the ad? “Needs to be talented”? Then, how would you test that talent in an interview?

    Making a list of techniques used and the amount of experience required gives you, as a candidate, an idea of what they require and what you’ll be doing most of the day. If it interests you, but you don’t quite fit the bill, apply anyway. No one says that you have to fit all the requirements, as long as you can make a convincing case that you can fit them all in the near future.

    1. I’m not saying you shouldn’t have requirements and you’re right that I did not propose any solutions.

      Like I said in my conclusion if you can do both (meaning hire someone with talent and who fills the job requirements) that’s perfect. This isn’t an impossible situation btw. On the other hand if you can’t my personal recommendation would be to favor talent over requirements.

      If I were to write a job posting I would keep the list of tech requirements short. Avoid going too precise (Ruby is ok, asking for Sinatra experience isn’t necessary for someone who knows Ruby) and not make it a barrier to entry to talented candidates.

      It might be possible to leave out the years of experience and use qualitative descriptors rather than quantitative.

    2. There are ways to get a feel for real talent and passion when interviewing while avoiding looking at years of experience or specific languages and frameworks too much. For a developer it’s good to ask questions about what languages and frameworks they are familiar with. Chances are, if a developer knows 4 or 5 languages, they’re pretty experienced and can pick up a language quick, even if they don’t have a lot of experience with the specific language or technology the company is looking to hire for.

      It’s good to ask a few questions to make sure the candidate can back up their claims with knowledge. Usually a few simple questions can weed out a lot of bad candidates. Make sure they know what a hashtable/dictionary/associative array is. Have them write a little code to solve a simple problem and see how they solve it (e.g. find the smallest/largest number in an array or do a little recursion – nothing too tricky). Have them do a little SQL, etc… They just have to pass the idiot test – which a surprising amount of people fail.

      If someone is passionate, they’ll be a much more valuable asset to the company. Ask questions about newer emerging technologies to see if the candidate keeps up on the latest stuff. Ask where they go to learn about new technologies (e.g. Hacker News). Ask if they’ve taken opportunities to try to integrate new technologies in their previous jobs. This shows that they have passion for it, they keep up on things rather than just doing the same humdrum stuff for 5 years. Personally, when I learn about cool new things I like to play around with them, and if it’s helpful then use them at work.

      This creates a company of talented and passionate people. There’s no need to try to trick people and weed out great candidates because they didn’t figure out your trick. Just make sure they’re not an idiot, they’re passionate about what they do, and they keep up on the industry and aren’t afraid to dive into new waters and try new things.

  12. Great comments.

    It summarises the problems that (non-technical) recruiters have because they dont understand the technology. They are unable to tell if the candidate is, or can be, productive in a short time- again, because they dont understand the technology.

    Managers in charge of recruiting the right candidate are caught between two stools because the right candidate is not always the best at selling themselves and letting people know that they are “very capable”. The communicators are the people who are often the ones who will be successful.

    The managers often have the choice between:

    1. The safe option: someone who has the experience and who ticks the boxes but is unable to learn quickly.
    2. The right option: someone who has lots of different skills who can learn quickly and is very good at what they do but who may not tick the right boxes.

    Managers will often choose the safe option because they fear choosing the right candidate, in case it does not work out.

    1. I think one problem is that they “dont know how” to find talent because they checkboxes is a straightjacket which sometimes prevents the right candidate from being found.

      The entire process of finding the right candidate should be a simple one: “Can you do the job?”. However the process now is so longwinded and people-focused and HR-focused and so focused on weeding out the wrong candidates it also misses out the right candidate…

      1. Yeah, but look at things from the other side. Say you’ve got 3 open positions you need to fill, all for senior level people, you need people who you can toss a chunk of work at and come back in a week and it will not only be done, but done well. You’ve also got a pile of 100 resumes, all of whom if you ask them will say straight to your face “I can do the job” and most of them will probably believe it (see Dunning-Kruger effect). Out of that pool of 100 people, there’s probably about 30 who could “do the job” in a year or so, 20 who could reasonably “do the job” now, and maybe 10 who would “do the job” and then some (for those keeping score that means there’s also 40 that will *never* be able to “do the job”). So, how do you decide who to give those 3 jobs to? Do you pick at random the first 3 people who tell you they can get it done and then just fire them in a week when they’re obviously not cutting it and start over again? At a week a piece for evaluation, plus the overhead of the hiring paperwork, plus the time to interview you might be looking at a year from now before you manage to find 3 candidates that all work well enough to keep, and that’s assuming someone else hasn’t hired all the good candidates by the time you get lucky enough to randomly select them from the pool. I know at least a dozen really good programmers, all of which are currently employed, but any one of which, if laid off today, could have a good job inside of a month, and a really great job inside of 6 months. That’s what every recruiter and manager is competing against, they need to get good programmers in for interviews and hired before someone else does, but there are so many bad programmers (or mediocre programmers) out there gumming up the whole process it sometimes feels like an impossible battle.

        All of the above is why the process is so focused on weeding out the wrong candidates, because not only is it tough to find good candidates even after you’ve done your best to eliminate the bad ones, but it’s also a race against time, good programmers do not stay on the market long.

  13. As a CS senior, I have been running into this practice quite a bit lately. It is a little disheartening to see so many listings with such specific technologies + years experience as I have only been formally trained in one specific (C++). If I hadn’t started building side projects, I am not sure I’d even have a chance at this job market.

    I hope HR and Recruiter folks get a chance to read this article!

  14. Don’t agree. Some technologies are that much complex that it really takes significant amount of time to get it. So it’s perfectly reasonable employees wan’t to snatch someone already familiar with it. If you can get someone familiar with the framework and smart or someone simply smart the proper choice is obvious.

  15. I agree with you in principle, but I don’t think that the underlying problem is that HRs are really looking for x years experience in y because they think this is the way to go!
    The problem is: How to recognize talent? “x years in y” is at least a measurable value. And generally, if one has this he might be better then a person having <x years in average.
    When it comes to talent I am more in line with Malcolm Gladwell's "Outliers": That talent plays a minor role over trained skills.
    I agree, that the skill is not "x years y tech", but more "x years y principle" (e.g. Java vs object-oriented programming) and that picking up a new tech fast is more essentially than sticking with the same routine over x years.

    To point out my question: How do you measure theses actual needed skills?

    1. I’m afraid you can’t simply by looking at a piece of paper. You either need to have access to work done by the candidate, meet him in person or test his abilities in some manner.

      Sadly there are no easy perfect solutions to this problem. I personally think the best hires are those done by reference.

      If I was in a position to write a job description I would keep my list of tech requirements short and ask for qualitative skill levels. I would focus on general tech and languages rather than go into specific tech.

  16. This! So very this!

    I realized this about a year ago. If I ever wanted to branch out from Java, I would need to stop marketing myself as a Java guy, and more of a generalized programmer that goes and learns stuff. I revamped my Linkedin profile to reflect this mindset removed from specific technologies, focusing more on general programming, web apps, web development, problem solving, and architecture. I’m now have a job I love and want to keep.

  17. Nice article. I agree – it would be useful to think/discuss how to identify a talented individual as opposed to focusing on someone with experience in the ‘right’ technical skills ?

  18. Don’t agree. Some technologies are that much complex that it really takes significant amount of time to get it. So it’s perfectly reasonable employees wan’t to snatch someone already familiar with it. If you can get someone familiar with the framework and smart or someone simply smart the proper choice is obvious.

    1. As I mentioned in my conclusion : “Why settle for someone who fills check boxes on a requirements list? Hire the best possible candidate. If you can do both, excellent, if not prioritize talent.”

      Which is similar to your : “If you can get someone familiar with the framework and smart or someone simply smart the proper choice is obvious.” so we have at least some common ground.

      I also don’t want to generalize my comments to every possible situation, but I still think, particularly in today’s market where finding candidates can be hard, that it’s better to hire someone with talent than holding out on hiring.

      I liked those two comments made about this post on Hacker News :
      “If there’s no slack for training time, there’s no slack for an empty position, which is what we have now.” and in reply “Very succinct. If a company can afford to let a position go empty for six months because they “need someone who can hit the ground running,” then they don’t really need someone who can hit the ground running.”.

  19. Great post. I have shared it with some co-workers.

    I work for a recruiting agency and this happens all the time: requests come with a neverending list of skills/knowledge in specific technologies or languages with a number of years attached to each. And this not just makes finding the right candidate harder, it makes it totally confusing to know what the really important skills actually are. Not to mention the face clients put on when you send them a quote for the profile they think they want.

    I think you may be missing a “Yet” in the middle here:
    “…will net diminishing returns after a few years. As more and more features…”

  20. AKA hire for personality, fire for competency. Hard to accomplish when more and more of the technology sector is dominated by placement agencies that hire for margin gains and fire when clients yell enough.

  21. When you have no idea about the area of expertise you’re hiring, you are basically at the mercy of chance and referrals (which may be bad referrals). Especially when it’s a high tech expertise or requires a lot of experience (complex plumbing, electric wiring, car maintenance not just programming but anything you are ignorant of).

    You could be hiring an overpriced idiot, a complete loser, or a cheap genius. You literally have no idea, and no possible way to judge besides what they show you- which sometimes can be next to nothing (or nothing useful).

    If you have experience in the field, hiring people is a lot easier, but still difficult. Some people can fake their skill level, some will only appear talented, some will be geniuses but never have a chance to show it. You don’t know until it is far too late.

    1. ~~~ Talentless but experienced people slow down our progress ~~~

      It took me a long time going from newbie programmer (always needing assistance) to competent programmer (able to program anything at all with full confidence). Part of why it took me so long is because 90% of the people out there on the internet are total idiots who pretend to know-it-all. Pompous arrogant “programmers” who give horrid advice, make irrational demands on newbies (like saying every container except Vectors are EVIL for game development), or simply have no idea but insist on giving advice despite their inability or ignorance.

      Once I learned who the actual intelligent developers were, I was able to better identify the idiots who claimed to be competent. After that, it was so easy to learn to program. It took me only a few weeks to go from “Help! Help! I have no idea!” to “What do you want me to program? I can do anything.” Why? Because I was able to absorb intelligent resources (articles, tutorials, books, lectures) from competent programmers. I no longer wasted my time with idiot’s advice, which didn’t help very much (if at all). Once I got my hands on competent teachers, oh man was it awesome.

      ~~~ My experience with arrogant (talentless) programmers ~~~

      Now I go to game dev forums, still an amateur (but capable) programmer (with professional programmers I consult with weekly), and look at professional programmers who have years of experience in the industry, and their games are total trash. They waste so much time programming pointless classes, and one in particular has worked on a game FULL TIME for 2 years, and has barely accomplished more than what would take me a month PART TIME. (I wont give away the game, but it’s quite popular, and it never gains any real progress because there is only one programmer who is extremely slow or lazy and obsessed with feature creep).

      To show how this guy (and so many) are idiots, here’s an example. I talked with this individual once, and he argued that he was not guilty of feature creep because the feature has to be considered a NEW feature for it to be feature creep (and thus slow down his progress?) and he had “many of these features in his head a long time ago, years before making the game, so they aren’t new features.” I was stunned. The features weren’t in the design document, they weren’t in the prototype and weren’t in most of alpha. Yet he, at one point a long long time ago, thought of a feature ONCE while having coffee, and thus it’s not new, thus not feature creep, thus he is not guilty of it, thus he doesn’t waste his time, thus he is justified in taking so long to accomplish nothing.. Just craziness.
      Then one of the morons on StackExchange with tens of thousands of reps, tell newbies that all containers (Lists, Arrays, Maps, everything) are EVIL and should NEVER be used except for Vectors. What an idiot. Another there told me I’d have massive performance issues because modern hardware is “worse than it was in the past”. I ignored him, since the opposite is true, and I tried my method anyway- it worked flawlessly. Obviously he was dead wrong. Yet both instances I was the one with a negative rating. Trololol, I guess.

      ~~ Unfortunately, these idiots are the ones you will most likely hire. ~~~

      Yet these were the people who caused me to never grow as a programmer. Who linked me to useless tutorials, worthless articles, and incorrect advice. They are the NORMAL programmer in the workforce. They were the ones who the intellectuals said “Don’t listen to them. Try things [this way] or try [this out]. “Wow, that makes so much more sense! Whoa, they were wrong and my game runs fine!”

      They are the people you will hire, even when you think you got a good one.

      The only solution is to find some way to understand their intelligence outside of their expertise. I can only assume that these people are idiots in all walks of life, not just programming. It’s a mindset. It’s a blindness to arrogance which inflates their ego (and thus they probably come across as a lot more competent then they are to people who don’t know any better).
      A mindset, “I’m just as good, if not better than everyone else.” even if they are trash programmers. Probably alongside a hefty dose of white privilege (alongside the sheltered denial which often goes with it.)

      1. The video game dev who never makes any progress while being hyper-sensitive to criticisms has a good following, but the community (at least for the last few months) is becoming more and more critical that the game has made no progress. Each week, I see new threads on their forum of another customer complaining that in the last year, barely anything has changed.

        If you look at the patch notes, you quickly realize why it takes so long, as the dev posts updates which include minor feature additions (while major features are still broken or unfinished) and bug fixes that were simple fixes (like grammatical errors in text).

        Even worse, some features have gotten WORSE since a year ago, and thus new bugs have appeared. Bugs which are very prominent, such as in the interface when you click on things. It’s just crazy.

  22. BTW, I meant to prelude all of my rant against talentless programmers with this sentence:

    GREAT ARTICLE! Totally agree. Even more so, those hiring the programmers sound as incompetent as those they probably hire.

    The best line of all was in the beginning:

    “Specific Tech Y that came out last year, 3 years”

    LMAO!

Leave a comment