CJ & The Duke

People ask "how can I interview for TOP ServiceNow talent if I don't know much about ServiceNow".  This episode teaches you
- The 3 Characteristics of TOP ServiceNow talent.
- Creating "hard to fake" questions that reveal those characteristics.
- Setting up virtual test environments.

MENTIONED IN THIS EPISODE:
- Understanding the limits of personal performance
- Success on ServiceNow, without ServiceNow

ABOUT US
Cory and Robert are vendor agnostic freelance ServiceNow architects.
Cory is the founder of TekVoyant.
Robert is just some guy.

Sponsor Us!

What is CJ & The Duke?

Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk

CJ: All right, well live

Duke: Sweet.

We're back.

CJ: again.

Duke: We really gotta get
back to our old cadence.

CJ: man, duke, I swear good
to get together and do these

things and life sometimes, man.

Duke: Man, we're grownups.

I'm not apologizing.

CJ: No.

No, exactly right.

I mean, stuff happens, right?

, That's just the way it works,

Duke: Yeah, it's crazy.

Life happens.

, Didn't we do an episode on that once,

CJ: I think we did.

Duke: times and seasons

CJ: Yep.

And about being un
unapologetic about it too.

Yeah.

Duke: Yeah.

You can't be all on all
the time for everyone.

CJ: No, it is, definitely a, challenge.

And So let's just get into it.

Okay.

Duke: All right folks, we love you.

We're so glad to be back.

what are we talking about today, Corey?

CJ: All right, duke, today we are
talking about, what did we call this?

Duke: Well, it all started, I've
been asked a couple times in the last

month about how to interview top tier
ServiceNow talent, and we know there's

a range, But certain organizations
want like a very, very senior resource

but the twist here is how do you do
that When you yourself are not a top

tier ServiceNow execution resource,
maybe you're just managing the team.

Maybe you're the political owner
of it, but you don't know you know

how to build on it or whatnot.

So how do you get the best ServiceNow
talent that you can with as little

knowledge of ServiceNow as possible?

I don't know how we're gonna get
that into a tiny little title.

CJ: Huh?

Yeah, no doubt.

Shrink that.

It's gonna be like a Bitly title,

you know, this is a question I get asked.

Um.

Not often, but not, rarely either.

you know, how do you find the
best ServiceNow talent, especially

when you aren't necessarily
the best service now talent.

what should a non-expert in
ServiceNow be looking to do

Duke: Because I think in tech Even
if we're not the tech person in tech,

maybe we're like the managerial, the
director, whatever, we have this,

baseline assumption that I have to
ask tech questions to figure out if

somebody's a real legit player or not.

And you do like and you do, right?

But there's other characteristics about
them that make them a great talent.

It's not just their
technical expertise, right?

Like how many episodes do we have about
being politically savvy and being.

CJ: Yeah.

Duke: like figuring out all the different
elements of success that have nothing to

do with your technical prowess, right?

And so how do you get that person
as well as making sure that

they actually know their stuff?

And so we've done some studying and
some thinking, and so we are gonna

bring you three characteristics.

That you can look for and test for.

We're gonna teach you how to apply those
characteristics to the questions that

you ask, and then we're gonna talk a
little bit about logistics of formally

testing people as opposed to like
just asking questions back and forth.

And gosh, I hope we have
enough time to do it all.

CJ: Yeah.

or, we are going to play, you're
gonna play this episode back at two x

Duke: Right.

Yeah.

Yeah.

It'd just be an extra long one.

so let's talk about the characteristics.

I came up with this model
called the trifecta.

And we all know that for Apex, ServiceNow
Town, these are people I want as

either principal consultants or my ma.

Like that would be the partner
ecosystem in the, customer ecosystem.

This would be like your product lead or
your main architect or, your main dev.

But it's gonna be the key, key
foundational person on the team.

Now what are the table stakes?

What's the one thing I have
to have as table stakes?

CJ: that, that's a good question,
duke, like when you're thinking about

hiring someone, what's the first thing
you think that person needs to have?

the first thing I think
about is capability.

Duke: Yeah, can a person even do the work?

Right.

There's no sense testing
beyond that unless they've

been in the trenches, you know?

And so you have to test for capability.

And I know, I know you're probably
thinking, but I, but Duke.

Like you just told us that you can test
for this without having the capability

promise you we're gonna get there.

Promise you just hold on.

CJ: Absolutely.

Duke: capability is absolutely the
number one thing to get in the door.

Okay?

But that doesn't make you an Apex resource
because we can rent rather cheaply.

Capability from, the lowest price
providers on the face of the earth, right?

