Ask HN: Why are we still using years of experience to measure work aptitude?
Not every programmer with some years of experience is better than a recent grad at doing certain things. A new grad from a top school can fire on all cylinders with some training. Having more years of experience does not confirm that a person requires less or no training, however.
Yet we state in job requirements "5 years experience with ____" with a sweeping generalization for everyone that has worked with ____ 5 years. People are held to different standards based on number of years of work rather than their accomplishments. That's some flawed reasoning. There is no standard consensus to measure some aptitude for any given length of experience. Experience is only a measure of time quantity. But quality and accomplishments are what matter.
So why are many companies grouping applicants by years of experience, and not by quality?
The only forward answer that I have gotten was "because it's easy, and a measure (but not THE measure)". I don't find this answer satisfactory. It almost defends a lack of investing more time or effort to find better ways to filter applicants for desired aptitude.
62 comments
[ 2.9 ms ] story [ 102 ms ] threadMaybe they're borderline sexist, but not enough where you can pin anything on them. Some people in the office will avoid that team or part of the office.
Maybe they're borderline reverse-sexist, where you disagreeing with them means you're obviously sexist.
That describes two people I've worked with who were fired. It really lowered team and office morale that they were around. I suppose I bonded with my coworkers over our bad experiences, but I think everyone else would've been happier and more productive without these toxic coworkers.
My point is about team and company dynamics. If someone seems off enough to their potential teawhy take that chance? There are plenty of good candidates out there and the cost of getting rid of a bad employee far exceeds the cost of deleting finding a good one.
I don't care about a candidate's gender, race or whatever else. I care how they'd get along with who they work with, which plays a large part in how we'll be productive together, or get in each other's way.
I do think that measuring individual competence is important for software too. Gauging collaborative ability is still important though.
If you can produce a demonstratably effective test for filtering out incompetent or low productivity employees, people will bury you in cash at you without hesitation.
They do hire plenty of people without law degrees for support roles that don't require it, so presumably they've already decided it's not a useful discriminator for those roles.
Also, because the people paying for and the people doing the recruiting have very different incentives, motives, and KPIs - from the people getting recruited... It doesn't make sense to _you_, because the question you think they're answering is not "How do we get the largest number of vaguely plausible candidates into the sausage-machine with the least amount of effort - while minimising the numb er of obvious no-hires down below some acceptable level - so that one one of them flukes the 'cultural fit' lottery we get 25% of their first year's salary?"
So we take proxies -- like degrees from renown (or at least accredited) institutions, prior employer prestige, and years of experience as signals for what may be. But ultimately, we can never know.
Even with a whiteboard coding exercise, the subject could get lucky and know the question. Or get nervous and fail miserably, but would have succeeded on the job.
There is no good answer for how to reliably choose talent. If there was a prescribed way, we'd do it. The best that we've come across in our industry is to say, "well, the candidate could implement algorithm <x> on the whiteboard, so maybe they know a thing or two".
Also, you might be over estimating the amount of time/effort we should put into hiring. Most employees are at will, so we can quickly get rid of them if they aren't a fit. In a world where employment trends further and further towards being ephemeral, why should we invest any more than we do?
While this is technically true, it's ridiculous to think most employers think this way. Onboarding costs (from placing ads to interviewing to extending offers to actually hiring to getting equipment issued to getting people signed up for all the crap they need to get signed up for to training etc) is MASSIVELY expensive.
A day of interviewing costs not only the flight & hotel for the candidate (presuming they're from out of town), but also the lost work time for everyone involved as interviewers.
Flight + hotel should not be a deal breaker for a well-funded business or one with access to a lot of capital. If you're bootstrapping, it could be an issue, but I don't think those startups tend to hire people out of town.
And #2 could easily have already accepted elsewhere. Or otherwise no longer be interested.
Hiring is HARD. And doing it not poorly is often the biggest hope: hiring well is exceptionally difficult - a couple hours of forced interaction in a manner that will never happen again is a pisspoor way of doing it.
If the company just wants you to lay down lines of code the way you lay down bricks, sure I could see any tech school training as being sufficient. But years of experience are an indicator of a number of different factors:
1. You were competent enough to hold a job(s) doing x for y years
2. You get along with others if you don't how could you possibly accrue 5 years of experience working
3. You've seen different approaches to doing things, which can give you insight into how to do things that make sense for this application
4. You have awareness of performance, maintainability, testing etc... that affect a long-term success of a project.
I think it can be helpful, recent grads are just that, recent grads. You have a lot to learn about working for a company, contributing code in a long-running project and other things that your college or tech school training cannot provide.
Best case the code you write for this company will be in production and running for many years to come. That's what the company is hoping for. Not just a short-term implementation of some best practices to satisfy short-term goals.
A hiring manager at a decently desirable company posts a job online. Within a week they are likely to get around 50 applicants, at which point they basically stop looking at new ones. Probably 30% of those can be eliminated immediately for not having any relevant experience or coursework whatsoever, having glaring mistakes in their resume, etc. Now the hiring manager still has 35 applicants to evaluate. How do you propose that they narrow the pool in a way that doesn't take weeks of labor? Remember that any multi-round interview, skills test, whiteboarding session, etc. is going to take significant time from the team as well for every single candidate.
This is now an optimization problem. The hiring manager and team have X hours they can allocate to reviewing resumes and interviewing, but X is not nearly enough to properly evaluate the skill level of every single applicant in the pool. We need shortcuts to narrow it to a reasonable level, so what options do we have? Experience is one, so is pedigree (prestige of school, certifications, etc.), maybe we could also look at GitHub commits or spend a maximum of 5 minutes per candidate looking at referenced projects/websites. But we need something that can be evaluated quickly, and experience is an easy proxy since it at least indicates that a person has been around a thing for a while and wasn't so bad at it that they got fired for incompetence. And in many cases that's better to look at than having no indicator at all (i.e., 0 years experience).
It's also worth noting that experience implies more than just technical competence. There is value in having worked on a team in a real-world work setting using skill X that goes beyond how well you can solve technical problems. Experience means you've seen things go right, and also seen them go wrong, you've worked with various kinds of people and personalities while doing X and have the benefit of knowing what to do when you encounter a situation that has come up before.
You can be an 80 year old man who is doing totally inappropriate things by sexting pictures of their junk to underage kids.
Or haven’t you been watching the news lately?
To add to that: Companies are not always looking to hire the best person for the job, but someone that can solve the problems they are facing. Since problems tend to repeat themselves, someone with experience has likely encountered and solved many of the problems they are hired to deal with.
This is not saying that having experience in a field means you will be able to solve a problem better than a inexperienced person, it just means they've likely encountered it before (or a variation) and managed to solve it. Business in general are risk averse, and therefore will opt for a guaranteed solution even if its not optimal.
This fits workplaces that make CRUD apps. But if you're ambitious you really don't want to filter out the un-cynical young people that might have lost patience with a poor employer in a short time. Even at the cost of having to skim through the text of 50 applications and picking out the interesting sounding ones.
From my experience having worked in mostly agencies doing the CRUD work you described, and other "consultant-like" work, not many skills seem easily transferable to large, well-known B2C corporations where the software they work on is their own (not the property of clients) and need to deal with massive datasets. My interviews and resumes get rejected from this gap in knowledge. I simply don't have much of that sort of experience. Yet time and again I am faced with high scrutiny because of how many years I've worked in my career.
It's about time I update my resume. Perhaps I need to create a much more functional resume, and less chronological based one. Emphasizing my best personal projects and most relevant skills while trimming away the older jobs, to make myself look more fresh.
> Perhaps I need to create a much more functional resume, and less chronological based one.
No, do something about that skills gap.
I’ve met so many people who are incompetent and yet have many years of experience, and I’ve met a number of people who are very competent but do not actually have that many years of experience.
It's not _just_ about the technical skill, our jobs require us to communicate, think, analyze problems/challenges, troubleshoot, fix bugs, oh and also, on occasion, write code :P
Or you could have 30 years of experience
Both look like "30 years" - but it, generally, comes out in screening and interviewing processes who actually has the "30 years"
I have 25+ years experience, and I make as much as my coworkers who have ~5 years experience. There are engineers younger than me that make more than I do. I don't get a free pass or more money because I'm older with more experience.
There's a great deal of salary compression once you hit about 10 years experience. Someone with 20 years of experience isn't twice as good as someone with 10 years experience. It in fact might be a hindrance if you haven't updated your skills.
So, sometimes years of experience is taken into account, but I would say mostly not really, just broad strokes at best.
It's 2017, and we are still using an archaic architecture for the worker-business relationship. As long as the workers continue to believe that they are getting a great deal, then this will continue.
What employers are doing when they look at years of experience and so forth is trying to hijack the process of evaluation. If you see that someone has been working at some prestigious company in an important role for years or they've been promoted while working there, and so on, that gives you a little bit of insight into what that organization and that person's co-workers think of their skills. If someone has managed to stick it out in the industry for some number of years it's less likely that they are just faking it.
The core problem here is that assessing a tech worker's skills and potential is something that could easily chew up millions of dollars in resources to get a good answer, and easily many tens of thousands of dollars to get a pretty crappy answer. Instead, employers choose to try to get answers to the question with one or two orders of magnitude less in resources expended. That's all it is.
I recently watched an Eric Schimdt interview where he says... "The industry over values experience, but under values strategic flexibility...I used to go around and ask 'what's your super power'"
Looking at the spectrum of software organizations at one end there are product shops baking simple mobile apps or dressing up WordPress, at the other end - enterprise grade vendors with codebase lifetimes reaching into decades. Those bakeries tend to have small number of experienced engineers/project managers and a high number of cheap fresh grads who will somehow ship something. In those large enterprises juniors are usually required to show ability at baking code and some experience. So we see that years of experience is not necessarily pervasive metric.
> So why are many companies grouping applicants by years of experience, and not by quality?
Bootcamps are based on the very same principle - sharper individuals can be trained in basic principles of baking Angular/Laravel/Spring code in a summer. Competent developer can more or less switch frameworks in even shorter timeframe. Baking code according to spec is not the biggest issue in software engineering. There are two aspects here.
SW industry has a pervasive problem of people burning out and leaving industry and opportunists attempting for good pay. Years of experience can show applicants' ability to live in this Absurdistan that is SW engineering. Years of experience is a metric allowing to chose applicants who will commit to work at relatively low false positive rate (albeit at absurdly high false negative rate). Another aspect is "smelling shit sooner than seeing". In a long term project senior engineers able to scream "Boys and girls of every age, hold your keyboards, this looks good, doesn't work. Been there done that" are crucial to success and that comes with direct experience not from reading books. Years of experience, while it may not be perfect or even unsuitable in certain situations, is not unjustified metric.
Why? Experience matters. It is not just about the ability to write lines of code, doing all nights, and getting lots of "stuff" done, it is about the ability to write (and remove) the right stuff, and not wasting time with things that don't matter. It is the ability to guide, teach and mentor other people, and the ability to see when something might/will not work.
This comes only through experience and time. Experience to ship multiple large features and products (some products might take years to finish off), and see what works and what doesn't.
Sure, a bad dev. with 10 years of experience is worse than one with 2, but a good engineer with 10 years of experience will probably be more effective than one with just 2 years of experience.
Let me give you some real world examples:
1. In many states you can't rent a car if you are under 25. Why? Because rental car companies figured out that the human brain is not fully developed and reaches maturity until 25, and younger folks are prone to be fickle, take unneeded risks, and get into reckless accidents more often.
2. The Roman army had three units: The Hastati (young/inexperienced solders) in the first line, principate (more experienced folks) forming the second line, and the battle hardened triari forming the third and final line.
They figure out that just physical strength was not enough, and experience was more important. Aka, you can't be just good at swinging the sword, but composition, battle formations, tactics were more important, and the more experienced you were the better solder you were, hence the best soldiers were kept on the third and final line.
3. A bad doctor or lawyer can be bad at any age, a but a decent one becomes better and better with experience. (lots of different cases can form predictable patterns over time, and experience counts).
4. Plenty of young soccer players are really good at playing soccer, but can be terrible at coaching/teaching it. Some of the leading/coaching abilities come only through time and lots of life experiences.
I can give you countless other arguments, but the final gist is: if you are good with 2 years of experience, you become even better with 10. And some companies don't want people that just code/write features, but they need also the people that will guide large projects, know when to remove things, and teach/mentor other folks around them. And those abilities come only with sheer experience.
At Spotify we had a desirable ratio of 1/3/3. One lead engineer (usually with at least 7 years of experience, 3 with 3+ years of experience, and 3 with little/no experience). The senior ones could guide the more junior one into doing things, but the lead one were expected to see the upper view of a project (i.e. not just the trees, but the forest), and help steer the architecture on the right directions.
When we had too many junior devs. in one team they tended to be ineffective usually by: slow at producing things (deer on the headlights syndrome), buggy features, bad architecture, creating frameworks that were totally pointless, and my favorite: in-fighting between devs, usually over trivial things on code reviews which rendered the teams totally ineffective.
So, you can see that some companies want to maintain the right ratio of "young guns" vs "experienced folks", and hence some might want people with more real life experience for some positions.
When I worked at Yammer, I remember the exec team refused to hire junior engineers initially, because it proved to be a time wasting exercise and they tended to require more time from senior devs. to be guided, than the value that they produced (by doing and shipping the right features).
Now there are always exceptions to this rule, but usually I learned that the exceptions were kids that have been programming since they were 13-15, and when they...
I get several job offers per year from my professional network, because I have been doing some things in the past where mistakes were bound to happen. Due to my expertise I am more likely to finish certain projects within time/budget/scope than others.
While it might be a long stretch, compare it to road cycling: who might have the best chances to finish a century (100 mile ride) within a reasonable time:
- someone who has read a lot about road cycling
- someone who has finished several centuries successfully
Practical knowledge tends to be way deeper than theoretical knowledge, and usually gives you the ability to judge whether the theory applies in a certain situation, or it does not.
You can not become a master chef by looking at TV shows, you need to walk the walk...
depends on the job but it should be obvious that an inexperienced developer can slow a project down if the skill levels are too great between a team of programmers as they will have a hard time communicating certain things. there will be many hours a day spent explaining little things that they usually fail to see. this might be fine for big companies but a real handicap for new budding startups.
programming is not just math and logic, its also about seeing and properly identifying the situations, to know what type of tools to use, which 3rd party libraries are needed, and knowing when to take shortcuts and not to, which are all difficult choices if you dont have any real world experience.
but on the contrary, i have also worked with some college grads or even high school dropouts that seem to have as much experience as some seniors. and these are the hidden gems most companies wish to find during hiring process.
its a difficult nut to crack when you are reviewing a hundred or so applicants and it comes down to seeing who they are on paper. which means most of the focus is seeing who have the most accolades, ahievements, github stars, etc.
- how well someone can get along with the group
- how well someone knows the industry and relationships they've built within it
- how well make decisions that are not specifically programming-based that may need a business perspective as well
Seriously though, I think what’s important is to look at your weaknesses and keep improving and learning new technologies. X years of experience just shows that you have hopefully grown professionally and personally from where you are today. If you are sure you can do a job I as an employer wouldn’t mind seeing this sort of information in a cover letter hopefully with links to code examples on github.
Finally X years of experience is meant to show how to get the best out of working on a team!
Because, as a recruiter, you just need to fill the job; you have no incentive to do justice to any particular person.
Because recruting is just another job and you just printed the cv as the candidate entered the office and the first 3 questions will all have the answers in the cv, because you didn't read it.
Because beeing a good recruiter is hard and rare so you mostly encounter bad recruiters that use easy to understand signals, like years of experience.
Because with a little guidence anyone could do the job but the person with the guidence left the company.
If they have problems finding qualified workers they are much less strict with requierments and more creative
Another reason to prefer easily measured established values like experience is to justify yourself against higher ups if something goes wrong
A fresh graduate, or a one-year-in second jobber could be a genius with encyclopaedic knowledge of the subject. They could also be utterly incapable of doing the job. Their Dunning-Kruger overconfidence is untempered by the experience of being overtaken by considerably more competent cow-orkers.
Someone who has been at it for 5 or more years, should have a reasonable grasp of whether or not they can do the job (though not necessarily the level at which they can do it).