►
From YouTube: Meet the Tanukis 1.7: Wayne Haber
Description
In this episode of Meet the Tanukis, we talk to Wayne Haber, Director Engineering for Security, Applied ML, and Growth. Wayne tells about how he got into tech, what he's working on with his teams, and other exciting topics.
0:00 - Intro
1:53 - Pj
5:05 - Wayne!
5:25 - Wayne Introduction
7:16 - Machine Learning to recommend reviewers for code
7:54 - Talking about the Anti-abuse team (Spam and CI abuse)
10:45 - How Wayne got into coding, engineering, and tech
11:15 - Hot-Swap Game cartridges
13:20 - Wayne enters University
14:50 - 2nd developer at a company to CTO
20:33 - initial role with GitLab
23:50 - What does the Growth team do?
27:00 - "A failed experiment is not a bad thing"
29:40 - Secure stage vs Defend Stage
32:55 - It's all about balancing risks
37:12 What's new with your teams?
39:20 We're Hiring! https://boards.greenhouse.io/gitlab
41:50 - The Handbook! https://about.gitlab.com/handbook/
42:25 Goodbye!
A
A
B
Gonna
get
another
episode
pj,
and
I
proved
that
no
well,
no
one
said
that
actually,
actually
everyone's
been
really
supportive
and
kind.
But
here
we
are
meet
the
tanuki's
another
episode,
and
this
is
a
special
episode
for
me,
because
we
are
talking
to
someone
who
is
outside
of
my
immediate
team
for
the
very
first
time.
So
for
those
of
you
who
don't
know
who
are
new
here,
my
name
is
pj
matt,
I'm
an
education
evangelist
at
git
lab.
B
This
show
is
meet
the
tanuki's
and
I've
got
this
new,
weird
setup,
where
I'm
looking
right
down
the
barrel
of
my
camera
here.
But
when
I
want
to
look
at
my
screen,
I
gotta
look
over
here.
So
what
if
I
do
like
this
and
it's
a
little
better,
but
now
I'm
like
it's
always
hard
to
know
where
to
put
your
camera
where
to
have
your
screen.
But
these
are
the
type
of
kinks
that
are
gonna
get
worked
out.
The
more
I
do.
This
amazing
show
so
meet.
B
A
B
Haven't
been
following
me
on
twitter,
you'll
know
why
this
is
in
my
life,
so
follow
me
on
twitter
to
learn
more
about
mountain
dew
kickstart.
So
I'm
very
excited
for
the
show
today
because,
like
I
said
it's
a
team
member
who's,
not
in
my
immediate
team,
I'm
on
the
what's
called
the
community
relations
team.
We
are
full
of
developer
evangelists
and
program
managers
and
education
managers
and
open
source
people
which
we
are
hiring
for
open
source
project
managers.
B
If
you
want
to
come
in
and
be
a
part
of
our
lovely
team,
but
our
team
is
all
about
reaching
out
to
the
community
and
and
finding
out
what
developers
need
what
they're
doing
finding
ways
for
them
to
learn
to
to
level
up
and
getting
really
involved.
And
today
we
are
talking
to
someone
who
is
not
only
not
on
my
team
but
kind
of
sort
of
really
super
duper
important.
B
So
I
get
a
little
nervous
because
I'm
talking
to
someone
who
is
a
director,
a
director
of
engineering
for
growth
and
security
and
applied
machine
learning-
and
this
is
a
very
exciting
get
for
us-
and
he
came
to
us
and
said
I
think
your
show's
interesting.
I
want
to
be
on
it
and
said
well
come
on
through,
so
everyone
please
give
a
warm
welcome,
clap
at
your
computer
screens.
We
can
hear
you
it's
just
like
tinkerbell.
We
need
to
pause
to
live.
Please
welcome
to
our
stream
wayne
hey
there.
B
B
C
Sure
so
I'm
wayne
haber
one
of
the
directors
of
engineering
at
get
lab
and
as
pj
as
you
mentioned,
a
couple
different
teams
that
I'm
responsible
for
the
sec
section
or
security
section.
That's
responsible
for
the
security
features
of
the
gitlab
product
that
customers
and
users
use
to
make
sure
that
they're
the
code
that
they're
writing
is
secure,
then
also
the
growth
team,
which
does
experiments,
growth,
experiments
or
growth,
hacking
in
the
product
to
connect
users
with
val
with
features
and
with
value.
B
That's
fantastic
two
years
in
a
couple
months,
so
it's
that
seems
like
I
feel
like
two
years
ago,
was
a
period
of
like
a
lot
of
growth
for
gitlab.
I
know
people
who
were
here
my
co-worker
brendan
o'leary,
my
team,
my
teammates,
he
has
been
at
get
live
for
about
four
years
and
he
was
like
in
the
low
hundreds
and
I
feel,
like
our
employee
count
just
skyrocketed
two
years
ago.
So
you
came
at
a
really.
B
C
So
the
model
of
steam
is
more
there's
a
couple
different
areas:
there's
using
machine
learning
like
right
now
we're
working
on
implementing
one
of
the
first
machine
learning
specific
features
in
the
product
itself
to
recommend
reviewers
for
merge
requests,
aka,
pull
requests
where
they're
using
patterns
identified
by
the
machine
learning
to
find
who
would
be
best
to
review
a
merge
request,
which
is
great
in
terms
of
just
the
developers,
morale
and
also
the
time
to
merge,
is
a
really
important
thing,
because
that's
really
about
the
efficiency
of
the
development
teams.
That's
working
on.
C
We
have
the
anti-abuse
team,
which
looked
at
abuse
of
the
platform
itself,
which
is
in
two
different
areas.
The
primary
focus
are
is
spam,
where
people
put
spam
into
issues,
comments
or
descriptions
or
merge,
requests,
etc,
and
then,
which
you
know
it's
then
viewable
online,
but
also
can
generate
emails
to
people,
which
is
what
spammers
are
after
and
then
also
abusing
the
ci
features.
The
continuous
integration
features
where
people
so
continuous
integration
is
about
building
the
code
building
and
deploy
primarily
building
the
code.
C
C
Sometimes
it's
definitely
okay
and
we
let
it
go,
and
then
there's
that
in
between
where
we,
the
line
changes
as
both
legitimate
users
change
what
they
do,
where
we
don't
want
to
block
them
and
the
the
bad
actors
also
chip
away
at
what
we
have
in
there
and
find
ways
around
it.
Occasionally.
And
then
we
look
at
those
things
and
then
find
ways
to
protect
against
those
things.
B
Yeah,
that's
exciting.
I
love
both
of
those
ideas,
the
idea
of
like
knowing
who
to
give
a
verge
request
to,
because
one
of
the
things
that
I
always
get
worried
about
when
I'm
making
emergency
quests
and
I
need
to
make
a
change,
I'm
like
all
right,
if
it's
not
for
my
handbook
and
I'm
not
sure
who
I
need
to
give
it
to.
I
get
really
confused
at
that
point.
So
it's
really
cool
that
you're,
using
machine
learning
to
help
users
find
the
best
possible
person
and
again
like
like
most
machine
learning.
B
It's
not
a
we'll
just
trust
the
computer,
and
it's
always
going
to
be
right.
It's
here's
some
advice,
here's
where
we
think
it
might
be
based
on
previous
patterns,
but
that
crypto
mining
stuff.
I
remember
when,
when
that
was
sort
of
affecting
a
lot
of
ci
companies
who
are
having
their
their
their
cpu
and
their
processing
power
being
abused
and
again
like
cryptocurrency,
is
whatever
but
like
it's
it's
using
other
people's
power
to
mine.
Like
that's,
not
that's,
not
great,
that's
so
cool!
That's
that's
awesome!
B
C
C
Then
you
could
actually
read
the
data
off
the
cartridge
so
and
then
a
family
member
who's,
much
older
than
I
was
said,
here's
this
bit
of
assembly
code.
That
makes
so
you
can
copy
this
data
over
to
the
over
to
a
tape
drive.
This
is
really
quite
a
while
ago,
that's
kind
of
neat.
Maybe
I
can
improve
that.
I
can
learn
enough
assembly.
C
C
Yeah
and
then
I
started
it's
really
well
like
where
I
got
interested
and
I
started
learning
basic
programming
and
then
back
then
c
programming,
which
was
a
lot
of
fun
and
I
was
still
in
high
school
and
I
wanted
a
job.
I
wanted.
Some
extra
spending
money
and
I
went
into
the
newspaper-
was
at
the
time,
so
you
did
it.
I'm
in
the
newspaper
looking
at
job
listings
of
physical
paper,
and
I
thought
I'm
gonna
look
for
c
programmer.
I
mean
I'm
16.,
I
don't.
C
C
It
basically
made
me
an
interim
at
a
computer
company,
the
software
compiler
company,
and
I
learned
I
had
a
lot
of
fun
there
doing
doing
working
on
actually
the
manx
cross
compiler,
which
was
a
second
or
third
tier
company,
but
was
still
doing
quite
well
at
the
time
company,
maybe
40
or
50
people.
I
did
support
and
worked
worked
on
a
little
bit
of
the
code
there,
which
was
a
lot
of
fun.
They
went
to
school
for
computer
science.
C
C
So,
for
example,
you
know
I
learned
the
theories
of
data
structures
and
things
like
that,
but
also
like
my
favorite
class
was
writing
a
relational
database
from
scratch.
The
whole
semester
was
doing
that,
so
it
actually
had
to
you
know,
interpret
the
sequel
store,
the
tables
be
able
to
do,
joins
and
was
introduced
back
then
to
automated
testing
as
well.
Where
the
professor
didn't
check
anything
herself,
she
wrote
automated
tests
to
check
the
code
written
by
the
students,
which
is
pretty
neat.
I
still
remember
working
on
that.
B
B
Much
grading
to
do
and
you're
a
computer
science
professor,
like
listen,
people
are
doing
it.
It's
possible,
you
don't
need
to
use
blackboard
or
heaven
forbid.
If
some
of
you
are
still
hand
writing
code
and
turning
that
in
get
on
the
bus,
we're
waiting
for
you
so
continue.
That's
a
that's,
really
cool
a
relational
database.
That
was
the
whole
course
and
all
automated
testing
to
get
your
grades.
That's
awesome
continue.
C
C
I
was
in
the
midwest,
then
decided
to
move
to
atlanta,
and
I
interviewed
a
couple
different
companies,
and
this
is
company
where
it
was
a
number
of
companies
were
very
traditional,
and
you
know
people
dress
up
in
suits
and
things
like
that
or
I'd
be
traveling
all
the
time
which
I
wasn't
necessarily
looking
forward
to
that.
Although
that's
what
I
ended
up
doing.
C
Interview
to
one
company,
it
was
a
company
of
like
20
people
and
the
ceo
was
wearing
shorts
to
the
interview,
and
I
thought
that's
kind
of
you
know.
She's
just
super
casual
went
there
and
I
was
the
second
developer
at
the
company.
This
company
did
software
for
hospitals
to
move
data
between
hospital
systems
and
medical
systems
yeah
and
did
a
lot
of
consulting
in
that
area.
C
I
was
the
second
developer
to
kind
of
take
what
the
consultants
were
doing
and
make
it
into
a
product,
and
I
didn't
know
really
what
I
was
doing
to
organizing
projects.
But
nobody
was
organizing
the
work
because
we
grew
the
team
to
five
six
people.
Nobody
knew
what
the
priorities
were.
There
were
no
like.
B
C
C
Yep
security
focused-
I
took
over
the
development
team,
which
was
five
people
at
the
time
and
then
built
it
up
over
time,
where
hired
a
whole
bunch
of
people.
I
think
we
got
to
about
40
people
then
started
acquiring
our
competitors,
so
acquired
two
competitors
were
around
the
same
size
and
then
took
the
role
of
integrating
the
best
of
the
technologies
so
fast
forward
from
there
about
five
years.
We
were
probably
we
went
from
one
office
to
in
the
us
only
of
course
to
I
think.
C
Definitely
and
then
started
integrating
those
companies
doing
architecture
work
things
like
that
had
a
portion
of
the
engineering
team,
and
then
we
were
acquired
by
dell,
which
was
which
was
interesting
and
they
kept
us
mostly
separate.
That's
that's
how
dale
treated
that
acquisition
at
least
and
stayed
there
for
a
number
of
years
afterwards,
and
then
dell
actually
spun
that
company
off
and
ipo
the
company.
I
was
able
to
attend
the
nasdaq
pub
ipo
event,
which
is
kind
of.
B
And
then,
while
you
were
at
kit
lab
we
ipod
as
well
so
like
very
exciting.
Oh
my
gosh,
like
that
idea
of,
like
like
your
first
job
in
tech,
was
as
a
high
schooler.
You
accidentally
saw
an
ad
for
it
and
then,
after
that,
you're
like
okay,
I'm
gonna
seriously
pursue
this
earlier.
When
you
were
talking
about
exposing
the
code
of
video
games,
pyrox
came
with
a
comment
called
hot
swapping
and
I
guess
that's
the
official
name,
for
it
is
like
not
quite
putting
the
cartridge
all
the
way
in.
C
C
Like
the
right
most
pins
would
say,
can
you
do
anything
other
than
just
run
the
code
on
it,
so
that
when
you
turn
on
the
compute,
when
you
turn
on
the
game
system,
it
would
allow
you
to
read
the
data,
but
it
wouldn't
automatically
run
it.
So
you
could
actually
load
code
from
elsewhere,
download
the
cartridge.
B
Yeah
for
those
of
you
born
after
1999
games
used
to
come
on
cartridges
and
it
wasn't
just
automatically
downloaded
from
the
internet.
Oh
interesting,
so
pyroc
with
another
comment:
they
wanted
to
do
hot
swapping
for
banjo-tooie
initially
to
get
the
game
data
from
the
initial
banjo-kazooie
cartridge.
That's
by
the
way,
banjo-kazooie
one
of
the
best
games
of
all
time
pie
arc,
and
I
used
to
play
it
all
the
time
as
kids,
fantastic
stuff.
So
so
wayne
you
work
at
this.
This
security
company
they
get
acquired
by
dell.
B
C
C
Okay-
and
I
did
that
for
about
six
months
and
then
we
changed.
Let's
see
I've
actually
in
two
and
a
half
years,
I
think
I've
changed
four
times
my
role
in
some
way.
Then
I
took
on
the
growth
team,
then,
in
addition
to
the
protect
stage
and
great
great
team
there
that
already
existed
to
do
these
experiments
on
the
product
to
see.
A
C
A
B
It's
going
to
be
kind
of
exciting
to
like
like
leave
a
team
and
then
come
back
to
it
and
sort
of
see
where
it's
progressed
to
and
see
what
stuck
around
and
what
didn't.
But
I
really
want
to
ask
about
the
the
experimental
stuff
and
the
the
sort
of
like.
Oh,
what's
the
name
of
that,
that
group
that
we
just
talked
about.
B
C
Abs,
absolutely
so
the
team
does
experiments
and
a
failed
experiment
is
not
a
bad
thing.
You've
learned
something
that
doesn't
work.
That's
why
you
do
it
as
an
experiment,
so
an
example
would
be
we
wanted
to.
We
thought
we
had
a
theory
that
if
we
provide
a
readme,
a
default
readme
with
steps
on
what
to
do
for
new
projects
that
we'd
see
more
usage
of
more
features
in
those
projects.
C
C
C
That
we
did
is
we
sometimes
expect
the
experiments
are
more
complex,
like
that,
like
you
know,
having
a
new
file
and
new
features.
Sometimes
it's
really
simple.
Like
we
change
the
email,
we
send
the
formatted
email
we
send
when
you're
in
gitlab,
and
you
invite
another
user
of
your
project.
Okay,
changed
it
to
where
it
came,
instead
of
from
quote
unquote,
git
lab
and
the
from
email
address
to
the
name
of
the
user.
C
That
did
the
invite
we
thought
well.
If
somebody
sees
a
name,
they
know
they're
more
likely
to
click
on
it
yeah
and
it
turns
out
it
has
like
a
0.2
or
something
like
that
difference
in
people
clicking
on
those
emails
when
we
did
it
to
10
or
20
percent
of
users.
So
we
could.
You
know
it
actually
didn't
help
much
if
at
all,
not
stiffly
significant,
so
we
didn't
roll
forward
with
that.
As
an
example,
that's.
B
The
both
of
those
seem
counterintuitive
to
me
because,
like
when
I
get
a
the
automatic
readme
that
populates
one
of
the
first
thing
I
do
is
I
highlight
it
all
and
delete
it,
but
for
an
email,
if
it
came
from
someone
I
know
I
feel
like
I'd,
be
way
more
likely
to
to
open
it.
That's
so
and
that's
the
reason
why
you
do
an
experiment
you're
like
well:
let's
try
it.
B
Let's
see
what
happens,
because
if
you
just
asked
me
and
trusted
me,
neither
of
those
would
have
gone
well
at
all,
because
I
don't
know
what
I'm
talking
about.
So
that's
fantastic.
The
idea
that
that
whole
group
just
gets
to
sort
of
like
make
changes
and
see
what
happens.
That
sounds
like
an
exciting
group
to
be
a
part
of
talk
to
us
more
about.
B
C
Yeah,
it
is
really
interesting.
You
have
to
remember
that
not
a
failed
experiment
is
not
a
bad
thing.
You've
learned
something
that
doesn't
work.
That's
why
you
you
do
it
to
a
minimal
level
and
a
minimal
viable
change,
but
you
also
want
to
experiment
on
a
percentage
of
users
before
you
do
it
with
all
see
if
it
has
the
desired
effect.
A
C
Other,
it's
very
very
data
intensive
like
how
do
you
choose
what
subset
of
users?
How
do
you
interpret
the
results?
So
it's
not
all
only
you
know,
add
feature
see
if
this
feature
gets
used
more
or
less
often
or
change.
Other
features
used,
sometimes
just
a
textual
change
or
like
even
a
color
change
on
a
page.
Sometimes
this
okay,
we
change
this.
Maybe
it's
just
a
simple
change.
We
changed
the
text
here
on
this
page,
but
then
we
want
to
know
is
within
30
days.
Do
they
use
this
other
feature?
C
And
in
this
way,
okay,
you
have
to
look
at
many
different
steps
in
the
data
and
we
get
so
much
data
on
that
on
usage.
You
know
it
can
be
really
complex
to
kind
of
track
that
through
the
user
process,
so
that's
one
part.
This
is
very
different
than
normal
engineering,
not
different
bad,
just
different.
The
other
is
that
we're
very
data
intensive,
as
I
mentioned,
and
we
try
to
stay
away
from
doing
development.
C
That's
not
an
experiment
like
for
other
teams,
although
we
do
it
occasionally,
because
it's
really
easy
to
just
turn
into
a
regular
development
team
and
not
do
experiments.
So
we
we
do
that
occasionally,
like
the
growth
team
built
the
what's
new
feature
in
gitlab
in
the
top
right,
you
can
see
you
know.
What's
what
the
new
features
are.
Yeah.
B
C
Built
that
it
wasn't
really
an
experiment,
because
we
were
sure
we
wanted
it,
because
we
want
to
really
stay
focused
on
experiments
right,
we're
really
good.
Also
at
knowing
various
parts
of
the
product
you
know
at
gitlab.
You
know
everyone,
everyone
can
contribute.
It
doesn't
mean
it's
easy
to
contribute
in
every
single
area.
So.
C
Gets
really
good
at
working
in
various
different
areas,
based
on
where
the
experiments
are,
which
is
great,
because
it
makes
us
very
effective,
we're
also
the
first
candidates
for
hey
we've
got
this
big
thing
that
needs
many
different
people
from
different
groups,
but
often
it's
the
first
team.
Other
product
managers
want
to
pull
from
because
we
can
contribute
which
we
do
often,
but
we
need
to
keep
an
eye
on
that
to
make
sure.
B
Of
course,
that's
exciting,
so
one
of
the
things
that
you
brought
up
was
used
to
so
worked
in
security
for
a
long
time
came
to
gitlab
doing
security
left
for
a
bit
and
now
you're
back
with
security.
When
we're
talking
about
security,
you
mentioned
two
different
stages:
first
is
secure
where
you're
securing
the
code,
while
you're
working
with
it,
the
other
is
defend
and
to
me
that
seems
like
one
is
very
dev.
The
other
is
very
ops,
but
since
we're
devops,
obviously
there's
a
marriage
between
the
two.
B
C
C
The
development
teams
are
definitely
involved
in
the
secure
side.
It's
they
create
the
security
issues
in
the
code,
not
intentionally,
of
course,
hopefully
not
intentionally,
and
they
also
wants
to
resolve
them
on
the
protect
side.
Sometimes
it's
the
developers
who
can
resolve
the
issues.
Sometimes
it's
the
operations
team,
as
you
mentioned,
ops
and
security,
is
very
interested
in
both
sides.
So
it's
different
data
for
different
people
at
different
times.
C
C
Accidentally
doesn't
validate
input
data
and
then
it's
vulnerable
to
cross-site
scripting
attack,
for
example.
Sometimes
it's
a
library,
that's
changed
that
the
developer
doesn't
change
anything,
but
a
new
vulnerability
has
found
a
new
library
like
log4j,
which
has
been
in
all
the
news
been
in
the
news
lately:
yeah
yeah.
So
it's
there's
that
that
element
of
chaos
that
comes
in
from
the
outside
then
and
the
developers
have
to
resolve
that
code.
C
Then
there's
the
challenges
when
code
is
deployed
where
it
could
be,
the
library
is
updated,
one
that
didn't
come
from
the
developers
through
the
dependency
chains.
It
could
be
just
in
the
operating
system
or
some
other
third-party
software,
and
that's
where
the
container
scanning
comes
into
play
and
also
operating
system.
Configuration
and
container
configuration
is
really
key
with
scanning
the
containers
to
find
vulnerabilities
because
it
might
have
no
vulnerabilities
in
the
code
or
the
dependent
libraries.
B
B
A
B
C
So
it's
you
can't
stop
them
all.
You
can
truly
try.
That
is
a
great
laudable
goal.
It's
about
knowing
what
the
risks
are,
reviewing
the
risks
periodically
and
prioritizing
resolving
them,
based
on
both
the
risk
and
the
the
negative
outcome
of
that
risk.
So,
like
let's
say,
one
risk
is
a
dos
risk,
so
you
could
think
well
denial
of
service.
So
you
know
if
we
don't
resolve
this
thing
and
it
gets
exploited.
C
So
looking
at
things
like
having
really
good
logs
and
systems
so
that
you
can
and
then
looking
at
patterns
in
the
logs
for
detecting
watching
network
traffic
in
and
out,
because
often
the
bad
actors
need
to
exfiltrate
data
out
of
a
network.
So
looking
for
those
things
to
catch
the
exfiltration
outbound,
our
key
catching
changes
to
systems
that
were
expected
versus
unexpected
and
then,
lastly,
having
a
really
good,
you
know.
Lastly,.
A
C
Next
thing
comes
mine,
really
good
incident
response
plans.
Everybody
is
gonna,
have
a
security
issue
at
some
point,
so
doing
a
tabletop
exercise
like
if
this
kind
of
thing
happens.
Okay,
what
are
we
gonna
do
and
who's
gonna
do
it
and
how
we
know,
let's
actually
talk
through
what
we
do,
how
we
do
the
patching,
how
we
do
the
communications
to
our
customers
in
the
public?
I
talked
to
a
former
colleague
who's
now
at
a
another
company,
and
he
said
in
their
response
to
log4j.
C
C
B
There
were
times
where
we
were
doing
fire
drills
twice
a
month
and
no
fire
ever
came,
but
if
it
did,
we
were
ready,
and
so
we
need
to
make
sure
we're
treating
software
and
development.
All
of
this
the
same
way,
we
treat
what
we
would
consider
real
world
issues,
but
I
mean
as
much
as
software
is
involved
in
our
lives.
Now
it's
all
real
world
issues
really,
but
that
exercises
and
having
a
plan
and
like
you
said,
the
plan
might
fall
apart
as
soon
as
it
comes
up
against
the
actual
example.
B
But
you've
got
this
blueprint
that
you
can
use
and
you
you
usually
know
what
the
next
step
is.
Yeah,
that's
fantastic
man.
We
can,
we
can
start
wrap
it
up.
This
is
all
such
amazing
information,
your
your
team,
like
what
what's
going
on
in
your
team
now,
what's
the
new
new?
What's
the
news
what's
happening
with
with
people
under
you
as
director.
C
The
really
excited
about
a
number
of
features
I
mentioned
the
merge
request.
Recommender
reviewer
recommender
is
coming
soon.
You
know,
powered
by
machine
learning,
we're
recruiting
beta
customers
right
now
to
be
early
users
of
it,
so
we
get
feedback
on
it.
The
we
are
also
got
all
sorts
of
features
coming
on
the
on
the
growth
team,
all
sorts
of
different
experiments,
and
it's
really
exciting
we're
looking
at
how
to
so.
C
We
can
do
more
experiments
over
time
per
engineer
or
per
team
per
month
per
engineer
per
team
per
month,
so
we're
looking
at
ways
to
kind
of
take
the
common
things
out
and
refactor
them,
so
we're
not
rebuilding
them.
Each
time
like
selecting
it's
too
hard
today
to
select
which
users
are
going
to
be
in
which
experiments
when
we're
doing
10,
20
etc.
So
we're
looking
to
refactor
that
out
and
then
on
the
security
side.
C
We've
got
all
sorts
of
features
coming
on
scanning
code
and
scanning
infrastructure
better
and
more
efficiently
for
finding
issues
both
to
have
a
lower
false
positive
rate
of
where
we
say,
there's
an
issue
and
there
isn't
and
when
a
false
negative
rate.
When
we
miss
something
and
there's
something
there.
There's
a
couple
different
projects
that
the
vulnerability
research
team
has
been
working
on
a
while
that
we're
working
to
productionize
one
is
called
browser,
which
is
a
cool.
C
B
C
Wide
machine
learning
team
is
actually
right
now,
looking
for
the
same
to
integrate
the
applied
machine,
learning
features
and
anti-views
features
into
the
product,
and
also
looking
for
python
developers
who
have
a
machine
learning
background
a
little
bit
unique
for
gitlab.
We
don't
have
that
many
of
those
yet
but
python's
the
primary
language
for
machine
learning
and
then
the
security
side
is
primarily
backend
engineers
and
ruby
and
rails,
who
also
have
may
not
know
security.
B
Available
ruby
on
rails
front,
end
back
end
python,
machine
learning,
tons
of
stuff
available
out
there
wayne
any
any
last
word
last
thoughts:
advice
for
the
people,
whether
it's
people
who
are
looking
to
apply
or
people
who
are
currently
working
or
people
in
security.
Anything
you
want
to
leave
the
people
with
before
we
head
out
of
here.
C
C
What
many
companies
do
and
that's
fine
we
do,
is
we
give
you
some
example
code
and
say
enhance
it
in
this
way,
find
the
problems
with
it
and
fix
them,
submit
those
changes
to
us
and
the
interview
is
actually
discussing
them
not
doing
the
change
live,
and
so
it's
always
worth
practicing
those
things
so
you're
not
nervous
and
see
if
your
skills
are
where
you
feel
they
should
be.
The
other
is
read
the
handbook
yeah
before
you
interview
for
the
team
for
the
department
etc.
C
You
can
get
so
much
information
about
how
we
interview
what
things
we
look
for,
so
you
can
not
game
the
system
but
think
about
things
in
advance
on
the
kinds
of
questions
we
might
ask
so
that
you
can
know
what's
going
on
and
know
what
kinds
of
things
we
look
for,
so
you
can
come
up
with
examples.
Those
are
the
things
I'd
consider.
B
Absolutely
and
like
the
handbook
is
a
treasure
trove
of
information,
even
if
you're
not
interviewing
with
git
lab-
and
you
want
to
see
how
git
lab
does
something.
So
you
can
bring
it
to
your
own
team.
The
handbook
is
available
all
right.
It
is
available
for
everyone,
we
believe
in
transparency,
and
we
want
what
we
do
to
be
available
for
all
of
y'all,
listen
wayne.
This
has
been
such
a
great
show.
You
have
been
such
an
amazing
guest.
Thank
you
so
much
for
coming
on
and
we
will
see
you
around.
B
I'm
just
excited
to
get
to
know
you
more
and
just
as
a
team
member.
So
everyone
thank
you
for
coming.
Thank
you
for
watching.
This
will
be
available
on
the
unfiltered
gitlab
channel
after
this.
So
if
you're
watching
that
now
check
out
the
links
below
we
got
great
stuff
there
and
we'll
see
y'all
later.