Even they have capable resources,
strong technical resources, so, so

we're missing two parts of the trifecta.

CJ: Yeah.

'cause capability is not enough,
we're not talking about, you know,

creating an API, we're talking
about hiring a person, right?

So my next thing would be communication,
And you got someone who's capable.

Now, can they actually
communicate with you?

Can they communicate
with your stakeholders?

Right?

Can they communicate that capability are
they folks who can have a conversation

and work through The problem statement,
In a way that's collaborative and

explainable and understandable.

Duke: Now what we did was put a
lot of serious thought , into how

do you assess communication skill
without just going by your gut.

CJ: Right.

Duke: You know what I mean?

there's some people you
just enjoy talking to more.

Right?

You know what I mean?

Like

CJ: Yeah.

Yeah.

So those

Duke: tell you're like that per, that
this person's a good communicator

versus this person's a bad communicator.

You can usually tell.

CJ: right.

Duke: But, but maybe it would help if
we understood more points within that.

what skills fall under the
skill of communication.

And I'll lead off with the first one,
, is just validating, understanding.

how many times Corey, have
we been in front of people?

Like, we, we need to tell somebody you
have to do this technical work, right?

And it's like, yes, yes sir.

Yes.

We can get that done.

Yes.

CJ: Yep.

Duke: You know, it's just consultant
provider speak for, we'll figure it out.

We hope

they might not even understand what
we ask them to do, but sometimes

it's just the answer is yes.

You don't tell your, boss.

No.

So validating understanding
would be somebody who, when

you're asking questions, they
might not necessarily say yes.

No, they repeat back for clarification.

In the repeat back, you can hear the
notes of the things you asked them for.

So validation of understanding is 0.1

under communication.

CJ: Yeah, and just one additional
thing to that too, right?

Like you wanna make sure that the
person, when they're repeating it

back to you, or , rephrasing it
into their own words or their own

perspective, , it doesn't help anyone
if they just say the exact same thing

to you that you've already said to them.

Duke: We can train in AI for that.

CJ: Yeah, exactly right.

Like, you want them to put
their lens on it, right?

Like just have everything that you just
said flow through their lens so that

you understand that they understood.

Duke: It just reminded me of like when
the ais were first coming out for image

generation and you're like, I want
a picture of a Middle Eastern man.

He must be Middle Eastern.

He cannot have blue eyes, and
all the AI's like blue eyes.

CJ: Yeah, the, the, the old school AI was
just like, we will give you a human and

we'll, we will put on these additional
attributes and we hope you like it.

Duke: All right.

Validated understanding.

What's the next one, Corey?

CJ: narrative articulation, can
the person you that you're speaking

to explain the benefits, right?

The risks, the rewards, the roadblocks,
the , the value, the problem statement,

can they actually talk you through?

whatever the thing is, right?

The thing could be the
question that you asked, right?

Like, you might have set up
an example scenario and can

they talk you through that?

Or the thing might be you're asking
them, to come to the table with a,

story about what X, Y, Z, How do they,
how do they communicate that to you?

Right?

and is it understandable?

Duke: We've all been in a room where we're
with senior kind of business stakeholders

who don't know anything about building
ServiceNow, and there's some technical

resource explaining to the Nth level
of what technically is wrong with the

thing and why we're not gonna hit the
deadline and what you're looking for.

Someone there, like when we say
narrative articulation, it's kinda like

understanding who your audience is and
being able to abstract to that level.

CJ: Absolutely.

Yeah.

Know your audience.

That's a, that one's so key, if
you're sitting in a room talking to

the owners of the platform, right?

You probably don't wanna be super
in, in the weed on the tech stuff.

Duke: No.

CJ: And vice versa.

If you're in a room full of developers,
they probably wanna understand the nuts

and bolts of how you built that business
role or that script and include, right?

So go a little deeper.

Duke: It is kinda like that.

There's a YouTube channel that
I liked for a while where.

They get some profound expert in
something like astrophysics and they'll

like explain black holes in five levels.

And so it's like the first start off
with like some kid in kindergarten

CJ: Yes.

Duke: and then all the way up
to like a physics grad student.

but yeah, it is that, that's the kind
of thing, being able to read the room,

read the audience, understand what
this particular conversation needs is,

what we mean by narrative articulation.

CJ: Absolutely.

Duke: So this is two pillars
of communications, validates

understanding narrative articulation.

The third is persuasion.

you know, that magic that some
people have where, they can

convince people to see it their way.

CJ: no, I call that the art
of, telling people, no, I'm

making them love me for it.

