LinkedIn Assumes Skills And It Is a Problem

booleanstrings Boolean Leave a Comment

From LinkedIn Engineering:

“Don’t confuse skills with “that list of skills you entered on your LinkedIn profile”.  We intuit skills from MANY places.  For example, we will give you “credit” for a skill if you:

-Have it in your profile some place.  We convert all the text in your whole profile in to one big field behind the scenes and use it to keyword search for skills. 

-Have it in a resume we have access to (this is permission dependent).  We scan resumes for skills. 

-We also “give credit” for skills based on connections at times. (!!)  So, let’s say you have a bunch of connections, and you are all “similar” profiles, and all those other folks have X skill, and you don’t.  We will “infer” that you have that skill.”

(Bold is mine – IS)

Let me show you what happens.

Developers in El Cerrito, CA (where I live) with:

  • keyword = javascript — 430 members
  • (LinkedIn) skill = javascript — 416 members
  • Self-entered skill = javascript — 347 members

I.e., searching by “LinkedIn Skills” in that wider sense outlined by the Engineering have found 97% of members with the keyword. The stats are similar if you use other keywords for skills.

How is this useful? I am glad we have the hidden skills: operator to search for self-entered skills.

It is not too early to sign up for our most extensive

Seven-Day Talent Sourcing Bootcamp for Recruiters,

starting on June 4, 2024.

Exclusively for Technical Recruiters

booleanstrings Boolean Leave a Comment

Sourcing Software Developers? There is no better place than Github. And our tool, GitHub User Search, is the best tool for finding lists of Developers. I want to tell you how to integrate it into your sourcing process by combining it with LinkedIn.

First, search with our tool. The search syntax is complex. But typically, you will only need to search for:

  1. Programming language, e.g. language:python
  2. Location in every way you can think of spelling it out, e.g., location:SF location”San Francisco”

Example: language:java location:NYC location:”New york” location:NY.

You can also search for keywords, but note that Github does not have a field for the job title, and few have filled out the company field.

As a result, you obtain an Excel file with up to 1,000 records with these fields:

  • Username
  • URL
  • Name
  • Company
  • Location
  • Bio
  • Social (up to four social profiles and a blog URL)
  • Number of followers
  • Emails  (which we discover and provide).

You can also search several times in different ways to merge the exports for further processing.

Some of the records would already have LinkedIn profile URLs. You can collect the URLs, run them as a batch with SalesQL, filter, and review the output. This makes part of your ready-to-email list of potential candidates.

Then, if you have LinkedIn Recruiter, upload a CSV file into a designated project with a list of all the emails from the export and any first and last names (the names do not matter). This will cross-reference the batch against LinekdIn and let you search within it, creating an additional distribution list.

Email is a unique identifier, but you can also work with other information within the records. For example, you can search on LinkedIn for the location and the language name plus an “OR” of first and last names from the export in keywords.

This makes for a productive, fast process with rich results. The combined information collected from LinkedIn and GitHub facilitates personalizing the outreach.

We will be running various scenarios of the tool usage along with tons of other material in the upcoming in-depth

Three-Day Tech Sourcing Bootcamp

 (March 26-28, 2024, Tuesday -Thursday)

Please see the full agenda and register on the site – and hurry! Only a few seats are left.










Unlocking a New World of Sourcing : A Bigdata Approach

booleanstrings Boolean Leave a Comment

Guest post from Ashfaq Ahmed.

Continuing from my previous post – Death of LinkedIn X-Ray, What next?

Before talking about Bigdata concepts, let me demystify a common sourcing myth that is widely prevalent in the industry:

“There is no one approach to sourcing. Everyone can have their own strategies/approaches.”

If you’d be interested in why such a thought process is prevalent in the industry, read my linkedin post (to keep this blog short, I’ll jump onto Bigdata concepts).

Bigdata concept is nothing but a structured approach to organizing your data sets and addressing them as small & unique data slices, one at a time.

Your candidate data is scattered in so many forms & shapes, because of which we think & believe there isn’t one sourcing approach. However, the reality is that there is some structure/shape to how candidates’ data is presented.

For example, assume you are getting a Software Engineer role with C#,, SQL, Rest as skills.

Below is a visual representation of how candidates would have presented themselves on a platform like Linkedin. It is a probabilistic view of their representation; some would have written all 4 skills, some 3, etc.

Note : Red means they don’t have that skill on their profile but have the rest.

When some anchor skills aren’t present, like “,” the data becomes noisy, meaning it can bring irrelevant profiles. The data noise increases further when more than one anchor could be missing in a profile, like the below image

