Location, Location, Location

booleanstrings Boolean

location-location-location

 

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.

traffic

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:

lookup-zip

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?