Duke: I call it the art of Bs,
but not, not because, not because

they're speaking bs, not because
they're speaking Bs because it's

just, it's so hard to quantify.

CJ: Absolutely.

It is very hard to
quantify persuasion, right?

, This isn't the Star Wars universe, right?

There's no Jedi mind tricks.

These are not the joys you're
looking for, you do actually

have to have a conversation.

But I think it, this one's like a
next level skill, honestly, right?

Because you gotta have the base in place
first before you can even evaluate,

or even u utilize persuasion, right?

Like so on both ends, right?

Duke: and it comes in
different flavors, right, too.

Like some people got it because,
they're incredibly good looking and

they're super confident and super
magnetic and they were born that way

and you just can't help it, right?

It's nature.

CJ: Absolutely.

Duke: And then other people are just very,
very good at, you know, it's like the

people that always have the good point.

You know,

CJ: Yes.

Duke: are we ready to rock?

No, we can't go that way.

Why not?

Because of this.

Uh, that's a good point.

CJ: Right.

Yes.

Nobody likes that guy, by the
way, but he saves some lives.

Duke: Oh boy.

Yeah, so persuasion, it
comes in different flavors.

You don't have to be like the
incredibly super good looking,

ultra charismatic person.

It can come in your ability
to make a case as well.

And then what's the last one, Corey?

The fourth pillar of communication.

CJ: Interrogation.

Can the person that you're talking
to go deeper on the subject,

Without you feeding it to them?

Can you come with a, I won't say
surface level, but a setup, right?

A decent setup for, you know, the
conversation and or the problem statement.

And can that person take that?

Then dive deeper and come out with more
detail and more understanding and add

things to the situation that weren't
there previously, but are still relevant.

Duke: This is where I feel like the
BA role, when they're a good ba, they

have this interrogation skill down pat.

CJ: Yeah, I.

Duke: Because this is the skill
you use, when somebody says,

deploy ITSM, what's the goal?

Right.

The, the goal is to deploy ITSM.

Okay.

Why do you wanna, like, why
do you wanna deploy ITSM?

What's like, why do you
literally wanna spend a quarter

million dollars doing this?

What's the, you see what I mean?

Like, it's breaking it down
from the statement of I want.

to, something that we can actually
have legitimate requirements out of.

CJ: Yeah.

And it's super important, Because it
matters to the project often, like why

you're actually doing the project, because
there are gonna be some situations where

you're gonna have to make decisions
on the fly because not everything gets

figured out in the, preparation room, So
how do you make that decision on the fly?

Or do you just wait and , potentially
delay the project, right?

Because you're waiting to get an
answer back from a stakeholder,

and that might take a week.

Duke: Or how many times is this
gonna be wrong until we get it right?

Because nobody really drilled down,

CJ: Yep.

And so we're six or seven levels
deep, but nobody understands why.

Duke: Mm-hmm.

CJ: Yep,

Duke: Or, or we're like narrowing
down on V one of this app, but

nobody really understands what
it does for the customers.

CJ: yep.

Duke: We just got a whole
bunch of technical stuff.

So interrogation is the art
of extraction of information.

Okay?

So those are the four
pillars of communication.

And the two pillars of the trifecta
are capability and communication.

And the last pillar is my favorite.

If you have somebody who is fully
capable, maximally capable, and maximally

communicative, what is the one thing.

That differentiates that candidate
from the perfect trifecta

candidate, and the word is agency.

Can the candidate self determine what
needs to be done and take the action

without any kind of managerial catalyst?

Okay.

If someone is highly skilled, and
capable, and they're highly communicative.

but they need to be told what
problems to solve, Then they're,

just shy of the apex trifecta.

But if they have high agency,
this means they're already gone

out and hunting their own game.

They need as little as your influence
and energy as possible in order

for them to make drop the coin.

In order for them to make a maximal
impact for your organization.

So you get the three of those pillars,
capability, communication and agency,

and now you have the trifecta resource.

And we are excellent pattern recognition
machines like we go through this

process when we are evaluating
contractors to do work on our house.

When we're buying cars, when we're
doing anything really significant, we

want to know is this person that I'm
standing across from, the real deal.

And we've done that, since we
were living in capes, you know,

CJ: Yeah,

Duke: trust the fact
that you can spot this.

But I think a lot of people just need
to know that these are the properties

that exist and what to look for.

one person asked me, they said,
well, what if I asked them,

what's the hardest thing you did?

And they say, write a script.

Include what do we do then?

Well, they certainly haven't
demonstrated any kind of narrative

articulation in communication, and
they haven't provided you any agency.

