
Ask HN: Why are we still using years of experience to measure work aptitude? - djellybeans
There are things about years of experience that may <i>guess</i> something about a worker&#x27;s aptitude with certain skill sets, but it&#x27;s just that, a guess, not a sure-fire guarantee.<p>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.<p>Yet we state in job requirements &quot;5 years experience with ____&quot; 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&#x27;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.<p>So why are many companies grouping applicants by years of experience, and not by quality?<p>The only forward answer that I have gotten was &quot;because it&#x27;s easy, and a measure (but not THE measure)&quot;. I don&#x27;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.
======
mdorazio
You might be looking at this only from the perspective of a young person who
wants to find a job. If you consider the perspective of an actual hiring
manager, things start to make a lot more sense. Let's use a hypothetical
example based on some plausible real-world stats...

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.

~~~
bradknowles
With respect, I’ve got nearly 30 years of experience in the field, and I have
the same questions —- why do people equate years of experience with
competence?

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.

~~~
Symphlion
I agree to some extent, years of experience doesn't necessarily equate to
competence, however, it does help in determining whether or not that person is
at least capable of dealing with problems so common in our development world.

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

------
ToJans
When you are learning something new, you will make mistakes. Some mistakes can
be cheap, but others can be really expensive. If you do not know what I am
talking about Google for "advanced beginner" and "Dreyfus curve of skill
acquisition".

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...

------
Y7ZCQtNo39
If there were a better way, we would be doing it. Recruiting is half science,
half art. There is no formulaic way to guarantee you'll find the perfect hire.
There likely never will be. People are fickle -- you could find the perfect
person for a position who could have the ulterior motive of "resting and
vesting", and not being the leader in your organization that you'd hope they
would have been.

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?

~~~
warrenm
>Most employees are at will, so we can quickly get rid of them if they aren't
a fit.

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.

~~~
Y7ZCQtNo39
Let's say you get brought on, and it's clear that you aren't a fit in the
first two weeks. They still have the rolodex of other candidates they picked
-- they could easily extend an offer to #2.

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.

~~~
warrenm
>they could easily extend an offer to #2

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.

------
snow_mac
Training and experience are different qualifiers. Often times employers want
more then you can do "x" in "y" framework. Sure out of some kind of training
program you can do things quickly, "correctly" if there is such a thing. And
most importantly on time. But it often time is more than just the skills to do
the job, it's the skills to think, to conduct yourself in a professional
manner and also the relevant experience doing many different things.

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.

~~~
grigjd3
It is easy to understate how having experience with a wide array of tools
provides value. The number of times I've seen what should have been a three
line sql query written as a 200 line program in python or scala just blows my
mind.

------
InclinedPlane
Because the only _real_ way we have to determine the quality of a developer's
talent/expertise is to have someone equivalently talented/expert make a
_subjective_ estimate based on seeing lots of examples of their work. And even
then it's a bit of a crap shoot.

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.

------
InternetOfStuff
> Yet we state in job requirements "5 years experience with ____" with a
> sweeping generalization for everyone that has worked with ____ 5 years.

I'd be happy to hire somebody with five years of experience. However I might
get somebody with ten times six months of experience instead. Not the same
thing.

My point is: somebody who has worked on a thing so big that it took five
years, and watched its growing pains and observed it take detours and outright
wrong paths has learned a great deal, and I'd be eager to have them on my
team.

Somebody who spent the last five years banging out lots of cookie-cutter two-
month projects doesn't bring that experience at all.

> So why are many companies grouping applicants by years of experience, and
> not by quality?

This is a reasonable question. If somebody has long experience, this _is_ a
quality, in my experience. But, as I explained above, plain counting years
gives no valuable information.

> 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.

Neither do I.

As an aside (which some might object to), I feel myself growing sympathetic to
reverse-ageism: I'd prefer to only have people older than 30 years on my team.
To put it most bluntly: somebody that old will very likely have been
egregiously wrong before, will have failed spectacularly before. It has been
my experience that this makes people better engineers, and better teammates.

People who haven't met with failure yet make me suspicious.

Now get off my lawn.

------
pfarnsworth
To some degree yes, but mostly no.

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.

~~~
Nuzzerino
You're assuming that salary is determined by how "good" somebody is at the job
itself. Sorry to be the one to tell you that is but a small part of it. At the
end of the day, the company really doesn't know how good you actually are.
Your manager _may_ have a decent understanding of the skill level of the
members of their team. But your manager doesn't have much of a say over your
salary.

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.

------
blikdak
When I first started developing software and systems I thought it was about
the code. Now after many years experience I know the less code I write the
better. This is not something they teach or you want to learn when you’re just
getting into coding.

------
bigiain
Because tech recruiting is fundamentally broken. And pretty much every smart
geek who thinks "How hard can it be?"and decides to disrupt it, ends up
walking away battered and bruised (usually muttering under their breath
"People man! You wouldn't _believe_ what people do sometimes!")

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?"

------
friendzis
> People are held to different standards based on number of years of work
> rather than their accomplishments.

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.

