Skills proficiency

English (en)

The global remote work community tends to interact in English. Switching languages might impact your visibility.

Jobs/gigs

Publish a job

Your jobs (posted or applied)

Preferences

Your genome

Signals

Messages

Torre's product roadmap

Request features

API for developers

Help

4.1.

Skills proficiency

4.1.1.

Purpose

The skill-proficiency feature’s purpose is to validate if a user is able to perform at the required level of the job considering its skills and proficiencies on their profile.

4.1.2.

Data

4.1.2.1.

Candidates

The data for this factor is captured by the candidates themselves. The candidates are able to validate their skills in the onboarding process of the platform, in the edit section while viewing their genomes, through the recruiter bot, while changing experiences or through importing resumes.

4.1.2.2.

Talent seekers

Talent seekers can specify their requirements in the job post onboarding or while editing the job.

4.1.3.

Data validation

We validate the data that candidates give us in multiple ways.

4.1.3.1.

Verifications

Experiences of candidates can have related skills and they can be verified by other existing profiles. The verifications make the skill more likely to be true information.

4.1.3.2.

Recommendations

Candidates can have recommendations for skills with their related proficiencies. This gives the skills and proficiencies more credibility.

4.1.3.3.

Through related experiences

We check the amount of years of experience that a candidate has with all of their skills and we validate the related proficiency with that experience.

4.1.3.4.

Skill-experience relevance

We check for every experience that’s linked to a skill, how relevant that experience actually is for the linked skill.

4.1.4.

Algorithm validation

Daily and weekly metrics
Editorial reviews
Direct feedback from talent seekers
Direct feedback from candidates

4.1.5.

Description

For each skill the job requires, we assess the corresponding skills in the candidate's genome. This evaluation involves two key aspects: measuring the similarity between the skills and comparing the proficiency levels.

4.1.5.1.

Skill similarity

First, we standardize and map every skill to a normalized version. We then employ a string comparison technique. If the genome's skill and the job's skill are an exact match, we assign a similarity score of 1. If they do not match precisely, we use our skill graph to check for any possible connections between these two skills. In cases where no direct connection exists in the skill graph, we resort to a data science/word2vec model to calculate the similarity score.

4.1.5.2.

Skill experiences

In some cases (unrecommended) the job requires a years of experience requirement instead of a proficiency. In this case, we compare the user’s years of experience with all of the skills with a similarity bigger than 0.

4.1.5.3.

Total score

We conduct a comprehensive comparison of each job skill with every skill in the candidate's genome. In this process, we calculate both Skill similarity and proficiency similarity for each pairing and multiply these scores together. The highest resulting value for each job skill is taken as the individual's score for that particular skill. Finally, to determine the overall job matching score, we aggregate all the maximum scores calculated for each skill and divide the sum by the total number of skills. This gives us the total score on how well a candidate can perform the skill requirements of a given job.

4.1.6.

Mathematical description

The mathematical equation for the entire described process can be expressed as follows: Let:

J be the set of job skills.
G be the set of skills in the genome.
S(j) be a specific skill in the job skills set J.
S(g) be a specific skill in the genome skills set G.
Prof(S(j)) be the proficiency level of skill S(j) for the job.
Prof(S(g)) be the proficiency level of skill S(g) in the genome.
Sim(S(j), S(g)) be the similarity score between skill S(j) and skill S(g).
Proficiency_Weights be the set of weights for proficiency levels.

The total job matching score is calculated as follows:

Where:

Sim(S(j), S(g)) is defined as:
If exact string match → score = 1
Else
If the skills are connected in the skillgraph:
Multiply the weight of each edge until you reach the job skill node. The result of the multiplication is the weight.
Else:
Compute the vector for both skills using word2vec and compare both vectors to calculate the similarity instead.
Proficiency_Score(S(j), S(g)) is defined as:

Experience_score(S(j), S(g)) is defined as:

SkillGraph_Sim(S(j), S(g)) is the similarity score based on the skill graph connection
Word2Vec_Sim(S(j), S(g)) is the similarity score based on the Word2Vec model.
|J| represents the total number of job skills.

4.1.7.

Uncertainty

Uncertainty factors of this feature are in “missing skills only”. When a skill is missing from the candidate’s skillset we don’t assume that the person doesn't have it but instead we let the candidate and talent seeker know that we have some missing information of the user. This is then reflected in the score as an uncertainty range.

4.1.8.

Alternatives (why are we doing it better)

In contrast to other job platforms, we gather structural skill and experience data. By gathering the data more structurally it makes it possible to do much more resilient and accurate algorithms.
Where other platforms use years of experience as a measure of a person’s capabilities to perform a skill, we use proficiency instead. This is a more accurate estimate because someone can have years of experience with a skill but as long as they haven’t focused on learning and optimizing the use of their skill they can be outperformed by someone with fewer experience relatively easily.
Most skill matching is done by using text co-occurence, text vectorization and text analysis. This has proven to be insufficient for matching people to jobs though. We have noticed that there is a more intricate system that defines if someone can do a skill or not and a better approach of matching is by building a knowledge graph of skill relations. This give way more control and flexibility of matching. A typical example is that someone with the skill “java” can do “back-end development” perfectly. This is because java is a tool for backend development. These “types of connections” tend to be very important parts of matching that text analysis and vectorizing isn’t able to solve.