MARK MIRCHANDANI: There wouldn't be
much point to a job search solution
without jobs to search for.
In our last video, we talked about creating companies
using the Google Cloud Talent Solution Job Search API.
Now, let's talk about how to create jobs and best practices
for working with them.
[MUSIC PLAYING]
We'll get started by creating a job.
You can't make a job without a company,
so we'll be using a company that we created in the last video.
There are also a few required fields we'll need.
First off, we'll need the company's name,
which is the unique identifier, not to be
confused with display name.
We'll also need a requisition ID,
which is a string that represents
your own unique identifier for the job, kind
of like external ID for companies.
This is helpful to make sure it's easier
to sync the job search API in your current job solution.
There's also the title, which is, well,
the display title of the job.
Description is where you put all the job details and related
information.
You can use HTML and some markup tags here.
Finally, we'll need at least one of three fields
under application info--
URIs, emails, or instruction.
These help point job seekers to where they'll
need to go in order to apply.
URIs and emails are arrays in case
you have multiple, while instruction
is an HTML-friendly string where you can describe
the application process.
Each job could have all three, but you can't create a job
without having at least one.
With all those fields, you can create a job,
so let's look at some code.
The code structure should look pretty
similar to our other samples, but let's walk through the bits
to create the job.
We need to include the project ID and the company name
here so we can use it when we first define the job.
We'll hardcode it just for this snippet.
Here, we're passing in the job when we
call the API with jobs.create.
Again, pretty similar to creating a company.
And here's where we actually define the job
and set those required fields.
We've got the company name, which was set up above,
as well as the requisition ID, which
is the string we can use to more easily map the job to our job
system.
After that, there's the title, description, and in this case,
we provided a link for the application information.
So from here, we'll create the job.
And the API knows which company it belongs to,
so we pass in the company name.
After running that code, here's part of the response.
We'll see the new job was created,
and it has the same property values that we passed in,
as well as our unique name that we
can use when referencing a job.
Now that we can create jobs, what
happens when we try to create a job that's
already in the system?
As you might expect, you'll get an error,
because job duplicates aren't allowed.
Duplicates are determined by three fields--
company name, requisition ID, and language code.
We provided company name and requisition ID
when creating the job.
Language code is an optional field
that will represent the language based on the job description,
and it defaults to en us if not set.
As long as the combination of these three fields is unique,
the job won't be treated as a duplicate.
So that's the basics for creating jobs.
We can also get a job to see the details,
delete a job to get rid of it, and patch a job
to update any properties.
Just like companies, you should pass in an update mask, which
is a string of comma-separated properties
that you want to update.
There's a few more details about why
that's important in the company's video.
We can also list jobs to see all the jobs in the system.
This is just a simple list without any filtering,
so it's probably better saved for any administrative
functionality.
This code is the modified version of our list companies
code that now shows companies and jobs.
We'll loop through each company, and then list jobs
for that company by filtering on the company's name.
Pretty simple, but a great starting point
to making sure that you know the jobs
and companies in your system.
There's quite a few more fields when dealing with jobs,
but they're optional.
Let's look at some of the more common ones.
And you can always check on the docs to see the full list.
Each job can have an array of up to 50 addresses, which
are passed in as strings.
Just like companies, the API will
create a read-only property for each job, called derived info,
that looks at addresses you pass in
as well as the parent company's information
to geolocate each job.
This is all powered by the Google Maps Geocoding API.
So if it works there, it'll work here.
There's also a posting region which
lets you specify how strict the location matching for the job
needs to be.
For instance, if the posting region is set to nation,
this job will show up for a search in jobs
that match the same country.
Administrative area depends on the country
but represents areas like states, for United States,
and prefectures for Japan.
Telecommute means the job allows for remote work,
and the location is less relevant.
There are also some fields to help you
talk more about the job itself, such as job benefits,
compensation info, employment types, and degree types.
Each of these have their own object, or enum,
to get the most accurate data.
But they're all pretty simple fields.
There's even custom attributes.
So you can provide your own key value pairs
and do some advanced searching, which we'll
talk about in a later video.
However, these are all useful to help jobs searchers get
better results.
There are also a few properties specific to the job posting
itself.
These are all strings that represent timestamps.
The fields postingCreateTime and postingUpdateTime
are read-only fields that let you
know when the job posting was created and most recently
updated, respectively.
jobStartTime and jobEndTime are useful for contracting
or seasonal jobs where you might have specific timing
requirements.
postingPublishTime represents when
this job was most recently published,
while postingExpireTime is the timestamp for when
the job posting expires.
By default, the expiration time is set to 30 days
after the job was created.
We definitely recommend explicitly setting
the expiration date to what makes the most
sense for your business.
For example, if you update a job but don't include
a new expiration time, it will refresh the expiration
to 30 days from the time of the update.
If you want to get around that, explicitly
set a new expiration time, or make
sure to use an update mask without posting expire time.
Expired jobs won't show up in search results
or when calling list, but you can still
get the properties of an expired job by using get, and in fact,
update it with patch.
It's even possible to update the posting expire time
to unexpire a job.
That patch may fail if there's another open job
with the same company name, requisition ID, and language
code, so make sure that you handle
any errors that come back.
Also, if a job is expired for long enough,
or you have too many expired jobs compared to open jobs,
expired jobs start to get permanently deleted.
Remember, the job search API is a search index for jobs.
So if you want any permanent record keeping,
you should do that in the job solution directly.
That's a brief overview to help you start loading companies
and jobs.
With all that data, there's only one thing
to talk about in our next video--
performing searches.
Thanks for watching.
And remember, when looking for talent,
it's OK to keep your head in the cloud.
[MUSIC PLAYING]