When you sign up for RoleLens and say you're open to offers, you can come up in the searches of companies that are hiring, and each company whose shortlist you're on sees a number from 0 to 100 for how well you fit its role, with a short note on why and how sure that number is. If you're going to let companies find you through a number, you should know where the number comes from, so this is how it's worked out, including the parts that are still imperfect.

It starts with a profile of your work

When you connect your GitHub, upload your CV, or connect your LinkedIn profile (any one of them is enough), a language model reads what you've given us and writes a profile of your work: the skills it can see in it, the level the work points to, from junior through to principal, the domains you've worked in, and a summary of four to six sentences. You can read that profile yourself, and if it gets something wrong, you can tell us.

That profile is what every company's search is compared against, not your files directly. To change how you come across, update what your CV or repositories show, then update the profile.

Step one: narrowing the field

A company's search says what the role needs: the level, the skills it requires and the ones it would like to have, and a description written in its own words. Reading every profile against every search properly takes time and costs money, so the first step is a cheap one that only narrows the field. We compare the description the company wrote with the summary of each profile and keep the ones that read as close, up to five times the size of the shortlist the company asked for and never more than 100.

Only people who've said they're open to offers are in that pool, and anyone who has asked to be hidden from that company is left out before the comparison starts, so they don't take up spots someone else could have had.

For the curious: "reads as closest" is a vector search. Each profile summary and each search description is turned into an embedding, a list of numbers that represent what the text says, and the search finds the profiles whose numbers are closest to the description's. The index it uses is approximate, which means it can occasionally miss someone who was slightly closer than the last person it kept. The open-to-offers and hiding filters run inside the same query, so the people they leave out don't take up places in the pool, although a search can still return fewer people than it asked for when fewer are open to offers.

Step two: the score

Every profile that makes it through is then read by a language model alongside the search query and given a score from 0 to 100. The model is given fixed bands that say what each range of numbers means, and is told to choose the band first and only then pick a number inside it:

  • 90 to 100: meets all required skills with clear evidence and most preferred ones; the level matches.
  • 75 to 89: meets all required skills and some preferred ones, and the level is the same or one step away.
  • 60 to 74: meets most of the required skills with one or two clear gaps, or the level is off by more than one step.
  • 40 to 59: some relevant experience, but several required skills are missing or lack supporting evidence.
  • 20 to 39: a related technology or domain, but not this role.
  • 0 to 19: a fundamentally different profile.

A required skill only counts where there's evidence for it, and a skill with no evidence counts against you as a gap rather than as neutral. Preferred skills can move you up within a band but can never lift you into a higher band on their own, so a long list of nice-to-haves can't make up for a missing must-have. The model is also told to score each person on their own against the search, never relative to the others it reads in the same batch, so who you happen to be read alongside shouldn't move your score.

The model writes the reasoning the company sees next to the number as well: two or three sentences about your work, how it fits the role, and where it falls short. It's told to leave out your name, email, handles, and links, and we remove any we find, although a project or a past employer it mentions could still point to you. The model is told, both when it writes your profile and when it scores you, that what it reads — your CV and READMEs as much as the company's search — is material to read and not instructions to follow. That makes a line in a README asking for a score of 100 unlikely to get anywhere, though no instruction to a language model is a guarantee.

Why your score doesn't change from one run to the next

Ask a language model the same question twice, and you can get two slightly different answers. For a number a company may compare from one week to the next, I didn't think that was good enough, so once you've been scored against a search, the score is kept and reused for as long as three things stay the same: the search, your profile, and the way we score, including which model does it. If the company edits its search, your profile is updated, or we change how scoring works, you're scored again. Otherwise, you get the same number with the same reasoning every time a run of that search finds you.

How sure the number is

Next to the score, the company sees how confident that score is — high, medium, or low — with a few words explaining why it isn't higher. It's worked out by ordinary code rather than by the model, whose opinion of its own work I wouldn't put much weight on, and the code looks at four things, in order of how much they count: how many sources your profile was built from (GitHub counts for the most, then a CV, then LinkedIn), how many of the search's required skills your profile lists by name, how close your profile came in the first step, and how much evidence the profile rests on. If your profile was last updated more than 45 days before you were scored, the evidence portion counts for slightly less. So a good score with low confidence usually means the fit looks right but rests on thin evidence, and the way to change that is to give your profile more to go on.

What isn't in the score

The location and ways of working you set in your preferences aren't sent to the model that scores you. They're compared with the role by simple rules and shown next to the score as a short note where they don't line up; for example, that you're in another country and wouldn't relocate, and that note never changes the order of the shortlist. If you set a minimum salary, no company ever sees the figure; it only learns how many people on its shortlist want more than the range it published, and only when five or more people are on the shortlist. The roles you tell us you're interested in don't affect any company's search either. They're there so that you can see what you'd need for them, not to steer anyone towards you.

What each side sees

Until you say yes to a company, it sees its score for you, the reasoning behind it, how confident it is in the score, and whether where you live and how you like to work suit the role. It can also see your country when the role is in a different country, and whether you saved the search or liked the job. The full list is in the privacy notice. It doesn't see your name, how to reach you, or your profile summary. If you say yes, we'll collect your name, email, and full profile, including an analysis of your work, a summary, the skills and level we found, and any GitHub and LinkedIn data you've shared.

On your side, your list of matches shows the searches in which you scored 70 or higher, along with the company, the role, and the reasoning. Below 70, you aren't told which company or role it was, or the reasoning, because a company that scored you lower hasn't chosen to show itself to you. You can see how many searches have scored you, as well as your best score.

What you can do about your score

Since the score is built from your profile, the useful things to do are the ones that give your profile better evidence: CV lines that say what you did and what came of it, a README that explains what a project is and why it exists, a pull request merged into somebody else's project. When you connect a new source, you can update your profile straight away; otherwise, you can do it once a week. Any company search that runs after that and finds you will score you against the new profile. I've written two guides on this, one on how recruiters and hiring managers read a developer CV and one on what your GitHub profile says to an employer.

What it doesn't do well yet

The score can only be as good as the evidence behind it. An engineer whose best work is in private repositories and whose CV undersells them will score lower than they deserve, which is why the score comes with a confidence level, and why you can read your own profile and fix what it's built from. The first step is approximate, so it can occasionally miss someone. And if you tell us your profile is wrong, that goes to a person who looks at it; it doesn't change your score on its own.

If you'd like to see what your own work says, the page for engineers shows what a company sees before and after you say yes, and the privacy notice lists all of it.