(Can I please ask you to read to the end?)

It has eventually become such a mismatch in terminology. Most people in our industry refer to search strings on Google as “Boolean Strings”. However, the term “Boolean”, meaning AND, OR, and NOT, no longer applies to Google search best practices, and less so every day. Practical Google search strings do not use ORs and rarely use the minus –.

This similarly-styled string (submitted yesterday to our NING site as a “favorite”) is also full of syntax errors – and finds no results:

I started this blog in 2008 and “Boolean” was different back then. Should I feel sad? We search about 40% of the time and our clients like the results, but the last time any of us used a single OR on Google was years ago. We now use the term “Boolean Strings” meaning “advanced search.”

Do not take me wrong, Google is the best search engine! Using advanced operators, especially, X-Ray (site:), is a must for any Sourcer, Researcher, or OSINT practitioner. Note that Google no longer documents all the operators, most likely because a minority of us uses them. Its search currently shows the list on my blog as a “featured snippet”; I do my best to keep the page up-to-date. Dan Russell’s document is another source you can trust (he works at Google!) Many other sites – even search engine-oriented publications – list the wrong operators and copy from each other, unfortunately. It is your responsibility to apply an inquisitive mind and stay in the loop.

If you continue with ORs, especially long OR strings on Google, your results will be mediocre. Why? When Google sees ORs, it stops bringing up relevant terms. Instead of trying to take control, it is more practical to trust Google’s interpretations. As a popular (but not popular enough!) example,

• If you search for “software engineer” OR developer, Google will do exactly what you asked
• If you search for software engineer, you will find Coders, Programmers, etc. – results you would miss if you use OR.

Since Google has learned to interpret long quieries,  ORs have become even less productive. The semantic component in Google search is AI-based, meaning that it improves all the time, making results relevant – unless you “turn it off” with ORs and NOTs.

Clair (Milligan) Mohamed’s share brilliantly summarizes the situation:

(“Boolean Search” OR Boolean Search)

I was asked yesterday if Boolean searching works in an X-Ray search on Google.

A timely post by expert sourcer Irina Shamaeva in her Facebook group flagged up how many recruiters are still using Boolean Strings in their Google Searches when better results will come from more simple searches.

Google uses Semantic Search and coined the phrase “things not strings” as far back as 2012.

Since then their search has evolved to include NLP, machine learning, and BERT (super-advanced tech that interprets search in a more conversational way).

The old idea behind long ORs was that a clever search will “cover it all”. It puts “the” “Boolean String” as the goal. Indeed, a one-click solution sounds attractive! (We continue to get requests for “the” string for someone’s job requisition, sometimes as a matter of urgency.) The goal is results, not a string.

It is best to keep Google search simple 95% of the time – and search (anywhere) an iterative process. Every string leads to a new one and uncovers information to take into account. If someone “builds” a “string”, runs it on Google, gets the results, and stops, they are using the best search engine not in its best way. It is difficult and unnecessary (like eating soup with toothpicks. )

As a practical example, when you write senior OR sr OR snr OR principal engineer OR developer OR lead OR coder on Google – that is 16 separate searches with no interpretation, results are somehow mixed up – not what you want. Just software engineer is better!

A Facebook discussion is here.

And here are the shortest strings ever! (Dan says it is a bug) 🙂 🙁

• https://bit.ly/HappyString
• https://bit.ly/SadString

A more descriptive title of this post could be “Hack: Check Whether an Email Address or Phone Number is Registered on LinkedIn in 5 Seconds or Less”.

The “hack” does not reveal which member it is – it only returns a Yes/No answer. But it is a validation pointer for the contact phone number or email address you are looking to verify, or, in a different scenario, trying to guess the email or the missing phone digits. It is a “good to know” piece in OSINT research.

Since the death of the Sales Navigator URL hack, there is still – even improved – way to mass-cross-reference long lists of emails (as long as 9K+). But there is nothing as quick and simple as a login attempt to verify whether a single email address or phone is registered. That is, if the site “cooperates”. 😉