So you're getting your
answer from the person

CJ: absolutely,

Duke: they're showing you right.

So if you're in a position where you're
like, gosh, I felt that was lacking,

or I wish they would've told me more,
or I'm having trouble extracting

this information outta the person.

You're lacking the communication
in the agency aspect.

CJ: Man, let me tell you.

That's so true, duke.

, The person who has this level of
agency that you wanna see is a person

that you can ask a bad question
and that person can take that bad

question and turn that into a way to
progress the conversation to the next.

Level.

They don't have to know exactly what
you were trying to get at, but they can

still take that information and put some
thought behind it and say, well, were

you trying to, or were you asking me?

Or, this is the way I
perceive that question.

And then go from there.

, If you don't have that level
of agency, you get an answer.

Like, you know, so what's the
most exciting thing you've done?

I built the script include.

Okay.

Well, most of us , know that a
script include is a container,

So it is not necessarily a thing.

And so if you're gonna tell me the
most exciting thing you did was build

a a container for code, then you
need to tell me why that's important.

Duke: And not even technically
important, but what happened?

CJ: Exactly like what turned
this boring thing, exciting.

Duke: We're still in a world
where, okay, maybe I know what

characteristics to listen for, but
there also needs some coaching about,

I call them hard to fake questions.

Or questions where you require
more than just a definition.

If somebody was like exquisite, like
memory recall, really good reading, and

just like went over tons and tons of
ServiceNow material, they could probably

do a convincing definitional interview,

CJ: Yep.

Duke: Without even really
having demonstrated experience.

So here's some categories
of hard to fake questions.

So number one is define and contrast.

This is what is the difference
between X and Y and Y?

Does it matter?

CJ: because typically you don't want like
a yes or no, answer to a question, right?

Duke: Yes or no?

Answers are the.

CJ: Right.

Like if you get into a spot where
you're conducting a conversation,

with a a potential hire, , and
all of a sudden the only thing

you're getting back are yes or nos.

You have went down the wrong route
at some point, , you found yourself

in a place where you didn't expect
to be in this, in this interview.

And that alone.

Can sometimes be enough, To say, yeah.

Wrong person,

Duke: They got a, they got a 50 50 chance
of being right, even if they don't know.

CJ: Yes.

Duke: So definitely no yes or no answers.

But if you ask them a define
and contrast, this requires both

definitional and contextual knowledge.

CJ: Absolutely.

Duke: Like what's the difference
between, I don't know, a UI

policy and a script include?

CJ: Yeah.

And why does it matter?

Yeah, or, and

Duke: No, wait.

Oh wait.

Ah.

A UI policy and a client script.

CJ: yeah, I was gonna say, or I say UI
put policy in the data policy, right?

Like, you know,

same difference.

Duke: good one.

Good one.

Yeah.

Yeah, yeah.

That's a good one.

That's a good

CJ: You know, slowly, I mean, 'cause
you can use both of those in most

cases, but there are some cases
where you only want the data policy,

Duke: Yep.

And you know what the paradox is?

You know what the paradox is?

If you know nothing about ServiceNow,
you can ask 'em a question like that.

What's the difference between
a UI policy and a data policy?

Even if you don't know the answer, if
you feel convinced by them, you might

have the resource you're looking for.

CJ: Yeah,

' Duke: cause we can see it, right?

there's a difference in somebody's
presence, in their voice, even if

you can't quite see them, right?

can tell when somebody's giving
you the definition versus giving

you the hard fought experience.

CJ: Yeah, it's just gonna be
additional context to it, right?

Because when you, I mean, Google, right?

Like what's the difference between
a UI policy and a data policy?

You'll get a fairly decent answer.

You won't get a fairly decent answer
that passes an interview like this,

you'll get a definitional answer.

You

Duke: it's kind of an
uncanny valley of it,

CJ: Yeah, absolutely.

you want a contextual answer.

Right.

The difference is that you, a data policy,
prohibits, these things at the, database,

okay, and why would I want to do that?

Right?

Like, 'cause that's, to me it's
like, okay, so you know the

definition, why would I wanna pick
that versus a UI policy, right?

Like, give that context too.

Context is king and key.

the next one, duke, is extremely
important as well, right?

Wisdom from experience.

Those are the situations where
you're asking someone, Hey.

Tell me about an experience
when Dot, dot, dot, whatever.

Dot, dot dot might be.

Duke: and this will, definitively show
if they're good communicators or not.

CJ: Absolutely.

Duke: Right?

CJ: now you, 'cause you're
asking them to tell your story,

Duke: from your own life?

