TPM is a very unique role in that, for me
specifically, it's stretching me to pull
me out of my default, which is just
diving through the technical. It forces
me to come out of that and think higher
level, bigger picture, is this the best
thing long-term? As well as being able to
balance business and technical decisions.
That's the part that's really unique
about it. I come from a software
engineering background but over the
years I realized that I like to talk to
people more than sitting in my desk and
code. This is a good mix where
I can work with people, find out what the
problems are, and then work with the
SWEs and the engineering team to have them
implement it. So it's a dual language
process if you will. Those capabilities
often are portable to a variety of
different areas and different types of
projects. It's really a passkey
to be able to go anywhere in Google and
work on anything that interests you.
For a TPM position you'll typically talk to
somewhere between three and five people
when you visit. Frequently there will be
one person who is specifically assigned
to assess the T, the technical aspect of
TPM. Often that's software engineering but
at Google it could mean anything. Most of
the questions which they asked me are
things which are very relevant to my job today. Half of them were technical
design focus and the other half were
more on the program management side of
things. What they try to assess in the
interview is your ability to solve
problems, it's your ability to interact
with cross-functional teams. How do you
lead without managing people? Those types of things.
One thing in particular that's very
important is to make sure that you don't
answer a behavioral question about how
you did something in the past with a
hypothetical answer of I would do this
or that. It happens quite a lot but it's
really important to really draw in your
experience and show that you've been
able successfully to do the things that
you're being asked about. I try to
find things that I've done in three
categories: the most difficult things
I've done. Then the second thing I looked
at was what are my biggest successes,
what were my biggest accomplishments, things that I'm proud of.
And the last one was what were my
failures. So those are the three things I
really focused on.
I think one of the things that helped me
was to really think about the questions
and the problems that were presented to
me in the five why's of who what
when where and why and another thing was
just not being afraid to get on the
whiteboard and to write things out.
Even when you're not necessarily writing
numbers and code on the board, but just
trying to organize your thoughts and
bucketing ways to solve a given
problem. I did a lot of technical
preparation just going through and
reading up on my design and stuff like
that but then later I realized I really
got to practice my mock interviews. It's
literally your 45 minutes of sales pitch
and you have to get it right. All the
things that are important for
project managers or program managers
such as organization, communication,
ability to simplify something down to a
solvable puzzle, is it's very important
in the job and it's important in the
interview itself as well. I think the
thing that was least productive was just
the self-doubt but I just convinced
myself that I was very confident in what
I was bringing to the table and it
worked out well. You will never find out
what you're missing on until you apply
and you go through the process, so I just
thought I'd apply and see what happens
and I was really glad that I got this.
