A Stellar Addition to Our Team!

booleanstrings Boolean


Photo: David Galley, me, and Martin Lee – from Oscar Mager’s Sourcing Summit Europe – 2015 album.

I am very happy to announce that my good friend and colleague Martin Lee is joining us full time as Head Instructor at Sourcing Certification and  Partner, EMEA & APAC at Brain Gain Recruiting.

Martin and I met at the second #trulondon event (very un-conference style) back in 2010, have stayed in touch, met at conferences (including all of Sourcing Summits in Europe) and training events, and collaborated since.


Martin is highly regarded as a sourcing thought leader in Europe. He has almost 20 years direct sourcing experience working with some of the world’s largest companies providing them with rare and difficult to find skills. He has trained inhouse and agency recruiters and advises global organizations on direct sourcing techniques with considerable experience in mapping target companies, competitor analysis and data mining. He sources globally with significant experience across EMEA & APAC with hands on experience of the differences in culture, tools and methods.

Before joining us at Brain Gain and Sourcing Certification Martin was VP, Head of Sourcing & Research EMEA & APAC at Kelly Services where he oversaw all sourcing and candidate engagement strategies. He understands the differences in recruiting across different countries and remains a hands on sourcer whilst consulting with Brain Gains customers on best practices. (I know the various country-based teams at Kelly will miss him!)

Welcome, Martin!


P.S. If you are an agency recruiter, check out our first upcoming joint webinar with Martin (just posted on our sourcing training site): How to Find Clients and Vacancies for Your Recruiting Agency.


The Boolean Basics – Webinar 17 May 2016

booleanstrings Boolean


(Drawing by Sourcing Certification Staff Artist Peter Friedman.)

For EVERYONE who searches for qualified professionals as part of their job (You!):

If the last class you took on Boolean searching was over a year ago or if you have never taken one, join me to the upcoming webinar on the Boolean search.

Did you know that:

– You shouldn’t use ‘AND’ when searching on Google?

– Google automatically includes variations of all keywords – and may “decide” to drop some keywords as well, unless you “tell” it not to?

– By excluding “jobs” in Googling you may also miss some resumes?

– LinkedIn has four different syntax rules for the same search box, depending on what you are looking for?

Knowing the correct search syntax and the unwritten rules on how various sites interpret your search strings is critical to finding the right results fast.

In 2016, we are seeing more professional data available in search and some shifts happening in how Boolean search works on various sites – let’s make sure we stay on top of all changes! Due to the introduction of #RankBrain, the best Boolean Strings are different from what they used to be.  It’s time to update your strings. Long OR statements are inefficient and produce fewer results. Using “Boolean Builders” are going to decrease your performance – it’s best to craft your searches “by hand”.

Sign up for the webinar on Tuesday May 17th with an optional hands-on practice on Wednesday May 18th to learn and stay on top of the best ways to search –http://sourcingcertification.com/booleanbasics

As always, we provide all the materials for you to keep, including a Boolean Tip Sheet, and one month of support. Hope to “see” many of you there!

Facebook Hacking (Searching for Job Titles and Employers by IDs)

booleanstrings Boolean


Due to the main professional social network not meeting our expectations on several fronts, there’s a growing interest in sourcing on Facebook. As many people are already aware, the Graph search is “officially” gone but still exists in the back-end. @TheBalazs has two great posts on using Graph search:

Most of these techniques continue to work, though some ways to figure out Facebook IDs are gone.

Here is a write-up on how to search on Facebook for employees of a company and for people with a given job title. Be warned though, that Facebook search is far from being precise, meaning:

  1. Depending on the search, Facebook may decide to include synonyms, and we don’t have a “verbatim” option to stop it from doing that.
  2. Facebook won’t return “all” results on most searches; we will likely get representative results. (Of course, that is true for Google searches as well).

Facebook Graph searches exist in two formats: 1) searching by strings and 2) searching by Facebook IDs. For job titles and company names you can, quite often, use both ways to search, and will often (but not always) get different results. In some cases (but not always) searching by IDs is more precise, meaning that there’s less interpretation compared to searching by strings.

The formats for searching by strings and IDs look like this:

Note, also, that some job titles and companies have more than one ID to choose from, and we’ll get different results for different IDs. (Try searching for Quality Control as a job title, for example, and you’ll see). On the other hand, some job titles won’t have IDs; for example, there is no ID for a Sourcer – in those cases searching by string is the only option.

Shane McCuscker’s popular Facebook search tool constructs “searching by string” queries.

Search is Back! by Michael Morgenstern provides a mix between searching by strings and by IDs. Michael’s tool has a good-sized database of company, title, and school IDs in the back-end, but it doesn’t provide many existing IDs (providing “any” ID is probably an impossible task anyway).

If you want to search by IDs yourself and need to find them for that purpose, here is how to do that. Pages on Facebook fall into two categories. The first kind has the ID as part of the URL – those pages are usually auto-created by Facebook (sometimes copying the content from Wikipedia). Examples:

The second type is “man-made” pages that don’t have the ID as part of the page; examples:

When you are looking for an ID to use, there are two steps: finding the page and finding the ID.

To find the page representing a title or company, you can just search in the FB search box and narrow to “pages”. Or, you can search in the Pages Directory. Or, you can search this way: https://www.facebook.com/search/more?q=keywords (replace keywords with your terms).

If the resulting page URL contains the ID, you are done!

If it doesn’t, you can look the ID up in the HTML source code (search for page_id=). Or, you can use any tool that provides Facebook IDs based on URLs (they usually say they find “your” ID, but they do work for any page).

Once you have the ID, replace the number 4 in this URL by the ID to find people with given titles or working at a given company:


Have fun!

For a deep dive into Sourcing on Facebook, check out the upcoming Webinar on Social Sourcing on May 11th, with optional hands-on practice on the 12th. As always, we provide a month of support to help everyone practice.


How To Find Unemployed on LinkedIn

booleanstrings Boolean



Not everyone who has lost their job and is looking would openly put this information on their LinkedIn profile, but people many do. Here are some ways to search for LinkedIn members who have said that they are unemployed.

Searching for people with no present job is not possible with any LinkedIn account. We can try to find those people by X-Raying. Those members, who do have a current job, have the word present on the profiles; the current job dates look like this:  – Present (4 years 5 months). Here is the X-Ray string, that excludes employed people:

site:linkedin.com/in OR site:linkedin.com/pub -pub.dir -present <add keywords>

Searching this way, we’ll miss the profiles of people who are not working but have the word present in a different profile section. (If you were wondering, there are about two million profiles containing the keyword present; that is about 0.5% of all members). We’ll also miss public profiles, for which users have adjusted the settings not to show their jobs. But the majority of profiles with no present job will be visible to Google. Here’s an example search:

site:linkedin.com/in OR site:linkedin.com/pub -pub.dir -present recruiter sourcer “greater new york”

If we are searching for profiles in a different language, we would need to adjust the search accordingly; for example, X-Raying for profiles in Russia would look like this:

site:ru.linkedin.com/in OR site:ru.linkedin.com/pub -pub.dir -“настоящее время”

However, the majority of unemployed people are “employed” in LinkedIn’s “speak” (and do have the word present on public profiles): they choose to put the word unemployed or its variations either as their current company name or current title. (LinkedIn doesn’t offer an “unemployed” status. It does have a special type of account for people who are looking for work but it doesn’t have a search function to find them. Not very helpful…)

Due to those members’ entering an employer’s name that means they don’t have an employer, LinkedIn has lots of “companies” with the name including unemployed; there are other “companies” with names like “looking for a new opportunity”, etc.

So here are some searches for unemployed people on LinkedIn:

Of course, we can also search for “open to new opportunities” and the like in the keyword field.

Note that we won’t be able to search for company = “not currently employed” (or anything containing the word not, even if it’s NOT capitalized). We can’t search for phrases that include short words that LinkedIn search ignores. Similarly, we can’t search for company=”in transition”. Another “company” or job title to search for would be available, but be prepared to also see everyone who is “not available” in the results – there’s no way to exclude not.

If LinkedIn starts allowing to search for those who are looking for new opportunities – at least for those who are paying for the “job seeker” account – I’ll update the post!

Verify Mobile Numbers Using Facebook

