JENNY BROWN: Our last video talked
about some major configuration options
when using the Cloud Talent Solution Job Search API.
There are some simpler configuration options
that we have recommendations for and some best practices
when testing out your API integration.
Let's start with the configuration options
when executing a search request against the API.
First up, page size is a pretty simple one.
It's number of jobs that get returned in a single response.
We typically recommend sticking to 20 or fewer
to keep things quick.
Now, if you're dealing with jobs in multiple geographic areas,
you'll want to make sure that you set the region
code through location filters and language code
for each search.
The search's region code will match the jobs region code only
to display results in the right regions.
For example, if a region code isn't set,
a search for Cambridge might return job results
from Cambridge in the UK and Cambridge in the US.
The language code will help the API localize the search query
to increase the relevance of results
through language-specific terminology.
Not only can you set the region for searching,
you can also set a distance in miles.
Setting the distance to 50 would limit the search results return
to only be within 50 miles of the user's indicated address
or lat long.
Like most of the configuration options,
you should tweak this to what works best for your use case
or expose an option to the user.
The fewer restrictions you place on the query results,
the more results you'll get, but potentially
with less relevancy.
There are also some configuration options
you can set on individual job postings to help the API
when searching, such as the location we just mentioned.
When setting the location of a job,
you should provide the address of the job,
if possible, rather than the GPS coordinate.
We'll go over more details in future videos
when we talk about creating jobs in detail,
but the API uses addresses to help
with location detection and accurate results.
In general, making sure jobs have
locations helps users have a better experience
when searching.
For each job, you can also set an expiration time.
After that time, the job no longer appears in results
when performing a search.
By default, the expiration time is
30 days after the job is created in the UTC time zone,
but you can change the value for each job as necessary.
Again, we recommend making sure to set
this property to what makes the most sense for you
and your users.
There is also an employment type to help
make sure users have more choice about what types of jobs
are returned.
Typical values can include full time or part time,
but there are a number of options to help narrow down
what can be returned, and not all options
may be applicable to you.
Finally, there's the custom attributes property.
This allows you to add additional values to each job
so that you can filter by them as needed,
or to use with custom ranking, like we talked about
in the last video.
For example, you may want to filter by GPA
required or industry type.
Now, we don't recommend setting up any custom attributes
for location-based properties.
That's because the API already has location logic specific
to the location field on a job that we've already
touched a bit on.
With those configuration options in mind,
you'll have a way to better control what
jobs get returned for a search.
There are also some best practices
when designing your integration with the API that
are worth noting.
Make sure you do your best to avoid uploading duplicate jobs.
While the API has protection to make
sure nearly identical jobs don't show up next each other,
it's still a poor user experience
to see the same job listing multiple times.
When creating a job in the API, it automatically
gets rejected if it's not unique according to a few parameters.
Two jobs can't share the same combination of company,
requisition ID, and location.
Again, we'll look more at these when we go over creating jobs,
but make sure to avoid any job duplicates before trying
to create them in the API.
Speaking of errors, you'll also want
to make sure you've set up your integration to have
appropriate error handling.
When running any requests, make sure to check
for the error codes in case the request didn't go through.
Some common errors we've seen are
cases where the job location is set incorrectly
when uploading a job or when required fields aren't set.
You can check out the full list of all response codes
in the link below.
When debugging or investigating an error,
we recommend starting with your local logging sources.
You can then check out to Cloud Talent Solution Management Tool
to see what may have happened.
It's also possible to setup Stackdriver
to collect all the metadata, metrics, and events
that you'll need to debug.
If the error code is related to quota or sending
too many requests, you may need to check the Cloud Talent
Solution Console, which you can access through the Google Cloud
Console for any indexing restrictions.
It's good to know if you'll be limited on the number of jobs
you can index at any given time before you upload any jobs
and to prepare accordingly.
When handling an actual error, we also
recommend doing exponential back off for any retries.
There's another link in the description for this,
but the basic idea is to ensure you design your system
in a way that doesn't just spam the API with requests
after a failure.
These are some high level things to keep in mind as you look
to start integrating your jobs and data with the job search
API.
In our next video, we'll walk through the details
of data that gets sent to the API,
such as jobs and companies.
Thanks for watching, and remember,
when looking for talent, it's OK to keep your head in the cloud.