“Wrong password” – seen on two out of the four screenshots below – is a welcome response that reliably validates the contact data you have.

There is nothing new about the “research using login dialogs” OSINT approach. This post is an alert that it works well on LinkedIn right now. 🙂 These checks do not trigger any notifications either (but avoid entering the same existing email just in case). Enjoy them before things change again. (With LinkedIn, imminent change is the only thing we can be sure about, lol).

Looking for someone?

Looking for professionals whose social online footprint is minimal (common for  essential workers), or perhaps an old classmate or your backpacking buddy?

It is often hard to find people on LinkedIn:

• with “shallow” (barely filled out) profiles
• with outdated professional history or education
• spelling their name in different ways (or changing the name)

But if you have a guess at at the email address or found an old address, seeing “wrong password” means that the person likely uses the email – or phone – in question, (Gmail-based emails have the highest chance of being kept.) You can then find the person by email, see more info, and email them if relevant. Of course, not finding a LinkedIn member by phone or email is far from guaranteeing that the contact data is outdated – it can be either way – but it is also a data point.

To perform the hack:

Log out of LinkedIn. The rest is best explained by the four screenshots below.

This is how registered emails and phone numbers show up vs. unregistered, on the login page. (Type something random and long as a password and press “sign in”.)

Tip: Pace yourself (if you know what I mean)! If you start seeing cows or sheep to rotate, changing your IP address would help.
Automating the hack to run over a list of contacts would be a next-to-impossible task.

That’s it.

(To my readers: I do not know if there is a way to reliably identify someone by phone on LinkedIn – if you do, I would love to hear!)

“Hacks” make monotonous parts of research work quicker, add discoverability to data, and fun to work. 🙂

As a piece of news, David Galley and I are finalizing the 4th fully updated edition of the popular eBook, “Sourcing Hacks” (available for pre-order).

Join us for an interactive preview of an expanded set of Sourcing Hacks in the upcoming webinar this Thursday. Expect to learn a good number of new sourcing hacks we have uncovered. Attendance includes:

• the slides complementing the ebook’s examples
• video recording for you to keep
• get the ebook (as soon as it is ready) at a discount
• one month of online support.

If you learn from video, audio, or interaction and practice better than from reading books, this webinar is for you!

In 2006, Christian Mayaud came up with a genius idea of LIONs – LinkedIn Open Networks. There was no connection limit; you could see the exact numbers of connections on profiles and the 4th level connections. But then, as now, people outside of your network were “invisible,” shown in search as “LinkedIn Member” with no details – and you were invisible to them as well. Imagine a business gathering where you can only see people you know or people who know them – it does not make sense!

“LION” means that the person would not “IDK” – say “I don’t know you” to your invitation – which hurts your membership. LIONs have made the network much more connected.

It is everyone’s individual decision whether to add “LION” to your last name and commit to accepting all invites. (I am no longer one since my connections are almost at the maximum level of 30K).

But it makes sense to have at least 500-1,000 connections and include connections with LIONs (who are well connected themselves) for your visibility to others and being able to see more members, no matter what your profession is. It helps to do business and find employment.

The straightforward way is to invite LIONs. However, the number of connection requests you can send per week is now limited.

Here is how to connect with as many LIONs as you wish in one day. If you upload an email list (as long as 9K) to Contacts and invite from that upload, the number of invitations is unlimited. And all you need is a list of emails; names do not matter.

How do you get the email addresses? Many LIONs have them publicly visible. LinkedIn won’t search for “gmail.com” to find emails, but Google will. A search like site:linkedin.com/in intitle:LION “gmail.com” – plus any keywords you could vary to get more results – will produce lists fast. Go for “yahoo.com,” “aol.com,” etc., if you wish as well, or search for distinct company email domains like “fb.com,” “us.ibm.com”. Use Julia’s Email Extractor, which can collect emails from every page you visit (set the option in the extension) to get a long list in no time. (See David’s video demonstrating the technique).