booleanstrings Boolean


Mobile phone numbers and personal email addresses both uniquely identify people. If we can locate social profiles tied to a mobile number or email address, that would serve as verification of this data; we can also get additional information, helping us to decide whether to try to connect with the person regarding a job opening or a business deal.

Many sourcers know that if we have an email address, we can identify the individual’s profile on LinkedIn using Rapportive. We can also determine the person’s Google-Plus and Facebook profiles by just pasting the email address into the search bar:


Few people know that it’s also possible to identify a Facebook profile by entering a mobile phone number. As you can see from these screenshots, Facebook “understands” a variety of phone number formats.


(Note that this won’t work with landline phone numbers – those that don’t accept texting – because of the Facebook verification rules for an associated phone number).

For this verification to work, you must be logged into Facebook. For hackers out there, I’d recommend not to try to run long blocks of sequential numbers; Facebook would likely stop that activity pretty soon.

When we are logged out of Facebook, there’s still a way to find out if a phone number is registered with some account. Start by using the “Find your account” feature:


For a mobile number not on Facebook, we’ll be clearly notified: “No Search Results. Your search did not return any results. Please try again with other information.”

For a number that is registered, we would get something like this:


In some cases, Facebook will show the name and the image; in other, it will not.

(Feel free to use these “hacks”, but please don’t make people worry by triggering password reset requests, OK?)

Join me for a new webinar to learn everything about Sourcing on Facebook (and Twitter) – only one day left to register!

Where Is Semantic Search?

booleanstrings Boolean


I was preparing a “Boolean for everyone” presentation and went over general concepts of searching in databases and search engines. This made me thinking – why is it that the strongest semantic search we are seeing is in Google (where it’s very hard to implement because of the volume of data and diversity of web pages) and not in databases (where the data is structured, and its size is so much smaller)? The most “advanced” interpretation databases do, is convert VP to “vice president”; none I know of would search for ‘software developer’ if we ask to search for ‘software engineer.’

Let’s take a look at a simple search for a professional. I will try to find Software Engineers who write in LISP. This language is pretty obscure and has its fans (with some of whom I had good luck to work in my previous career). People who write in JavaScript and took LISP in college are not the ones I want to find.

Searching semantically would mean that the system understands the searcher’s intent. Let’s compare a search on LinkedIn and X-Ray LinkedIn on Google.

(LinkedIn) Current title=software engineer; keywords=lisp

The top result (for me) is a profile that says: “Over 5+ experience in the areas of Software Development, Design & Analysis of GIS Applications and Customization of CAD applications using C#, VB.Net , ASP.NET, VB6, Visual Lisp, VBA, Object ARX .Net & C++ and Arc Objects.”

It’s the wrong result for many reasons. “Visual Lisp” is not LISP at all in the sense I had meant; it’s a variation of LISP used in AutoCAD, to “program” geometry (forms and shapes of objects to make). The person uses a ton of other programming languages. And, the job title “Software Engineer” is “present” only because he forgot to put the end date on the last job; he currently is a “GIS Analyst.”

The second result is a “shallow” profile that has LISP among the skills; however, the person lists a certification for “Java SE 6” and did mobile development until recently – this was likely not done in LISP. (A quick search shows she’s the only one at her company with LISP on the profile.) Wrong result.

Let’s switch to Google. X-Raying is tricky. We have less control over results since we can only use keywords; unlike LinkedIn or another database that has fields such as “job title”, Google deals with “just” pages.

(Google)site:linkedin.com/in software engineer lisp

The first profile belongs to a person who calls himself a “Code Gardener.” His profile not only has LISP, but also lists LISP “dialects” – it says: “Development in Common Lisp, Clojure, LFE (Lisp Flavoured Erlang), Scheme, and Shen.”  Very relevant!

The second result is all right; it also lists LISP and its dialects.

The third result is a profile of a big-time LISP fan and expert. He wrote in LISP at every one of his jobs and even “developed Lisp Machines.” Very relevant.

Further Google results also start showing synonyms found instead of the entered keywords, for example, it finds “software developer” (a synonym for “software engineer”).

