🦔 Location services API investigation

[gobyrne]

🦔 Spike

We currently handle locations by using broad Canadian regions to allow candidates to share their preferences. Eventually, if we want to be able to improve our automated matching, we'll need to do better and actually geo-locate places.

This is something we've been eying for a while and we'd like to see if we can put up a proof of concept.

🤔 Why move to an API for this

Josh's angle

"As an applicant, I want to be offered jobs in or around my current location by default, with the option to specify other locations as needed."

"As a manager, I want to find the best talent match with the skills I need who is willing to work in or around the location the job is available in."

The API would offer the following flexibilities:

• Adding locations for all users becomes REALLY easy thanks to autocomplete
  • We no longer care as much about where you currently reside or whether you're interested in relocation, just tell us all the places where you're willing to work
• The API provides consistent data, updates to said data, and so on, avoiding things like spelling mistakes, etc.
• Matching locations becomes WAY more nuanced and accurate
  • We can match against province (e.g. give me talent willing to work in Ontario)
  • We can match against a region across provinces (e.g. give me talent willing to work in the NCR)
  • We can match exact cities, towns, villages, etc. (e.g. give me talent willing to work in Laval)
  • Not only can we do exact matches, we can do proximity based matches; the rules around commuting into the office have certain distance limits we can use (e.g. give me talent that is willing to work within 150km of Ottawa)
• This also opens up the job alert system described in the Account settings designs so that people can define job alerts based on specific locations they don't currently live in

Our current implementation is problematic for two reasons:

• We can only match based on "Province, territory, or region"
  • This is a problem because it is vague; if I work in Timmins, why am I being matched to jobs that can only be performed in Ottawa?
• We ask for location exclusions
  • I'm assuming that it's generally easier for people to talk about what they want in this circumstance rather than list all of the places they don't want to work
  • This is also a problem because we can't do any programmatic matching; our clients are left to match manually every single time

🕵️ Details

https://developers.google.com/maps/documentation/javascript/places https://exoapi.dev/blog/building-an-autocomplete-address-form-in-react

Time Box

❓ Questions

• [ ] how do we integrate with an external api to autocomplete user location input (expect a proof-of-concept)
• [ ] how would we store preferences (eg list of geo-coordinates plus allowable radius, list of geo-fenced regions according to google, list of standardized addresses, etc)
• [ ] how do compare an office address to what we have stored in the database to produce matches? (For example, a geography postgres plugin might help with this)
• [ ] what kind of budget would we need for these services

[mnigh]

some questions:

• what if the google api stops working or changes (this has happened several times before)?
• what is our budget for using the google api?
• what are there coordinates of “telework”?
• what are the coordinates or the ncr?
• what if a user doesn’t want to enter their full address for privacy reasons?
• what if a user’s location is outside of canada?

[JoshBeveridge]

@mnigh I've answered a few of your questions in the main body of the ticket, but here are my thoughts:

• RE the API not working - I'm willing to eat this risk for an experience that is above and beyond for all of our user groups; Google has financial stake in their APIs' uptime, so we know they'll do everything they can to maintain it and get it back up when an issue arises, something no other service will offer at the same scale
• RE the budget - this is a ? for me as well, but @gobyrne doesn't seem worried about it
• RE coordinates for telework - this becomes irrelevant; we pair a question about remote, hybrid, and on-site with locations the user is willing to work in
• RE coordinates for the NCR - this is actually a mapped area in Google's API already
• RE full address privacy - I'm arguing that we won't need to ask for a user's address if we implement this, because we can ask them to specify where they want to work, not where they live
• RE folks outside the country - same deal, just tell us where in Canada you want to work

[gobyrne]

@tristan-orourke can you take a look at Josh's addition to the issue please? Let us know if you think it's worthwhile spiking now.

[tristan-orourke]

Let's turn this into a list of questions first. Here's what I'd want to know:

• how do we integrate with an external api to autocomplete user location input (expect a proof-of-concept)
• how would we store preferences (eg list of geo-coordinates plus allowable radius, list of geo-fenced regions according to google, list of standardized addresses, etc)
• how do compare an office address to what we have stored in the database to produce matches? (For example, a geography postgres plugin might help with this)
• what kind of budget would we need for these services

[gobyrne]

https://www.statcan.gc.ca/en/lode/databases/oda

[gobyrne]

Updated the issue based on Tristan's feedback.

[esizer]

• how do we integrate with an external api to autocomplete user location input (expect a proof-of-concept)

I'd reccomend a third party service like MapBox or Google Maps. These are very simple (I have done it many times) to do and can be restricted to geographic locations pretty easily.

• how would we store preferences (eg list of geo-coordinates plus allowable radius, list of geo-fenced regions according to google, list of standardized addresses, etc)

A few options could be taken here. I usually store just lat lng and then have a km radius. Though, you can do bounds using GeoJSON as well.

• how do compare an office address to what we have stored in the database to produce matches? (For example, a geography postgres plugin might help with this)

Haversine

• what kind of budget would we need for these services

I have seen costs anywhere from $200-$2000/month for services. It all depends on how much you use. If we are just using autocomplete I'd wager we are near or at the min cost here.

[brindasasi]

Brinda & Eric have done that and we can discuss on that.

[brindasasi]

@gobyrne what's the next step on this?