That’s it 😊

Recruiters are aware that most job descriptions lack some information necessary to source potential candidates. A job description is written to attract talent, and it is only one piece of data for Recruiters. We gain the extra info and Hiring Manager’s preferences through intake write-ups and meetings.

We have designed our sourcing intake form Brain Gain Recruiting Sourcing Checklist to solicit that extra information. I find an “ideal candidate’s profile” (or two, or three) to be especially helpful.

LinkedIn Recruiter (LIR) offers searching by an ideal candidate. The idea is admirable, but have you noticed how it is implemented?

When you search by an ideal candidate, LIR does exactly the following:

• Sets an OR of the person’s job titles.

This means that you will be searching for past job titles, which could be more junior or even totally different from what you need.
I have a friend who once was an oboe player, then a database admin, and now is a speech therapist. If you are searching for a speech therapist, do you want to see oboe players?

• Adds an OR of the person’s companies.

Do you want to hire from the same companies? Most often, not – especially if the “ideal” person has worked at small companies or already works at the company in a similar role.

• Adds an OR of the person’s skills.

LIR’s skill search now looks (way) beyond self-entered skills; it finds people who have the skill keywords on the profiles. Therefore, skills search can only be separating good prospects from non-matching if you use an AND of skills.

• Adds an OR of the person’s industries – picked from the employers and jobs past and present.

But “Industry” is a tricky filter. For the majority of professions, choosing one industry does not cover the type of work people do. Then, some members enter their “role” industry (like “Staffing and Recruiting”) while others put the employer’s industry (like “Healthcare”).
For some suggested industry selections, you will not even find that ideal candidate. For example, a good friend worked in music production years ago, before becoming a Sourcer. If you search by her profile, a suggested industry is “Entertainment” – but you will not find her when searching for it!

“Search by ideal candidate” and other features of LIR require understanding how the search “really” works and how to overcome the limiting factors. The LIR Help does not explain that.

Join us for the LinkedIn Recruiter Mastery class next Thursday, August 5th, to get clarity on its search and learn to find promising profiles that may be hidden if you just follow LIR’s prompts. As always, you can follow up with questions for a month.

Reverse Image Search is a favorite way to find online traces of someone by their social profile photo.

But if you search by image on Google, you may be missing some results. Here is why and how to overcome that.

#1. When you upload an image, Google (annoyingly) shows its “explanations” – sometimes even offensive – like “hair loss.” For my friend @Infosourcer‘s Twitter profile picture in two different dimensions, it decides on “wildlife biologist” on one and “leisure” on the other. (Who needs this feature as it is?)
The “explanation” keywords is not an “innocent” addition, though – they affect your reverse image search.

Change the automatically appeared keywords to something meaningless – just “a” would work – to stop the results from being filtered. Or change them to the person’s name (or other terms) to “guide” the search.

#2. Did you notice how, in the example above, Google’s “approach” to searching by the same image in different sizes is inconsistent – it interprets the images differently? (Also note that “Find other sizes of this image” that you may see, as in the screenshot above, usually finds little.)

Searching by the same image from different sites or in different sizes often produces complementary results.

Let me demonstrate that using my business partner David’s LinkedIn profile photo as an example.
If I search by the profile photo, I find LinkedIn and a few other sites, including our CSE book on Amazon – but not the Twitter profile (which has the same picture).

But if I resize David’s LinkedIn photo to 200×200 pixels (as above) using a simple image editor, new results show up – including Twitter! If I search by the 200×200 image from Twitter, results vary again.

Summary for reverse image search on Google:

1. Remove or change Google’s guess
2. Use different image dimensions and the same image from different sites to uncover more results.

Bonus point –

How to see a LinkedIn photo without a frame

Some LinkedIn profile photos have #opentowork or #hiring frames. For reverse image search, these “stand in the way.” Images on public profiles have no frames, but LinkedIn often would not let you open the profiles without logging in. There are fun ways to see an incognito profile, such as view it with Google Mobile-Friendly Test.