Right?

CJ: Yes.

Duke: Which, which supposedly has
been spent doing hard things up to

now, because now you're applying for
a really serious senior position.

So you had to have been in
a trench fight or two, so.

If they struggle here, you're dealing
with maybe somebody who's lower

on that communication spectrum.

there's a few things we
want you to test for here.

So get them to tell multiple stories.

I ask 'em about technical and political
situations, tell me about the, best

app deployment you ever had, right?

Tell me about the most sensitive
political situation you are in.

Did you win and lose?

Win or lose and how?

CJ: Right.

Duke: Because it's real life y'all.

Um, getting the most technically
capable resources doesn't mean you win.

CJ: Sometimes just knowing how to
do the thing isn't enough, You need

somebody who can convince the people
who hold the power to allow the thing

to be done And that's important.

and look, the level that
we're talking about.

these things we're not at a, what
is a business rule level, the person

that you're hiring is going to
be interacting with some level of

leadership, even if it's just the
leadership of the platform itself.

, The person that you're interviewing
is going to have some communication

with leadership, and so it's
important, that that person can speak

to both technical and political,
situations and, hard things in those

situations and how they handled them.

Right?

I don't wanna know just about successes.

I ain't learn.

I I've never learned anything
when I've succeeded at.

I'll just be honest, right?

, All of my heartfelt lessons have
come when I failed and fell on

my face and it's like, oh man.

that's what a hole is.

Don't step in that.

Duke: Yep.

Once bitten, twice, shy,
all that stuff, right?

Um,

CJ: So if you ask me to like tell you
a story about where I screwed up, or

if you ask me to tell you a story about
something that resonates with me, I'm

going to go straight to the screw ups.

all the stuff that I did well
is just not, not exciting.

Duke: You don't wanna hire a bodyguard
that's never been punched in the face.

You know,

CJ: yes.

Duke: like you might have all the
technique in the entire world, But

CJ: Yep.

Duke: Who, who said it?

Everybody's got a plan until
you get punched in the face.

CJ: Mike Tyson and I actually
went and looked it up.

He actually did say it.

So that was not an internet meme.

That's

Duke: Yeah, that sounds like some
serious Mike Tyson wisdom too.

but it's true.

there are people with good technical
chops who have never stood in the fire

of, a room full of angry stakeholders.

CJ: Yeah.

Duke: Or a stakeholder who
like, I want mine now too.

And not realizing that it's not them
versus you, it's them versus their peers

who also want their stuff prioritized.

So anyways, uh, be sure to ask
about both victory and defeat.

Be sure to ask both technical and
political, and you can ask a wide variety.

You can just pick out features,
like tell me about an experience

you've had with the catalog.

With Portal.

With script include, but
also higher level stuff.

What's the best thing you
ever deployed in ServiceNow?

CJ: Yeah.

How did you manage to get budget,
for, that new app, right, that

was, that you felt was gonna save
your team,, 20% productivity?

Duke: Alright.

There's a third category that we came
up with for hard to fake questions,,

we call it utility and consequence.

. This would be a little bit lower
down the totem pole than tell me

about a custom app or whatever.

But this would be like, tell me about
a time you used a record producer.

There you go.

Tell me about a time you like
but you see the difference there.

It's like, what is a record
producer versus tell me about a

time you used a record producer.

It one is a lot harder to answer and.

Possibly shows, some agency
shows some communication ability.

Like you might not even know what
a record producer is, but if they

give you a convincing answer, like
maybe they teach you something and

you got your good communicator.

, CJ: That last piece that's really
good, you might not know and

maybe they teach you something.

I think in almost every situation,
the person that you wanna hire as an

outcome of this process you should
walk away from the interview thinking.

Damn.

I know more now than when I went in
thanks to talking to that person.

If you don't get that immediate
warm and fuzzy, I'm not gonna say

that's not the person, but it's not a
clear cut sign that it's the person.

I should be able to walk out of
the situation and think, man, I

didn't know you could actually
do that with scripted rest APIs.

Huh.

That's pretty interesting.

Duke: You know what, there's a fourth
category of hard to fake questions.

I just didn't even like snap to until now.

CJ: What

Duke: The fourth, the fourth
category is opinion questions.

CJ: Ooh, yes.

Duke: not what is what isn't.

Or did you, ever deploy ITSM?

Like, Hey Robert, , have
you ever deployed ITSM?

Yes, a bunch of times.

What's your least favorite part
of ITSM as on the platform?

CJ: Yeah.

Duke: Now, you don't have to
tell ServiceNow that you're

asking these questions, but

