Project: Reduce signup bottleneck Type: 🚀 Feature User: 💁🏻‍♀️ People

Key changes

Candidates can hide themselves from a company when editing their experiences on their profile.

Candidates are automatically hidden from the current employer when they join cord.

Why?

When someone is looking for work on cord, we know that they'd prefer their current employer not to be able to see them. Up to now, this was always taken care of by the profile builders, who would godmode into a candidate's account to manually add the current employer to the blocked company list. This would add a few extra seconds every time a profile was built.

For users, the ability to hide yourself and add extra companies to that list always existed - but wasn’t in an obvious place.

What?

We've brought blocking controls into the candidate profile, so that when a user is adding or editing their previous jobs they can choose to hide their profile from that company, without needing to navigate to their Privacy settings. On their Privacy settings, they can see all companies that they're hidden from (as before), with the addition of the Linked to your experience label.

When a candidate joins cord, their current employer is automatically added to the block list in the Privacy settings, meaning PBs no longer need to do this manually.

How?

The logic for candidates to hide themselves from companies has been in place for years, but here’s a reminder of how it works:

Hiding yourself from a company prevents said company from finding you on cord. This is done by comparing the company's name against the companies that you have hidden yourself form. As there is a certain degree of variability in company names, we fuzzy-match the names based on the following criteria:

All characters are converted to lowercase

Non-alphanumeric characters are stripped (IE: spaces, punctuation, special characters)

A wildcard is applied to the end of the names of companies you have blocked

A wildcard is applied to the end of the name of the company

When adding the controls to the candidate profile, there were edge case scenarios for multiple occupations with the same company name (A)

Adding to unlist [blocked companies list]

Once an occupation is unlisted, all occupations with the same company name should show as unlisted on the candidate profile

However, there should only be 1 result on the candidate's unlisteds page

Removing from unlist

Once an occupation is unlisted, all occupations should show as not unlisted

Result should be removed from unlisteds page

Renaming

Once an occupation is renamed from A to B, all A and B occupations should still be unlisted.

A and B should both appear on the unlisteds page

Deletion

If an occupation is deleted, the unlisted will still exist until all similarly named occupations are deleted

The hard link in the db will be transferred over if the hard link id is the deleted occupation

Creating new position

If another occupation named A is created, if it is unlisted as well, the hard link should transfer over

More information on the criteria

Let's dive into what each criteria does:

#1 All characters are converted to lowercase

This is straightforward. It allows us to match viagogo against Viagogo

#2 Non-alphanumeric characters are stripped

This ensures Signal A.I. is matched against Signal AI

#3 Wildcard is applied to the end of the names of companies you have blocked

Occasionally, company names will contain additional terms such as hq, .io, ltd or uk.

If you have blocked Vonage, if the company Vonage UK attempts to search for you, they will be blocked from doing so

#4 Wildcard is applied to the end of the name of the company that is looking for engineers

This is the inverse of #3. If you have blocked faceitltd, if the company faceit attempts to search for you, they will be blocked.

How did we decide on these criteria?

In order to decide the matching criteria, we first established what we wanted to optimize for:

Of the above, the False Negative case is especially important as Engineers may not want their current employers to know that they are considering external offers. False Positives are not ideal, as the Engineer would not be searchable by a company, but the consequences were not as severe as the previous case. Hence, we decided to take a more cautious approach and aggressively apply the blocking (and matching).

Having established our priorities, we set out to test a few different approaches in a data-driven manner:

No wildcards

Wildcards on both the start and end of company names

Wildcards on just the end of company names (the chosen approach)

Levenshtein distance matching

Approach #1: No Wildcards

False Negative performance was 38% worse than Approach #2. Did not perform well as it failed to match simple cases like redkitecrm to redkite

Approach #2: Wildcards on both the start and end of company names

This performed well on the False Negatives front. However, the False Positive right was 12% higher than Approach #3. Incorrectly matched natwestinternational to stint

Approach #3: Wildcards on just the end of company names

We noticed most of the False Negatives in Approach #1 was due to additional end terms in the name of companies, e.g. hq, .io, ltd or uk.

This performed equally as good as Approach #2 in terms on False Negatives, and performed better on False Positives as it did not fuzzy match terms like vitescotechnologies to tesco

Approach #4: Levenshtein distance matching

Levenshtein distance is the minimum number of single-character edits (insertions, deletions or substitutions) required to change one word into the other (wiki). Levenshtein is generally quite useful for fuzzy matching and spell checking.

We tested a few Levenshtein thresholds. Even under the most optimal threshold (3), this approach yielded 10% higher False Negatives and 62% higher False Positives. This was likely due to a few reasons. First, the company name inputs were mostly structured data (from the Autocomplete API), and hence the problem at hand was less to do with incorrect inputs (IE: google being mistyped as googlea. Second, as we have already seen above, mismatches were mostly due to additional end terms being attached to the end of company names. Longer end terms were not accurately matched. IE: mirriadadvertising to mirriad

Although we did not investigate further, we postulated that other word stem and corpus-based approaches would yield the same outcome as company names are generally portmanteaus or non-standard dictionary words. In the future, it would be interesting to create a custom corpus and explore this direction.

Thank you!