MARK MIRCHANDANI: Now it's time to do some job searching.
Our last video set up companies and jobs
using the Google Cloud Talent solution job search API.
Let's search against the API and see what comes up.
[MUSIC PLAYING]
There's a few things we should include in the request
when searching for jobs.
So let's cover those and then run some searches.
For every search, we need to provide request metadata.
This is an object that provides information
about the user making the search request.
It's important to provide these details to ensure
a consistent user experience as well as to better train
the machine learning models.
First three properties in the object are required.
Domain should be the domain where the search is
hosted from, such as foo.com.
Session ID and user ID are value specific to the user doing
the search and should properly be
obfuscated before being provided, such as hashing them.
That way the API doesn't see any personally identifiable
information, but it can tell when
it's the same session and user.
Device info is optional and consists
of the ID and type of device so you can distinguish create
a web search and an app search, for example.
Allow missing IDs is a Boolean that makes those first three
fields optional.
When the API is fully implemented,
you should always aim to provide all
of the requested information to ensure the best results.
You can use Allow Missing IDs if you
can't get all the information or if you're testing.
For our sample code, we'll provide
some static values for these.
Technically, that's the only required field
for doing a search.
But then the request will come back with all sorts of jobs.
More than likely, we'll want to actually search for something.
So we'll include a job query.
The job query can be pretty simple
with a query string for the actual search
terms and different filters to help narrow down the jobs
that get returned.
For instance, you can return only jobs
from a specific company or filter by employment types.
We'll just stick to the query string for now.
But there's more information about filters
in the description below.
You can also specify a job view property,
which is an enum that declares how much information you
want to get back with your job search request.
Job view full gives you back all the information about each job
result. But you might want to save some bytes
and choose another option that returns less fields.
Pick the option that makes the most sense for the platform
you're working on.
Since you may get a lot of results,
the API will also paginate, so you can work with a pagination
interface.
We recommend keeping the page size to 20 or less
to avoid latency issues and always use pagination
through the API rather than trying
to load in all the results.
You'll get a next page token in the response.
So if there's more jobs, you can pass it
into the next search queries page token.
There's also a search mode option
that lets you choose between a normal search
and a featured job search.
If you want to hear more about feature jobs,
check out the previous video in the series
that explains the difference and when
you should use feature jobs.
There's some other optional fields
you can read about more in the documentation.
But let's see some code and run a search.
Here's a sample script that takes a search string
and then runs a search query.
We'll set up the API the top and then we call our function.
Here's where we set that request metadata
and grab the search query string.
As I said before, the request metadata
should include as much information as possible,
but we'll still hash the user and session
information to avoid any personally identifiable
information.
Here we build the request object with our search
term and our request metadata.
We're also explicitly calling out
that this is a normal job search instead of a feature job search
and saying we want the full information
for each job returned.
We've also got a page size for 20
for now, though we'd have to use page tokens or an offset
if we wanted to get to the next page.
With that, we'll make the call with jobs.search
and we'll pass in our object.
Since we used job view full, we'll get a lot of details
back.
But the code is only going to look for two things, the title
and the search text snippet.
Each result will return the field
that your job use specifies.
And that may be getting back a job object for each result
as well as the fields that are specific to the results,
such as the snippet.
Now, if we run the code and we search for engineer,
we'll get some results in the matching jobs field.
By default, these are ordered from relevance
by the ML models.
You can specify the order in the search request
if you need to do some custom logic.
But we recommend using the default relevance.
This is a great starting point for getting data loaded
into the system and performing some actual searches to see
what kind of results you get.
Looking at the raw search response,
you'll see some important additional information.
Total size and estimated total size
can help you with pagination, and matching jobs
contain the actual search results.
In the metadata section, you'll also
get a request ID that's unique to this specific search.
These are globally unique IDs generated
for that specific request.
So if you're seeing an issue or have a question,
these requests IDs can be very helpful
if you need to contact support.
From here, you should be able to load information
into the job search API and start doing searches.
In our next video, I'll talk more
about the specifics of relevance and ranking
for the job search results.
Thanks for watching.
And remember, when looking for talent,
it's OK to keep your head in the Cloud.
[MUSIC PLAYING]