How come databases (LinkedIn, many resume job boards, and people aggregators, as some examples) don’t automatically offer results that reflect some query understanding? (To be fair, Monster.com has implemented some semantic search features; it has been a while since I tried that search.) “Understanding” queries – at least simple ones – should be doable, especially by systems like LinkedIn, that have tons of data, from which the system can “learn”. They have long lists of similar job titles, related skills, etc., plus they get data on search results relevance from tracking users’ behavior. I am not suggesting that a database would auto-transform an entered query to a very long Boolean OR string – but rather, just show me what I might like to see as results.

Slightly semantic search interpretation in a database search is also not as hard to implement as matching profiles to job descriptions (which many claim to do and nobody does well – understandably since it is very hard.)

I guess it’s a question to the tool developers (those who’d read the blog post). Let’s see what they have to say.

Built-In Introductions Are Broken – Create Your Own Instead

booleanstrings Boolean


When we talk about getting the best response rate from potential candidates or clients, one of the important considerations is how the message (text, email, etc.) looks on their end.

A friendly way to reach someone, that LinkedIn has had as its Social Networking function for a long time, is to be introduced by a common connection. However, if you have been relying on LinkedIn Introductions – sorry to bring the bad news: they are broken (and have been broken at least for several months). There are several challenges, the worst being the way LinkedIn introductions arrive on the receiver’s end, that make the built-in introductions useless. Here are some details.

If we find someone using search and select “Get Introduced” from the drop-down menu:

introunfortunately we will be simply taken to the Inbox, so that is a dead-end. At least it’s clear that doesn’t work! (It’s a bug).

Then, if we go to someone’s profile, find the “How You Are Connected” part, that’s where we can request an introduction:


We no longer have a choice of the connection in common to introduce us (as it used to be before this User Interface redesign). These days, LinkedIn decides for us who that person should be. Still, even if I’d prefer to be introduced through another connection than the one offered, it seems to be an OK way to reach out.

Here is the most broken part. Did you know that this is how the request arrives on the introducing person’s end?


Which Michelle? – might ask Martin (I’ve looked at his and my connections in common, and there are four Michelles; I imagine, there are more Michelles that are his connections and not mine.) In case of an even more common name to be introduced to, this would be a mystery.

If you really want to use the intro feature, you can fix it and edit the message to sound like this:intro-email-corrected

(Make a note of it.)

Manual Introductions

Since this built-in “intro” functionality produces more confusion than help, you can take complete control over introductions, in the following way.

First, find all the common connections with the person to be introduced to (search for the person and click on the green link with the “shared connections”). Second, select a connection in common for the introduction and hand-create a better intro message than LinkedIn does. This method requires a bunch of mouse-clicks and typing but at least it has a better chance to work. An alternative is to pay for InMails, as the help page suggests.

To get a broad picture of ways to fix LinkedIn built-in functionality, sign up for our webinar Overcoming LinkedIn’s Limitations, which turned out to be very popular!

RankBrain and Us

booleanstrings Boolean


Google’s search algorithm keeps changing all the time. Even search engine experts fall behind in understanding and interpreting how it works. Last Fall, Google told us that RankBrain is now one of the three most important factors for ranking search results. It was not until recently that we heard that the other two most important factors are familiar – they are “links” and “content”. Specialists think that, in addition, Google uses more than 200 other factors to decide what to display when we search.

RankBrain is an AI (Artificial Intelligence), machine learning algorithm. It plays an especially important role in responding to unique (mostly, long) search strings, which constitute about 15% of all the searches.

By now, we are familiar with these Google’s semantic search elements:

  • Auto-stemming (automatically searching for words with the same root, e.g. search for manager – find manage, manager, management)
  • Automatically searching for synonyms (e.g. search for developer – find developer, engineer, programmer)
  • Responding with Knowledge Graph objects and Direct Answers.

Rankbrain is a huge step forward in expanding semantic search capabilities beyond the above features:

  1. Google examines the whole query, trying to figure out the context, and respond accordingly. (As an example, compare results for salary apple packer and salary apple ceo.)
  2. Google learns what content users choose to explore and adds to its “understanding” of topics and terminology.

