Boolean Search

What Boolean search is

Boolean search, in recruitment, is building a search string that combines words with logical operators, so that the set of results is defined deliberately rather than left to a search engine’s ranking. There are three basic operators, AND, OR and NOT, together with two devices that control meaning: quotation marks, which force words to appear in sequence, and brackets, which decide which operator is applied first.

It is a tool inside talent sourcing, which means going out to candidates instead of waiting for them to apply, drawing on sources such as professional networks and the pool of past applicants. Boolean search is about how to write the string that pulls names out of those sources.

It is not tied to any one site. It is used inside an applicant tracking system, in a candidate database and in general search engines. What differs between them is which syntax they accept, not what the operators mean. Some accept brackets and some do not, and some limit how long a string can be. We found nothing, in the sources we reviewed, establishing these details for any particular platform or date, so we give no syntax attributed to a platform; the reference is the platform’s own documentation at the time it is used.

The three operators and how they go wrong

• AND requires both terms together and so narrows the results. Every condition added cuts into what came before; it never adds to it.
• OR accepts either term and so widens the results. It is the operator for handling several names for the same thing, and the most useful in Arabic, as shown below.
• NOT removes anything in which the excluded word appears. It is the most dangerous, because it removes a whole document if the word appears anywhere in it. Someone who excludes مدير (manager) to avoid managers also removes the candidate whose CV says they report to the finance manager, مدير الحسابات, who is exactly the person wanted.

Brackets are not decoration. Where an engine applies AND before OR, a string that sets a condition and then offers a choice between two titles without brackets is interpreted differently from what its author intended: the condition is required with the first title only, and the second is accepted with no condition at all. The result is a longer list containing names that do not meet the search conditions, and nothing on the screen says that is what happened.

Arabic raises a problem English does not

A single Arabic word can be written in several forms that mean the same thing and differ in their letters. A string that matches letter for letter does not treat those forms as one unless the engine itself has been set up to do so.

Take the job title أخصائي موارد بشرية (human resources specialist) and count the forms in which it might appear on a CV:

• The first word in the masculine: أخصائي, اخصائي, إخصائي and اختصاصي. That is 4 forms.
• The same again in the feminine, with the added final letter, for 8 forms.
• Multiplied by the two forms of the second part, موارد بشرية and الموارد البشرية, for 16.
• Plus the two English titles some people use for the same role, for 18 forms.

A string with one form in it searches one of eighteen. Drop a single form out of the eighteen and coverage is 17 of 18, about 94.4%: a small shortfall in the number and a large one in its effect when the candidate you want is in the missing form.

The shortfall does not announce itself. A search that finds nobody is read as scarcity in the market when it is in fact a narrow string. The sign that separates the two is to try a single form with no conditions: if it returns large numbers, the market is not scarce, and something in the string is cutting candidates out.

Some engines handle these variations themselves and treat the forms as one; others do not. Which do so is a property of the engine, not of the string, and we found nothing, in the sources we reviewed, establishing this for any particular platform, so we do not state it. The practical response is the same either way: write the forms with OR, and the string holds whether or not the engine handles them.

Searching within a single site

One form of the tool restricts a search in a general engine to a single domain, so that a site is searched from outside it. It is used where the site’s own search is weaker than the general engine, or where the site does not allow its full text to be searched.

It always comes with two limits: it reaches only what the engine has indexed, so anything not indexed will not appear even if it is on the site; and what appears is what its owner published publicly, not what sits behind a login. So results here are always narrower than the site’s contents, and anyone who reads an empty result as proof that the candidate does not exist has mistaken the limit of indexing for a verdict on the market.

Published publicly does not mean free of rules. What is gathered about people through Boolean search is personal data, and the rules on personal data apply to it; looking at what a candidate posts on social media is a practice with rules of its own. None of this is legal advice.

The source that gets overlooked: current staff and past applicants

The same tool can be turned inwards, and that is its cheapest use. The string written to search professional networks can be used unchanged to search the candidate database and the records of the people who work in the organisation today.

What comes out of each is judged differently. Someone who applied a year ago and nearly got the job is a candidate to go back to, and accounts of talent sourcing count past applicants as the least costly source. Someone who works there today and has the required capabilities in another role is not an external candidate at all; that is internal mobility, which has its own rules on advertising the move, handing over work and the current manager’s objection.

What makes this search possible at all is that the data is recorded in a searchable form: skills held in separate fields in each employee file, not a CV attached as a document whose text cannot be read. An organisation that stores only attachments has nothing to search, and no sharper string fixes that.

A worked example: two strings compared

The aim of narrowing is not to reduce the numbers but to cut reading time without losing candidates. Two figures decide it: how many of the results fit the description, and how many of the people who fit it appeared.

Take a search for a role in Saudi Arabia and assume there are 120 people in the source who fit. The figures are assumed to show the calculation, and they do not amount to a model string for any role:

• A broad string returned 4,000 results containing all 120 who fit. The share of results that fit is 3%, and the share of fitting people who appeared is 100%.
• A narrowed string returned 260 results containing 96 who fit. The share of results that fit is 36.9%, and the share of fitting people who appeared is 80%.

The effect on time: at a minute and a half of reading per result, the first needs 4,000 times 1.5 minutes, which is 100 hours, and the second needs 6.5 hours. Narrowing saved 93.5 hours and cost 24 fitting candidates who never appeared. Hours of this kind are part of the internal cost of recruiting that cost per hire is meant to capture.

The choice between the two strings is not absolute. If three hires are needed, the 96 who appeared are enough and there is no point spending a hundred hours. If the role is rare and every single name counts, each fitting candidate who did not appear is a loss that time saved does not make up. So the question that decides it is not which string is more precise but how many people are needed.

How to build the string, in order

• Start from the content of the work, not the title. Titles vary between organisations while the work stays the same. That content comes from job analysis, and the tasks and competencies it yields are the material of the string.
• Separate requirements from preferences. What the role cannot be done without goes in with AND; everything else stays out of the string and is used for ranking after the results are pulled. This is the distinction that hiring based on skills rests on, and putting a preference in with AND is what produces the search that finds nobody.
• Group the forms of each term with OR inside brackets, in Arabic and in English.
• Leave NOT until last, test it by removing and restoring it, and look at a sample of those it removed before keeping it.
• Write the string down and save it with its date. It is a tool that gets reused and built on; a string that is not saved is reworded every time, and its results change for no reason.

What spoils it

• Copying a finished string from a public source. It is built on the titles and work content of another market, and it produces a list that looks sound.
• Relying on qualification and title alone. The string then measures what was written on the CV, not what its owner can do, and it excludes whoever described their work in their own words.
• Putting personal attributes into the conditions, such as a university or a graduation year. Through that door come preferences based on reasons nobody states, and a graduation year in particular is one of the routes by which ageism enters a shortlist.
• Reading the number of results as a measure of the market. The number is a property of the string and the source, and it moves when they move without anything in the market moving.
• Stopping at the string. It produces names, and then different work begins: the first contact, where a standard message is read as standard and replies fall. For a sourced candidate, that first contact is already part of the candidate experience.

Related terms

• Ageism
• Competencies
• Candidate Experience
• Cost per Hire
• Structured Interview