But to find the image only, you can X-Ray the person’s profile in images, like so:

site:linkedin.com/in/jimstroud imagesize:200×200.

Last week, I ran a poll on LinkedIn- “Which site, do you think, is the best for sourcing Software Developers?” which attracted a massive 60K+ views and 1,400 votes.

It was a bit of a trick question. I had hoped to facilitate a discussion on combining sites for sourcing – and so it did (see the comments). Other sites were suggested, including Twitter. But most people just voted.

While the poll was intended for Technical Recruiters, it attracted Developers themselves (mostly voting for LinkedIn!) and others working in Tech. The “Other” votes included some folks who sell sourcing software 🙂

Here is a word cloud of the participants’ Headlines:

So – “which site is the best?” If I were to choose only one site, that would be LinkedIn. It is common sense: LinkedIn shows Software Developers’ job titles, companies, and years of experience and at the company. In comparison, Github does not have a field for job titles and few have filled out the company field. Stackoverflow and Twitter have free-form bios rarely disclosing the necessary info to prequalify someone for reaching out.

The fruitful approach is combining data across sites. This allows you to find prospects who will not be found on any (one) site – LinkedIn included.

As an example, someone who is popular and active on Github (but does not tell us where they work) with a “shallow” LinkedIn profile where they did not even mention programming languages, can only be identified through cross-referencing. And if you get their info from a “code authors” file, all you have is the name and email (plus you know that they worked on the project).

People aggregators like Amazing Hiring “pre-cross-reference” professional profiles for us ahead of time. That provides a productivity boost and ease of use – and I highly recommend trying them!

However, information in databases:

1. gets outdated
2. may not have the data for your particular needs or locations (that you can check during a trial).

You can do some “live” cross-referencing for free, targeting your requirements, and will pull today’s data. Check out the recent posts Who Are You? The Art of Cross-Referencing, Github Example, and How to Collect and Cross-Reference All Emails in Search Results for some ideas.

Our Scraping webinar next week will help if you want to dig deeper into cross-referencing – check it out!

I want to tell you a fast way to collect prospects’ email addresses from Google search results pages and then find the professionals on LinkedIn. The result is a target list of LinkedIn profiles for which you know email addresses. The method is free and requires no coding or being “technical” whatsoever.

See the steps in a fun 7-minute demo by David Galley. (We felt it is easier to follow a video than if I described each step in a post. )

Tools you will need:

1. Julia’s Email Extractor
2. Linkclump or similar (to open selected links in separate tabs)
3. Google
4. Basic LinkedIn.

David shows how to collect and cross-reference Kubernetes Developers on Github based on X-Raying “authors” files as a use case. (The demo is complementary to my latest Github Sourcing presentation sponsored by Amazing Hiring.)

We call digging under links “in-scraping.” It is available in some commercial scrapers, but the setup is not nearly as simple.

The demoed technique is wildly fast, free, and applicable to endless other use cases. Applied to Talent Sourcing, the technique is efficient in the era of remote work when candidates’ locations are less critical.

Join us for the upcoming webinar on July 28,

Web Scraping For Recruiters

and learn how to scrape simply for your productivity.

Google Custom (Programmable) Engines are capable of finding particular values (such as someone’s location or employer) precisely with the aid of special search operators. The precise filtering ability is based on the “objects” defined by Schema.org – such as Person, Organization, or Place – which site creators can embed in the page code. The “custom” search operators are written as more:pagemap:<custom addition> which you can shorten to more:p: 

There is no tipsheet for these operators since their syntax is often site-specific (unlike the 21 Google operators). This post can serve as the “next best” since you can alter and utilize the search examples. Also, check other (few) writeups, particularly this from my French friends Guillaume Alexandre and Pierre- André Fortin.

Expect a learning curve, but there is no coding involved.

Since David Galley and I are in the people search business, our research, book, tool, and upcoming webinar cover the object “Person” and its fields in detail.