For those of us who perform advanced Google searches, it’s not that our jobs will be automated any time soon. I doubt that Google will ever be able to find matching candidates if we paste a job description into the search bar. But we need to be aware that Google tries to understand (and learn from) complex queries.

We may benefit from Google’s growing semantic search capacity – as an example while we explore industry-specific terminology.

On the other hand, because of the new semantic features, it’s becoming harder to control search results. Boolean operators and Google search options do help when we look for something we want to define precisely.

When you feel you need to control the results, keep in mind the following:

  1. Putting the quotation marks “” around a word will likely stop Google from bringing up synonyms.
  2. Any word used with an operator, such as inurl:, intitle:, intext:, will be used exactly as it is – Google will not show any variations or synonyms of the word in the results.
  3. When we exclude keywords using the minus -, Google removes the exact word after the minus (it will not remove any synonyms or variations).
  4. Searching Verbatim will stop any interpretation of the search string.

Additionally, avoid very long search strings, not to trigger unnecessary interpretation of what you want to find.

Get the recording on 300 Best Boolean Strings to hear how to best utilize both semantic and Boolean sides of Google search in your practice today and tomorrow, or purchase the Boolean Book that has syntax explanations and 300+ examples of search strings.

What Sourcers Can Learn Learn from Investigative Journalists

booleanstrings Boolean

Searching the Internet is an important part of Talent Sourcing activities in Recruiting. So it is for some other professions, including, for example, Librarians, Private Investigators, and Investigative Journalists. We could learn from each other – I feel that we don’t do that enough.

I’d like to bring to my blog readers’ attention a few excellent resources shared by Investigative Journalists.

This is just the tip of the iceberg, once you start looking at the above resources, you will find a ton more!

Location, Location, Location

booleanstrings Boolean



For all of us who are looking for professionals, finding those living in the right locations for the opportunity is critical. The expected time for someone to get into the office should be reasonable.


The commute time may depend on the distance, the roads, and available transportation. If we are looking in well-populated areas where driving is “too” popular (which is the case of the San Francisco Bay Area where I live – just take a look at the photo above), you might even need to take traffic patterns into the locations’ considerations.

It would be helpful to have the full support of professional and “social” systems to search for locations based on the average commute time to the office, but those search capabilities don’t exist anywhere, as far as I know. The ways to search we encounter are not ideal. They also vary widely (even more so than the Boolean syntax!). It’s important to know what is offered, to “map” our requirements to the available location searches on each site.

Here are some examples of what various sites provide, to compare.

LinkedIn – search by one of:

  1. Zip code and a radius (in the countries with zip codes, which is roughly 1/3 of the countries on LinkedIn – Ireland is not one of them, for example)
  2. Country
  3. A combination of named locations (for example “Greater Chicago Area” OR “San Francisco Bay Area”).

Those are workable options. But an annoying feature of LinkedIn’s location search is that it’s sending its users to another site to check the zip codes:


This lookup that we do manually would be pretty straightforward to implement for LinkedIn Engineers; somehow it’s never been a priority.

Github – the “location” field on user’s profiles is a string of characters. So, to find people at specific locations, we need to come up with as many possible ways users may have entered the field as we can (city names, area names, sometimes, abbreviated, etc.), and use those in searching. (Example).

That’s reasonable, given Github’s purpose as software code repository, not a site for recruiters to search; we need to remember how locations work when searching.

Zoominfo – search by one of:

  1. Boolean strings in the location field (e.g. Marcelle or Lyon)
  2. Region/State/Country – in several English-speaking countries
  3. Zip code and a choice of the radius – from the exact postal code to 200 miles.

Those options are convenient. Zoominfo’s search is also fast and immediate; there is no need to press “enter” or wait. Of course, the full search is only available to paid subscribers, but it’s possible to preview the results without logging in as well.

Here is an additional consideration regarding location search. Pretty much every site with profile search offers keyword search in addition to searching by other facets. Whether you will find people at the right locations by using those location names as keywords, depends on the site. (Interestingly, LinkedIn provided that for a while at the dawn of moving to the Galene algorithm, then stopped, as we can notice in this example).

Do you know how exactly the sites that you use – your ATS or CRM system, resume databases, social sites, people aggregators, etc. – search for locations?