DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 964,423 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Lawless Sharpe
Lawless Sharpe

Posted on

The Broken Metric: Why Years of Experience is Meaningless in Software

We've all seen it: a job you're more than capable of handling in a competent manner: an opening for a developer position that highlights a tech stack that is your bread and butter.

You know it inside and out. Forwards and backwards. MERN. LAMP. Whichever it is. You know all the latest and most relevant features of your language. ES6? You're fluent in ES2022 - on top of all the newest tricks and shortcuts - Hooks, Async, Typescript, what have you.

The problem? Not one of these techniques existed five years ago.

So in what broken and out-of-touch hiring system is it important that you were writing React apps five years ago?

Class Components. Functional Components. Hooks. Redux. Going all the way back to when react was a library you included in a <script> tag. Obviously, this sort of scenario applies across technologies.

Why should it matter, at all, if you were writing React in a style and manner that was en vogue six years ago -- but which is completely useless now?

The obvious answer is that IT DOESN'T.

So why do HR departments and hiring managers continuously look at this metric?

The easy answer is because technology is a dense, and hard-to-evaluate skillset for people who are not themselves educated in it. The HR department doesn't know how to distinguish one resume from another for the simple reason that they don't know a promise from a hash table: they don't speak the language.

And so, they resort to familiar, albeit broken, metrics of competency: years of experience.

Which in an industry where the standard of operation changes every few months; reflects absolutely nothing regarding the skill level of a candidate.

Now there is some obvious benefit to having done something for a longer amount of time; but this creates a bar to jump over which in many cases, does nothing to actually differentiate candidates, and instead only favors those who have momentum in their career; instead of being a fair reflection of who is competent in the job.

Of course, some companies have sought to solve this by requiring coding interviews that resemble leetcode questions.

This is better; but it still has little to do with a Front-End or Mobile developer's day-to-day job responsibilities.

Other companies have gotten a bit closer with sending 'take home assignments' -- which mock actual real-world development; but the problem here is that the time requirements often make applicants feel rushed and prone to submit a project with overlooked bugs or a lack of polish.

Perhaps together, we can steer the industry into a bright new day where hiring managers have someone qualified actually review the github linked on your resume.

Top comments (6)

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

Perhaps together, we can steer the industry into a bright new day where hiring managers have someone qualified actually review the github linked on your resume.

I remember someone making a good case that the Google interview process he went through was meaningless and that the correlation between passing the test and doing the job well was very weak.

Basically it would be a better filter to just ask "in practice we will need someone who we can trust to do xxx and yyy. Do you feel up to the task ?". And have a look at the GitHub profile to confirm.

In response am interviewer from Google told him that yes the process was broken but he didn't have time to look at his damn GitHub profile.

So I'm not super optimist. The only good thing is that a tight developer market put pressure on companies to be less insane.

Collapse
 
lawless07 profile image
Lawless Sharpe Author

Hilarious. His job is to make hires; but doesn't have the time to actually do it properly! lol

Collapse
 
vladi160 profile image
vladi160

The argument that, because there are always new ways/libraries/practices/standards, the years of experience is not so important is wrong. The exp. will give you the habits to learn fast (learn to learn) in a way that you don't care much about that and more experience means easier learning. A dev with Mern stack only is far away from full-stack or senior. You need to learn fast and implement fast - this is what the experienced dev is.
When you learn a new framework, for the example, you just learn a new way to make the same result. After the years, you will know many ways and one is nothing

Collapse
 
lawless07 profile image
Lawless Sharpe Author

Well, that's kind of what I'm saying; just from a different direction. An experienced developer will be able to quickly pick up a new framework and implement it; regardless if they've been using it for a year, or just seeing it for the first time. Putting time in to learn the fundamentals is much more important than having x number of years in a specific tech stack: which is moreso what I am criticizing here; that recruiters and HR look for a specific number of years with their target framework; instead of realizing that general development skills transfer between technologies.

Collapse
 
naubit profile image
Al - Naubit

Thanks, it was a good read, bookmarked, and followed!

Collapse
 
decker67 profile image
decker

It's not totally meaningless but should not be that important. With every new framework you will learn something new.

More important is to know the concepts.

Those Bootcamps does not fit in theses cases and only teaches hopefully state of the art Frameworks, but not how to program or solve a problem.

Update Your DEV Experience Level:

Settings

Go to your customization settings to nudge your home feed to show content more relevant to your developer experience level. πŸ›