Intelligent Searching and Matching

booleanstrings Boolean 0 Comments

Intelligent searching and matching resumes against job descriptions is not an easy task, not for a recruiter and not for software. At the end of last year, I became interested whether recently released tools in the “match” category can help to speed up searching, by offering “short-listed” candidates for review and contact. I’d like to share some observations on intelligent searching and matching and will go over some tools in a future post.

Let’s take a closer look at what “matching” means for a job description and a candidate’s resume. I think you would agree that finding a matching resume would rarely be productive if it is only done by crafting a Boolean string with long lists of keywords and synonyms separated by ORs, based on the job post. (As just one example: the job and resume “context” matters for matching; in one case, a person with either Linux or Solaris, both being Unix variations, would be okay; in another instance, it has to be Linux.)

A naive assumption of some job hunters – and even systems that assist them (such as Resunate and Jobscan) – is that “resumes must contain the most prominent keywords from a job post” for a candidate to have a chance to be hired for the job. A junior recruiter (or poorly constructed system) can pull out only keyword-matching resumes as “the” ones worth reviewing – but this rarely works to solve the matching challenge. The reality is that keywords on job posts and resumes of those who get the jobs differ quite a bit!

Below, you will find the word clouds for two job ads, along with two resumes of people hired for each of the jobs. Let’s take a look and appreciate the how far apart these word clouds are:

Job 1 (Clinical Nurse)
job-cniiiResume, match #1 (the person works there):
r1-cniiiResume, match #2 (the person works there):


Job 2 (Developer, machine learning):


Resume, match #1 (the person works there):


A filled out LinkedIn profile, match #2 (the person works there):


You see? The keyword sets in both cases are dramatically different between jobs and resumes. Clearly, searching and matching in recruiting is more complicated than automatic keyword searching, even with the addition of synonyms.

Recruiters who use databases with resumes or professional profiles may construct searches based on:

  1. Location, job title (with variations), skills (including synonyms, popular technologies, etc.), years of experience, education requirements, (possibly) certifications or licenses, etc. – This is derived from the job post.
  2. (except for new and unique job openings) “Similarity” to people who have been hired for this type of jobs at this company in the past, or perhaps got an offer but didn’t accept – for example, graduates from given schools, employees from a company’s competitor, or a company using the required technology, etc. There can also be “preferences” input from Hiring Managers that is not present the job post. – This is additional helpful intelligence.

Constructing productive searches that would find results matching the requirements, as you see, is not straightforward – it is an art. Even in systems providing faceted resume search, allowing (for example) to search for job titles and years of experience, in addition to keywords and phrases, and offering advanced Boolean syntax, choosing search terms requires the recruiter to understand the industry terminology, as well as apply company- and job-specific knowledge. Recruiters, while sourcing, need to run a variety of searches to get the best matches and not miss any top candidates.

Can a computer system efficiently do the job of searching and matching? I’ll write a review of matching systems in an upcoming post.



Leave a Reply

Your email address will not be published. Required fields are marked *