Ask HN: Why are we still using years of experience to measure work aptitude?

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.

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.

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.

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

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.