CJ: Exactly.

Duke: you can discover a lot by asking
somebody, like what would they improve if

they could rebuild this part of the app?

CJ: Or what's your least favorite part
of the deployment process for ITSM?

Duke: Oh yeah,

CJ: Right.

Because there are some parts
of this process that you will

have to go through, right?

Like you can't have A-I-T-S-M without
having either some kind of category tree.

I know.

Ask you about category trees, but,
or some kind of function in CMDB,

you gotta have something there to
take up that, categorization aspect,

which is that, important or not?

Right?

Like, you know, things like that, so, oh.

Duke: You can also ask it in the opposite
direction, like, what's your favorite

feature on ServiceNow, or favorite
feature of, whatever area you're in,

like CSM or facilities or, what's your
favorite outcome that you've provided?

With that, but , it takes a
certain level of experience

to be opinionated on products,

CJ: Yes.

Thank you.

That's great.

That's exactly it, you can't have an
opinion unless you've actually been in

a fire long enough to have an opinion.

What's your favorite part
of the platform, duke?

I.

Duke: probably flow designer.

CJ: Yeah.

That doesn't surprise me.

Duke: And it wasn't always, there was a
time where if somebody said, what does

ServiceNow have to work on the most?

I would've said, flow designer.

But they have a great PM over that and
he is taken it so far I, I love it.

And I know there's a lot of raw devs
who are like, well, it's just, faster.

If I code it and I can,
get that at some level.

But to me, the spirit, the beating
heart of ServiceNow has been how much

can we build with minimizing the amount
of development talent that you need?

Whizzbang developer can get this
done in an hour with raw code, but

then they go to the next job or
whatever, and somebody who's not

a whizzbang developer inherits it.

They can't even read it.

You know, like,

CJ: Yeah.

Yeah,

Duke: anyway, we could do the
whole , flow designer versus not

Flow designer as a separate episode.

But Flow Designer is probably
one of my favorite things.

'cause it's, it's kind of universally
applicable, like every module can use it.

CJ: I

Duke: Every skill level
of person can do it.

There's just a lot of clever stuff in
there too, like I just love using it.

What about you?

CJ: Two things, one is the integration,
set module, So think transform mapping,

external data sources, that sort of thing.

I like pulling data
in , from various sources.

And then normalizing it and then using
it in my Service Now processes and apps.

that one is probably my favorite one
because of what you can do with the

data during the normalization or the
transform process, there's so many

different ways to script it or key
certain things to happen based on

data that you're importing, right?

It's just a, it's almost like a blue
sky, and that's what I like about it.

, The second one would be a app that is
now unfortunately retired, but would

have been my number one if it wasn't.

And that's data
certification, like data cer.

when I tried to add it, , it
was like, yeah, no, that's gone,

Duke: Oh, I love data search.

Oh, man.

CJ: dude.

Duke: I gotta be careful when I.

CJ: so I love data certification and
the reason I love it, is because like.

Service Now has a tendency
of building apps and then

putting guardrails around them.

It's like, oh yeah, data certification.

You can only use it on a task table, Uhuh.

Actually you can't, you
can use it anywhere, right?

It's just a, it's a little
filter in a business rule or

something somewhere, right?

You just comment at a little piece of
code and boom, all of a sudden data start

can run on every table in the instance.

Shh, don't tell anyone.

but, but then you can do
certain things with that.

being able to certify anything
opens the door to keeping everything

running correctly, and that's the
reason that I love it so much.

Right.

Because there's so many objects and
ServiceNow that where ownership of

the object matters and over ownership
of the OB object drifts over time.

How do you keep up with that?

Duke: And everybody talks like
governance, governance, governance.

Right.

But how do you, but how do you Governance?

CJ: Right, right.

And manual audits are expensive,
if you've already trued up this

certain class of objects, right?

And you've got ownership for
everything, you don't wanna have

to do that again in two years.

Duke: Uh, we're gonna have to record
two episodes in a row, aren't we?

CJ: We might have to.

Duke: Alright, so the original plan
was we'd actually go through a list of

specific questions, but I think we gotta
skip to one other thing we really, really,

really, really gotta do for this episode.

So, , wherever you see this, leave a
like, leave a comment that you wanna see

the next question, episode, and we'll do
an episode entirely based on questions.

And we'll all link 'em back to
the trifecta for testing for

Capability Communication and Agency.

So just leave us a comment.

but the last thing we wanted to address
was virtually testing people, ? Because

even with what we've covered so far, there
are people who are that good at talking

that they can just get past your defenses
and you could like them, or you can