more: operators allow you to search for specific values, as you will observe following the example links in the table below. But they also work to find pages with a given structure, regardless of the values (add your keywords):

• Pages including Person: more:p:person.
• Pages that have the Person object with a field Job Title: more:p:person-jobtitle

(As a side note, people have been telling me that our book title “Custom Search Engines – Discover more:“ is mistyped – it is not!)

At this time, social profiles on LinkedIn, Facebook, and Twitter do not follow a Schema format that CSEs can query. LinkedIn used to have “Persons” on profiles a few years back, but, alas, it has become inconsistent.

Here is a collection of site-specific Person example searches. It is followed by searches across sites (using a “find everything” CSE). Open-ended searches across the web can find “Person-friendly” sites for your research.

I constructed the below examples using Social List, a CSE API-based tool that hides the operator complexity from end-users and collects results in Excel.

Join us for an interactive two-part class, Become A Custom Search Engines Expert, on July 20-21 and learn about the unique technology. Attendees will receive the slides, recording, and one-month support. The webinar is recommended to Sourcers, #OSINT practitioners, and anyone familiar with advanced Google search and, in particular, X-Ray (the site: operator).

Yesterday I saw a recruiter’s post on Facebook asking for advice on how to figure out which candidate had texted them when they couldn’t see the name, only the number. (Has it happened to you?)

A recurring problem in sourcing is dealing with insufficient information. You want to reach out only to relevant people, but the data (say, a Github profile) does not have the essential info such as a job title, company, and often, even location. Emailing everyone who lives in Boston and writes in Java will unnecessarily bother senior managers, students, professors, retirees, people who just started a job, etc.

Let’s commit to being spam-free!

The solution to finding the missing qualifying information is cross-referencing – done by you or by software.

The obvious site to look for professional parameters is LinkedIn. And now it has become possible to find everyone by a registered email, no matter which type of account you have – Basic’s fine – by uploading an email list to LinkedIn. The list can be as long as 8-9K records, and you do not even need the first and last names. (Repeat if it didn’t work.)

Here is the process.

1. Start with a Github search like the above and collect (public) emails. Instant Data Scraper, one of my favorite Chrome extensions, can do it, or use Julia’s Email Extractor along with Autopagerize (all marked with an Asterisk in my tools list.)
2. There is a wise intermediate step to take before you start the list cross-referencing. In the  Instant Data Scraper search output, you will find locations and bios – you might want to filter by that first. After cross-referencing, the extra data will be “gone” – and some people will not say on LinkedIn profiles things they did in Github bios. (Also – if anyone in the Github list stands out, check them out right away.)
3. Upload the email addresses to LinkedIn the new way, and you will arrive at a list of profiles with professional info for people for whom you already know a lot:
   • Programming languages they use (or even their numbers of repositories or followers or other Github search filters)
   • Their email address
   • Their LinkedIn profile

The idea of cross-referencing is not new, but the current improved “Contacts” functionality makes the technology available at scale.

Note that their LinkedIn profile may be “shallow” and lack the programming languages listed – but you know that they use, for example, Golang, from Github. You will be surprised how large the percentage of those “LinkedIn-shy” Github users research shows. This means that you will be steps ahead of those colleagues who still only source on LinkedIn: your results will include potential candidates who are “invisible” on LinkedIn!

The advantage of the described method is that it comes at no cost and provides the most up-to-date data. It can also be easily generalized in application to any email list, no matter what the source. (Keep the intermediate “filtering” step in mind for better targeting.)

People aggregators like AmazingHiring do this profile association for users ahead of time, eliminating hands-on cross-referencing and including sites with professional data beyond Github and LinkedIn. (I first wrote about aggregators in 2011, calling them the “Dream Software”).

I am glad to invite you to a webinar on July 14th,

Github – Recruiters’ Paradise

sponsored by AmazingHiring, where we’ll go over this and other endless Github sourcing possibilities.