------
ramzyo
I generally interpret “X years experience” as a rough indicator of what
responsibilities are expected of a potential hire. If a role is looking for 2
years experience or less, I’d probably expect to be an individual contributor.
Approx 5 years and level of responsibility grows, etc etc. This isn’t true of
every role, and I agree with OP that taken alone years experience is an
insufficient decision point for bringing on a candidate (IMO no single axis is
a sufficient decision point for a yes, but some single axes are decision
points for a no, like inappropriate behavior during an interview). However, as
a heuristic for both a hiring team to optimize the greatest number of
qualified candidates applying and for qualified candidates deciding whether
they want to apply, it’s a useful indicator.

------
everdev
When hiring, especially for tech roles, I only evaluated what the candidate
had accomplished in the last 1-3 years. Beyond that didn't seem relevant to
evaluating current skill set.

------
PurpleRamen
While the experienced worker might be useless for a company, with the
unexperienced worker we know that he will be useless. The experience companys
need is the kind of knowledge you can't learn at school, not even from hobby-
projects. You need to learn it under the specific pressure of a workplace
inside the general conditions of a company. Because the most important part
for a company is not how good the worker is, but how much negative impact the
worker has on the company. The unexperienced worker is someone who will drain
worktime of other, for training and because of failures that happen. The
experienced worker will drain much less, maybe even none, so he is less
damaging for a company. And how smart or skilled someone might be, gaining
this experience is only possible through time. So someone with less or no
experience is also less valuable for a company, and more damaging.

~~~
muzani
The bar for 'experienced' variees a lot though. Someone with 0 months of
experience is useless. But I've seen plenty of people with 3 months experience
do better than people with 3 years experience. Some also have dealt with logic
or projects at a much younger age or in college (like college is supposed to
do)

~~~
PurpleRamen
Yes, there is no way to measure personality and general experience. So it's of
course not a perfect solution. But it's sane defensive solution. It filters
out the exceptions in both directions and gives a good baseline of ability you
can except from the people. If this doesn't work, you can also go lower. It
should be also noted that "x years epxerience" is not always a hard rule, but
just a guidance. It should specifically drive those away who are lacking the
confidence and knowledge about the job. Someone with just 2-3 years could be
equal good for a job.

> Some also have dealt with logic or projects at a much younger age or in
> college (like college is supposed to do)

As said, the experience learned under the pressure of a workplace is quite
different from the experience learned at a lazy school- or hobby-project.
School and hobby only teaches the basics and is more acceptable to failures.
But companys are seeking the masters, for which experience is neccessary. Of
course there are always exceptions, but those exceptions usually can present
some kind of experience, so they kind of automatically fall out of the scope
of the question. Someone working x years activly on a bigger project should
put it into his vita, so that he can sell this experience.

~~~
warrenm
>It should be also noted that "x years epxerience" is not always a hard rule,
but just a guidance.

Absolutely: if a place is looking for 10 years of experience in software
development, and you have 6-7 _but apply_ , you have a chance of being
considered. If you never apply, you have no chance of being considered.

In some ways it's like the truism that lottery vendors bandy about, "you can't
win if you don't play".

------
GoToRO
Because is easy and you don't need to be a very good recruiter to use it
(its's how for cameras people use megapixels and not the actual quality of the
picture).

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.

------
gamechangr
Thats what Google does to some degree.

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'"

------
andy_ppp
I always love to see jobs that list 5 years of React skills as a requirement
;-)

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!

------
Rubinsalamander
As long as they can fill open jobs with somehow suitable canditates they have
no real reason to change their established process. They dont need perfect but
good enough. So even if they miss some good canditates it doesnt matter and
they dont know which person they missed in hindsight.

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

------
frobozz
One reason is because they have survived.

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).

------
jaequery
no matter how talented you may be, you still have to learn to walk before you
can run.

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.

------
ardit33
Because a good developer at 22, becomes a even better one at 25, and even
better one at 30.

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 graduate from college they are equal to somebody that has about 2-3
years of work experience.

------
diyseguy
Since when did years of experience start to matter? Hiring in this business is
still heavily ageist in favor of younger people afaik.

------
austincheney
What would you recommend as an objective qualitative measure of competency?
The rest of the world, in just about every profession, has certifications or
licenses. Unfortunately, this makes software developers cry. It could be that
there are many people working as developers who aren't qualified to be there.

~~~
nitwit005
Certifications and licenses certainly exist, but proof of their effectiveness
often does not. You, after all, do need to hire the people who failed to find
out if it works, which tends to be unpopular.

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.

~~~
austincheney
That is so far outside of reality. Nobody hires a law student who fails the
state bar exam to qualify its effectiveness.

~~~
nitwit005
Probably because that would be illegal.

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.

------
adamredwoods
When building a team, you need more than just technical aptitude, therefore
years of experience can also help judge:

\- 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

------
mikekchar
"I have done X" is more valuable than "I'm absolutely sure I can do X".

------
ademup
I agree with your question and reasoning. I would offer that the recruiter is
specifically not looking for RCGs. I have no idea why that would be relevant
outside of 'We want another company to have smoothed out your rough edges'

------
amriksohata
Thought I know younger staff who are more competent, I also know younger staff
who yet don't have the maturity to work in an office

------
hjrnunes
Because, in theory, there's no difference between theory and practice; in
practice, there is.

------
jarvisdung
I agree with your reasoning and question

------
kapauldo
Experience has a productivity curve.