just imagine that they're demonstrating
capability, but you don't know for sure.

And so you want to actually get these
people on an app and testing stuff.

I was recently asked to suggest
some virtual tools where you log

in together and there's an IDE
there and all this kind of stuff.

And because I suggest those isn't
dawned on me like, why don't you

just use a ServiceNow PDI for that?

You don't want to test
their raw JavaScript.

You want to test their JavaScript
in the context of ServiceNow, right?

Or even if it's not scripting per se,
like maybe you wanna do troubleshooting

or maybe you want them to talk about
SLAs from the SLA form or something.

But it's better just to have an app
that you could just screen share.

we're gonna talk a little bit
about the logistics of that.

And the first point is, it must,
must, must, must, must, must be a PDI,

CJ: Yes, absolutely.

That's just baseline, right?

You want folks to be able to
show you in service now how they

can do things in service now.

Duke: But you don't want to do it
from your own instance in particular

because they don't work for you.

Your data's on that instance, right?

And they're gonna see it.

So you're gonna have people's contact
information or possibly data about

real incidents that actually happened
and just, it can't be a copy.

Even an old, old, old
copy of your instance.

It must be a PDI.

There's no way around it.

Yeah, I know.

You got your own custom apps,
your own way of doing things.

You're gonna have to find a
way to test them without it.

'cause you don't want 'em seeing.

You can have admin access or some
kind of like heightened access

to do stuff on the, , platform.

So just like be a security mindset,
put it on a fresh instance.

, You can test people's capabilities
without seeing your stuff specifically.

CJ: I mean, you can always Stage
a PDI you can have your update

sets and your app application
repositories, so on and so forth.

Stage the thing up and, then let
people jump on it , and do the thing.

the second thing I'd say though is
that if you are in this situation

where you're saying, okay, get
into PDI and show me what you got.

You also have to allow folks to
use everything that they would

use if they had the job, And
what I mean is, can they Google?

Yes, they should absolutely be able
to Google, what browser can they use?

Right?

Whichever one that they want or
whichever one that your company allows,

are you gonna allow them to use ai?

Yeah, you should allow them to use AI
if your company allows AI to be used.

these are all things that,
that you want to get.

You want to have the interview,
as close as possible to someone's,

real life work and experience,
and also their current comfort

level, Because are they competent?

Not, are they comfortable in this setting?

Duke: it's so artificial to put
somebody in a vacuum chamber,

and say, go develop this thing.

Really talk to anybody, honestly,
in the ServiceNow ecosystem.

And it's like, man, I got one
window up for ServiceNow community.

I got one window up for the
ServiceNow discord I've got.

Chat GPT up on one computer.

Like I work in ServiceNow.

We have our own internal AI tools.

I got that up.

and organizations, they are like,
use the ai, let the AI help you

do this, and like AI coworkers and
AI copilots and blah, blah blah.

And then it's like you go in for
an interview, it's like, okay, no.

Get in the vacuum chamber,

CJ: Right?

Duke: no outside information from nothing.

And just do this all from recall.

CJ: Yes, it is like, no,

Duke: When everybody knows nobody
works like that in the entire world,

CJ: Absolutely.

nobody does it, and so don't
do an interview that way.

It's, it is dumb.

And, it won't allow you to get
the best, the best candidate.

Duke: So yeah, just let 'em, let 'em be.

Let 'em use whatever resources they want.

You might learn something.

CJ: Absolutely.

All right.

What we got next, duke?

I.

Duke: Come up with the build
scenarios that you want.

This is gonna require that you have
somebody else with some technical

expertise if you're not that person.

but I would suggest some build
scenarios, like have them build a

record producer, have them build
maybe a simple catalog item.

Have them build a simple flow
with less common concepts.

CJ: I like it.

I like it.

Especially the less common concept part.

Duke: yeah, like maybe do it on
a schedule or do it on an inbound

email or so, you know what I mean?

Like,

CJ: Or how do I have the, flow.

pause until a certain thing
happens and then pick up again.

Duke: yeah.

Or have them, demonstrate, Two
of the methods that they think

are cool from glide record
that aren't, ad query or query

CJ: Yeah.

Duke: and just see what
they bring you, right?

CJ: I have gotten some really interesting
answers from, candidates over the years.

none that I can think of off the top
of my head, but some that I definitely

went and took notes of and went
and looked up after the interview.

Like, oh crap, I didn't
know what we could do this.

I,

Duke: My favorite eyebrow raising
moment with that was somebody

who did dot underscore next.

CJ: Ooh, yeah, you know, duke, I just
asked you about that one recently.

