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)
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.
Hilarious. His job is to make hires; but doesn't have the time to actually do it properly! lol
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
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.
Thanks, it was a good read, bookmarked, and followed!
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.