So, this is how data slices can be built based on how candidates write. For data-abundant roles on a platform like LinkedIn, one can build 100+ unique searches to spot candidates in different forms & shapes.

Sourcing does have a structure, form and shape. It’s about understanding your Persona of the role, how your data is presented & chalking out data-slicing strategies.

For the last 8+ years, I’ve been training these to tech recruiters & have been actively writing about this on my LinkedIn. Feel free to reach out to me on LinkedIn if you have any questions or if you’d like to know more.


Death of LinkedIn X-Ray, What Next?

booleanstrings Boolean 1 Comment

Guest post from Ashfaq Ahmed.

I got on a call with Irina & David & we discussed how sourcing will be impacted in the Post- X-Ray era.

First things first, why were we able to access LinkedIn via Xray before? Because when you’ve logged out from LinkedIn and visited a profile via Google, the profile data was more or less similar to what you saw when logged in.

Now, LinkedIn didn’t want scrapers or even Recruiters to access their data from search engines, and thereby, they changed the UI of Public Profiles by hiding almost all crucial data.

Sourcing Tools :

This change will not affect Large enterprise sourcing tools because they never relied on Google/Xray for scraping data at scale. Most Sourcing tools buy data from large data providers like Brightdata and others.

Recruiters :

In the post-x-ray world, if recruiters have to master something at all, then it is their foundational sourcing. Knowing to write a good boolean is just one step, and the others are – strong personal understanding + Big Data Concepts in Sourcing.

The Big Data concept is nothing but the ability to write mutually exclusive searches for a given JD. For instance, you write Devops & you spot 10,000 candidates. Can you slice this data into 10 search buckets, each consisting of 1000?

Such data slicing helps you organize your sourcing approach & classify your data based on the efficacy of results.

In the next post, I will touch on the details of how to implement big data concepts with an efficacy framework. Meanwhile, want to test your tech sourcing skills? Take up a couple of quizzes right here:


Google’s filetype: Decline and Workaround

booleanstrings Boolean 1 Comment

The Google advanced search dialog still shows file types:

But search using the operator filetype: and keywords no longer works. For example, filetype:xlsx attendees returns all sorts of pages.

For now, you can use a workaround: filetype: will still work if your search contains either site: or inurl: operator. We can use them with the minus, essentially excluding nothing, like this:

We all wonder how long Google will support its operators (I will need to update the operator list).

[edited] Danny Sullivan says it is probably a bug.

I Want My Profile To Be Public, But I Have Lost Control – So Have You

booleanstrings Boolean 6 Comments

LinkedIn X-Ray is gone (or soon to be gone, depending on your location).

So, what did LinkedIn do?

The screenshot above shows my LinkedIn public profile settings.

For the majority of members I know, the settings are the same. We want to be found on Google and Bing, which the UX promises.

However, this is my experience and education on the public profile. Profiles all went to “extreme privacy” starting about a month ago. Most data went to the deep web, which search engines cannot access.

1. Members were never informed of the changes – or asked whether we wanted them.

2. LinkedIn Help still says we are in control. Not true.

Here is a quote in response to my inquiry from a LinkedIn Engineering Director:

“Our trust team is rolling out (As they always have, none of this is new, it is an ongoing thing) changes to what is visible in public profile.  The idea behind public profile is to identify a person, to decide if that person is someone you wish to connect with, or reach out to.  If you want to connect, then of course that person can choose to accept or decline.  Same with messages and outreach.  But all of this is being done for member trust and member data.  Members expect us to help them control exactly where their data shows up, is used, and how it appears.”

This – Members expect us to help them control exactly where their data shows up, is used, and how it appears. – is exactly what has stopped happening. And it is new, and unfortunate.

How does it support our trust in LinkedIn? is a question for LinkedIn’s Trust Team.

Join us at the brand-new class

LinkedIn Sourcing in the Post-X-Ray Era

on February 28-29 and figure out how to source in the new circumstances.

Sales Navigator Revelations and Function Codes

booleanstrings Boolean Leave a Comment

The death of X-Ray prompts everyone to study LinkedIn’s search closer.

LinkedIn’s Sales Navigator has different algorithms from both Premium and LinkedIn Recruiter. There is no good reason for that. Different Developer teams fell out of sync.

Sales Navigator “thinks” most of LinkedIn. (I am being sarcastic.) It has a huge population of

1,665M+ profiles.

What are the 665M profiles unaccounted for in other accounts and in press? It is hard to say. In 2022, I posted LinkedIn Software Crisis (a Summary). At that point, LinkedIn Recruiter showed 400M “extra” profiles. It was a bug, that was fixed then due to the post and subsequent connection with an Engineering Director for LIR. Maybe it is the same bug in Sales Navigator, counting uploaded resumes as profiles.