Duke: Yeah.

And dot underscore.

Next is if you have a table that
actually has a field called Next.

It will stop, glide record
from performing properly.

And so you'll, you say if do
underscore next factors for tables

that might have the word next in it,

CJ: Nice.

Yeah.

Duke: or you ever, I have a person
who's like, I need to do a glide record,

but they're not using Glide record.

They're doing glide query instead.

Like that's always an,
it's like, okay, all right.

you sit at the teacher's desk.

I'm gonna sit Yes.

CJ: Yep.

Learned something new today.

Duke: Okay.

Another one I would go for have things
ready that you want them to build on

the fly or explain on the fly actually,
that maybe may, maybe a three tiers.

So something you want them to build,
something you want them to explain.

But have it built already.

Like explain this flow to me.

Explain this script.

Include, explain this client script.

CJ: Yes.

Duke: And they don't have to like
code, but if they can read it

right, it is still capability.

And

then the last one, go

CJ: I love that.

I mean, so think about it, instead
of explain, here's a scripting clue.

write some comments for me.

Right.

Tell me, this is a scripting clue.

There's no code comments.

gimme the code comments on what this does,

Duke: Yep.

and then the last one would be to,
to literally build failing cases.

CJ: Yeah.

Duke: A good one would be build
any flow that's rigged to fail.

There's a bunch of different
ways you could do that.

CJ: Oh

Duke: But you're specifically
looking for somebody who's just

gonna like, open up the studio and
run it and watch the data happen.

Right.

they should be able to go to the
debugging tool and just show you like,

CJ: Yeah, this is where it crashed.

And this is why.

Duke: But so many people are so caught
up on like, can they JavaScript,

you know, but that's not the be
all end all technical capability.

CJ: I got an interesting story about
this, when I was, applying for a job

in it, a long time ago, they had to
come in and gave me like a test, right?

had to take this computer and do stuff
with it, Got everything right except for

one thing, which was the network card,
couldn't get the network card connected.

Reason I couldn't get the network card
connected Duke is because they have put

transparent tape over the interface, pens.

So and put it back in the

slot.

Yes.

Yes.

So there was,

Duke: a test

CJ: they did that as a test and it was,

they, they had Right, that was a
warning that I should have taken.

I did not take it.

And,

and I stayed at that job for three months.

But,

Duke: That would mean dude.

CJ: Dude, like tape over
the freaking interface and

plugged it back into the slide.

Like, you gotta be kidding me.

And I walk in there, dude, like
I'm hot stuff I, I, I, I in my

sleep and I could not get this
thing connected to the network.

Man.

I was so frazzled.

Duke: Wow.

CJ: Yeah.

don't do that though.

Duke: No, for sure.

Don't be mean about it.

You can go a long way, even
with simple stuff, especially.

If you've got somebody who's got the
good communication and high agency.

'cause maybe they're gonna volunteer
something like, yeah, okay, I

found out what's wrong, but maybe
you could avoid this entirely by

writing the flow designer this way.

CJ: Yes.

Duke: Or hey, this isn't a
great case for flow designer.

Maybe you'd consider a business rule.

Like they're coming up with their
own things to advise you on, on

top of what you asked 'em to do.

And that's all part of
finding that prime resource.

CJ: Absolutely.

When they look at your thing and
be like, why'd you do it this way?

, That's the person.

Duke: last but certainly not
least on how to test people

on A PDI is that all of these.

build, explain, fail test cases.

please just put them in update
sets when you build them, and then

export those update sets, or X mls
if it's raw data that you need.

because , you might want to interview
like three, four people in a day and

you want to just be able to blow away
the instance and then just , whoop,

pop those things right back on.

And so put them in update sets so that
you only have to chew your food once.

CJ: I like that.

Yeah.

You only wanna chew the food once,

Duke: Yeah.

We aren't Aries up in here, man.

You're,

CJ: Oh man, that, that is like a
visceral, image in my head right now.

Duke: yeah, and it works.

What time are we at?

CJ: Oh man.

Dude, we've been going for a minute.

think we're probably at at a point
where we should stop going for a minute.

Duke: Okay, so we've been
on this for 48 minutes.

Hopefully you found
something valuable in there.

And again, let's leave us a comment if you
want us to do a whole dedicated episode

on specific questions we would ask in
various scenarios from interviewing.

excellent devs, architects,
implementers of various processes.

but we need your help.

We need your interactions on the posts.

Let us know.

CJ: definitely let us know
and, we'll make that happen.

Duke, I got a great idea for this.

I'll tell you after we
press end on the recording

still.