At Whitetruffle we frequently update our features and recently worked on a few important releases. Simplicity is our motto, but sometimes the easiest looking changes require in-depth analysis and some good brain-power.
When Whitetruffle first launched our closed beta, we were only working with San Francisco Bay area companies so our locations feature was built to reflect this using the colloquial San Francisco, Peninsula, South Bay, East Bay and North Bay terms. This was enough to give our users a good idea where the jobs were. And as we expanded to other markets, we merely added more locations until it became clear that simply adding new cities would be untenable. The feature needed to be redesigned and rewritten.
Requirements
Candidate and company location impacts three characteristics: commute time/distance, relocation, telecommuting (working remotely). To support these ideas we needed to be more granular with our options. We added addresses to support commute time and distance calculation. We added also home and relocation tags to addresses.
Implementation
Our first challenge was getting an address with usable latitude and longitude coordinates to support distance calculation. The process of accurate address to coordinate translation is called “Geocoding”. For this we decided to use Google Maps API. Google Maps API has been in the news a lot, especially with regards to their pricing plan, but depending on how much you need to scale and your requirements Google Maps API can be a good V1, just check their licensing page for details. For a small startup like us, judicious outsourcing allows one to focus on the final product, rather than getting bogged down with implementation and keeping things up to date.
Another reason to go with Google is the range of inputs which their geocoder accepts. They support postal codes, neighborhoods, street intersections, along with the expected address, city, state, country. For us, this is a very important criteria. The additional input options allows users to protect their privacy, providing us with reasonably accurate data for commute calculations.
On the other hand, one of the perils of loosey goosey input is validation. Unintelligible addresses prevent us from making any matches based on location. To prevent this we used a typeahead ui widget populated with the search results from the Map api. On the other hand misunderstood address, e.g. Springfield, MA, USA vs Springfield, IL, USA can provide wildly inaccurate matches. To mitigate this, we added address previews so the user can visually confirm that we have guessed the correct address.
Our current limiting factor with additional UI improvements is, ironically, Google. But we have some other plans on moving beyond that and you’ll continue to see more improvements coming in the future.
As always, we welcome your feed-back at [email protected].
– Joseph, Whitetruffle Engineering