Despite that, I think Sales Navigator is a fine choice for sourcing. It has a nice set of search filters. If it understood the hidden operators, it would be awesome. But it does not.

What I like about Sales Navigator is its search URLs. They are “readable,” can be shared, and expose various internal codes.

For example, I selected every function in the search, and from the URL, got this list of Function codes, which are not officially documented:

Accounting = 1
Administrative = 2
Arts and Design = 3
Business Development = 4
Community and Social Services = 5
Consulting = 6
Education = 7
Engineering = 8
Entrepreneurship = 9
Finance = 10
Healthcare Services = 11
Human Resources = 12
Information Technology = 13
Legal = 14
Marketing = 15
Media and Communication = 16
Military and Protective Services = 17
Operations = 18
Product Management = 19
Program and Project Management = 20
Purchasing = 21
Quality Assurance = 22
Real Estate = 23
Research = 24
Sales = 25
Customer Success and Support = 26

The secret operators do not work in SN, but you can use these codes in Recruiter or Lite with the operator functions:.

As always with LinkedIn-computed data, there is a warning. LinkedIn is not good at interpreting its data. Lots of members do not have functions assigned. Sales Navigator shows 1BN results without functions. It is 2/3 of the profiles. Since it has some ghost profiles, the high number may be the consequence of that. But always make sure that some of your searches do not include calculated values such as function (or seniority, etc.)

LinkedIn, unfortunately, falls behind in these AI times. No matter what account you use, it is best to use Boolean search where possible and understand how selections work.

Our latest webinar LinkedIn 2024 Solved is up-to-date.



LinkedIn X-Ray No More. Now What?

booleanstrings Boolean 2 Comments

Last week, Google has adjusted its index. It no longer finds me and many others by the Headline, About, Experience, and Education.

Bing is in the process. It already does not find some profiles:

Any search engine is affected. (A search engine does not have a LinkedIn login, right? Even if Microsoft owns them both.) X-Ray has lost its power. If it “works” for you, it is only a matter of days, maybe a few weeks before it stops. And it will no longer find updated info on profiles, i.e., your results get outdated daily.

X-Ray going down is a new challenge to respond to!

Nobody has data comparable to LinkedIn. Many would love this not to be the case, but such is life. Because a Premium account does only partial indexing, in order to source within, you need to have LinkedIn Recruiter, Lite, or Sales Navigator and learn how they search. It is not straightforward and is poorly documented. Learn how to search on LinkedIn in our comprehensive class.

You can also X-Ray the shallow data and go from there.

A productive way to source is to come to LinkedIn with some data collected to cross-reference. It can be emails, names, and other things you find outside of LinkedIn. While names are not unique, running a long OR of names combined with what you know about your target profiles, such as industry keywords or companies, can narrow it down to your prospects.

If you are after Software Developers, try our GitHub User Search Tool – no login required. (But please make sure you read the Help!) Once you have the data, go to LinkedIn to cross-reference.

How do you assess continued access to the full profile data if you are using a search engine or an outside system? Here is what I recommend. To (collectively) test how well systems deprived of LinkedIn profile public data will perform:
1) Change YOUR LinkedIn headline
2) Set up alerts on search engines and systems to check whether and when they will catch up, i.e., search for yourself with the new headline in keywords.
Let us know what happens 😉

Join us at the brand-new class

LinkedIn Sourcing in the Post-X-Ray Era

on February 28-29 and figure out how to source in the new circumstances.

The Adventures of X-Ray Are Mysterious

booleanstrings Boolean Leave a Comment

I have “Saved As” my public LinkedIn profile, and it looks like this:

This is my “Experience” and “Education.” Nothing much is visible without logging in. A large percentage of profiles look the same.

But things are in flux on the web.

Google LinkedIn X-Ray is back!

Mike Santoro has noticed. We think it is temporary.

In his post, Marcel has a screenshot of this search, pulling words from my now-hidden public LinkedIn profile: social list elsevier sourcing training verge brain gain. Here is Marcel’s image;  Google could not find me two weeks ago.

Here is today’s screenshot. Google has reverted to the previous Index state of the page! I believe it is currently true for all public profiles.  You will find them all.

Custom Search Engines have not been affected all along. Yet.

Bing finds me, but without a name (and finds my two partners):

It shows me again on page 3, with a location of “45K followers:”

Locations are pretty messed up in Bing’s snippets for most profiles.

It’s unclear what has happened with Google’s Index. Common sense dictates that Google and Bing will adjust to redacted profiles in the future.

