Years of experience
Yesterday, I found my resume while browsing through my documents. The first line read “More than half a decade of experience in programming”. Although the resume was not that bad, it still got me thinking that “Is this the best way to give a measure of my skills?
I know, it has been a standard practice for ages, to quote your experience in terms of years, be it anything. In fact, many times people quote their level of skills in years, as well. Looks like, it has become a norm, expected behavior. It might make sense when one is looking for a CEO or a manager for the team but is it an appropriate thing to do always?
Why do we measure experience in years?
It might be based on the assumption that any person can learn anything, given enough amount of time. Well, that does make sense. For instance, any person can spend two years on some Machine Learning problem and gain a lot of knowledge. But is there a way using which she can check whether she is on par with other ML enthusiasts with two years exposure? What is she expected to know after two years of exposure to Machine learning? Even if there is a standard around expected knowledge milestones corresponding to exposure in years, it would be based on another assumption that everyone can learn at the same pace and ease. These assumptions have never proven to be correct, rather proven otherwise every now and then.
Various other possibilities could be -
1.The belief in the old saying — “Wisdom comes with age.”
2.Years being an easily quantifiable metric, against the other qualitative skill measurement approaches.
3. “ More years implying better skills”, for traditional single-skill jobs like sewing, masonry, etc. It is a long shot, but yes, it could be one of the reasons.
About Accuracy!
Any hiring manager can judge the accuracy of this approximation of using years as the measure of skills. We just need to maintain a few metrics-
1. The number of people interviewed who passed the “Years of experience” Criterion, let us call it Nexp
2. The number of people interviewed who passed the “Years of experience” Criterion and were dismissed due to lack of skills, let us call it Nlackyexp
Accuracy = 1- (Nlackyexp/Nexp)
If accuracy comes below 0.5, we might need to look into “Years of Experience” Column and start again. Okay, this sounds too rudimentary. That’s why a Hiring manager should take a more data-driven approach. We should see how much impact the accuracy of Experience and Skills captured from job-seekers has on the recruitment funnel. If it does not impact it, we should ignore it, but if we find a pattern, we should go and fix it. And maybe share it with the world.
We do check for the skills during the interview!
Sure we do. But is that the right stage to check for the skill level? Shouldn’t interview just be a skill validation stage. Interviews are too costly to do the necessary skill-identification. It costs us both money and time.
Discussions should happen after primary match-making(what people call screening). Describing the skills required for a role correctly and comprehensively in the Job Description can help candidates assess the relevancy of the role and take informed decisions. It’ll also help recruiters in finding the right talent, by removing the guess-work.
Having said that, the right stage to identify skills might vary with roles, but definitely, should be done before interviews.
Let’s take an example.
Suppose, someone is working as a business analyst. His daily job requires him to extract data and analyze it to find some trends. He uses Excel to do the same. He writes one Macro to avoid doing manual and repetitive tasks. So it is fine to say that the level of his skill is: “Data crunching automation in excel”.
Some might achieve this ability in a year, some in 2 years and a few, in 3 months. Irrespective of the time spent, he possesses this skill. But data crunching might not be the only skill required for a job. Hiring manager might already know(more often than not) what he expects from a person when he says two years of experience. But pointing out every skill that we expect from a person to fulfil a particular job, will make it easier to do the right mapping.
For instance, in the case of programmers, we can have a look at this competency checklist. Although it is a bit older, it still gives us a fair idea. If we build something similar for all sort of roles, we might be in a better position to judge a candidate’s skills, way before interviews. It might still not be hundred percent accurate, but better for sure.
Conclusion:
We need to define new and better quantitative skill specific metric to measure the level of knowledge one possess.
