When you join cord, your profile will be automatically hidden from your current employer.
Apart from this, your profile is visible to all companies actively using cord as a default, but you can hide yourself from others, which will prevent your profile from ever appearing in their streams or from being otherwise searchable.
It does not have to be your current employer exclusively - you control what's on the list.
You can block companies by navigating to your Privacy page, or when editing/adding experiences to your profile.
The list of companies available in the autocomplete in Privacy settings is driven by Clearbit's Company Autocomplete API.
At cord we work with a wide range of companies, including early-stage companies. We have noticed that the Clearbit API takes time to add younger companies to their autocomplete API. If the company that you want to block cannot be found, the input also accepts plaintext.
What does this block?
Blocking 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 blocked. 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
How it really works
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.