It’s an adventure! To search on LinkedIn correctly, consider getting a recording of the recent class,

LinkedIn 2024 Solved.




The Best Github Tool In Industry

booleanstrings Boolean Leave a Comment

Guest post from Julia Tverskaya.

Are you a Technical Recruiter? Are you looking for Software Developers?

On January 16th, Irina announced a new GitHub search and export tool in her LinkedIn article.  We are happy to report that the tool has immediately attracted hundreds of users and we hope many more will discover its value.

The GitHub User Search tool empowers sourcers to find, export, and contact GitHub users. Our email search is optimized to be as precise as possible. You can find and export up to 1,000 results in each run. At this time, we do not require a login. There is nothing comparable available in the industry.

However, using the tool efficiently requires a solid grasp of GitHub’s search, including its peculiarities and constraints. Although the tool’s help page provides guidance, errors still happen.

Let’s look at the most common mistakes to help you improve your searches.

Qualifiers (GitHub search operators) are your friends!

GitHub search distinguishes between searching users’ general information, such as their names and bios, and searching within special fields. Keywords are used to search in general information; reserved words called “qualifiers” are used to search in fields. These fields include a user’s primary language and their location, parameters Sourcers are interested in.

Not using qualifiers, or using them incorrectly, leads to getting poor results – or in some cases, not getting any results. Here’s how to use the qualifiers correctly.

Searching for location

Use qualifier location:

This qualifier directs the search to exclusively examine the location field in users’ profiles.  Without this qualifier, any geographical term used in your search query is treated as a general keyword. Consequently, the GitHub search engine would only scan through keyword-searchable fields like usernames and bios.

Let’s say we are looking for users with experience in AI who live in Prague.
This search: AI location:Prague specifically targets users who have indicated Prague in their location field. It returns 89 results.
Compare it with AI Prague which returns only 20 (the ones where “Prague” is used in the users’ bios). 

Searching for two locations or different spellings of the same location?

Use qualifier location: twice, e.g.:  AI location:Prague location:Praha searches for users with AI who spell their location as either “Prague” or “Praha”. 

Searching for a programming language

Use qualifier language:

This qualifier allows you to refine your search for GitHub users by their primary programming language. For example, to find users proficient in C++, use: language:C++

Compare these two searches looking for users who live in Latvia and whose primary language is JavaScript:
location:latvia language:javascript returns 619 results. 
location:latvia javascript returns 49 results – all people who mention JavaScript in their bios. Not only did we get fewer results, we cannot be sure that JavaScript is indeed their primary language.

Searching for different languages?

Use the language: qualifier twice. E.g, to find people in Latvia whose primary language is either C++ or Python: location:latvia language:c++ language:python

Using Boolean operators in GitHub searches

While the Boolean operators AND, OR, and NOT are fundamental in many search contexts, their application in GitHub searches comes with specific considerations.

  • Keep it simple

GitHub’s search engine is designed to interpret only simple boolean expressions. Parentheses do not work (the search will not return any results). Combining operators AND and OR in a single query often leads to unexpected results, and we do not recommend it. 

  • Boolean with qualifiers is restricted   

The words “AND”, “OR”, and “NOT” can only be used with keywords and in: qualifiers (in:email, in:name, in:login). You cannot use them with other qualifiers. AND and OR are always implied, and NOT is expressed as a minus sign. 

For example, “java developer” AND location:barcelona does not return results because the qualifier location: cannot be used with the operator AND. Omit AND to get the desired result: “java developer” location:barcelona (remember, AND is implied).

Do you remember how we looked for people whose primary language is either C++ or Python? language:c++ language:python (OR is implied). language:c++ OR language:python does not work.

The operator NOT is always expressed as a minus sign when used with qualifiers, e.g. location:”estonia” -location:”Tallinn” returns people who live in Estonia but not in Tallinn. 

Because we cannot use AND and OR with qualifiers, some searches are simply not possible.  For example, we cannot search for users whose primary language is Java and who also mention Java in their bios. language:java AND java returns an error (and omitting AND is interpreted as OR by the Github internal algorithms). 

Our help page contains additional details and examples of Boolean search. 

Final notes:

  • Boolean operators are always capitalized: AND, OR, NOT
  • There is no white space between the minus sign and a search term, e.g. -language:javascript
  • Qualifiers are always lowercase: location:, user:, fullname:, etc.
  • There is no white space between most qualifiers and the search term, e.g.language:java, location:london, etc. 
  • Do not forget about the colon after qualifiers, e.g. repos:, followers:, etc.

Do you want to learn more? 

Sign up for our three-day tech sourcing bootcamp for an in-depth discussion