Like a million other articles already out there, I want to spend some minutes to chat about interviewing in Google. I’ll focus on interviews for Product Manager positions. Why that? Turns out there are quite a few resources out there for wanna-be software engineers (SWE) interviews, but not that much about PMs. As a result, I tend to see a skewed representation of what the PM role and associated interview is about. Why me? Over my time in Google I have interviewed over a hundred candidates, for a variety of roles and PM ones have always been the most difficult to gauge (for me being a software engineer). The usual disclaimer applies: what follows are the opinions of mine and not necessarily those of my employer. Also, there are bazillions other people @google, so consider that my opinion is just one among the group and not necessarily the most representative one.
I won’t discuss software engineers interviews here. For this, go read Steve Yegge.
The interview
As you may find on the web, a PM interview is supposed to cover many aspects, from cultural fit, to product insight and strategy, to technical questions, and you will be interviewed by other product managers, but also by engineers. We come into play when it comes to probing the wanna-be PM (that is you) technical expertise. Technical is a bit vague here, I’ll go into more detail later, but it may range from high level system design all the way down to coding. And this is the interesting bit.
The technical interview is tricky for both sides. For the candidate, it has usually been a long time since they touched a keyboard for some programming (if they ever did) and, coming from a PM background, candidates tend to approach technical questions with a mixture of fear (handwaving is not gonna work with engineers) and, well, fear (they know the engineer is gonna torture them asking for the algorithmic details of stuff the studied at uni 10 years ago).
For the interviewer (that is me), it is equally tricky because there is no hard and fast rule to judge a product manager performance. Mind you, there is no hard rule even for engineering positions, but either you know how hash tables work or you don’t. Judging a PM is always a fuzzier process, because the role itself is fuzzier by definition (hint: the job name contains the word ‘manager’ in it).
But for sure, the most common fear all candidates share is having to code and churn out algorithms in the technical interview. That is also, incidentally, among the last of the problems you should worry about. That is also, incidentally, the most common pitfall we engineers tend to fall into (asking coding questions is such an easy way out…).
This is a broad overgeneralization though. There are a lot of projects in Google, from the deepest technical guts of our backend infrastructure, to consumer products (the search, maps and mail you all know), to internal tools for the sales force, each further subdivided in a myriad of smaller parts. The following thoughts apply to the areas I’m familiar with: sales tools and consumer products, mostly focusing on the ones related to advertisting (AdSense, AdWords, etc…). In general, the deeper in the Google stack the project is buried or the more developer-oriented it is - e.g. our API and cloud platform products -, the more technical and CS-oriented the task of managing it becomes.
So what should you care about?
What do engineers look for in PMs
From my engineering point of view, the main characteristic of a PM is to be a good liaison officer for the team. Being a PM is mostly about coordination and syncing: across different internal teams, to figure out why team X cannot use our service Y and what exit paths out of it might exist. And toward customers, because either you spend time coding out beautiful products or you spend time collecting feedback and requirements from users. While developers do occasionally participate in product studies, and while engineers-sitting-with-users is a desirable thing to have, it often does not scale to Google reach. So I trust you PM to aggregate, study, distill and understand the needs of the hundreds of millions of GMail users out there (or AdSense publishers, in my case) and explain them to me.
The more effective you are in making clear what the problem to solve is, the better we’ll be at solving it together (this is not the only way problem solving occurs at Google, often also happening from the bottom up with PMs tasked to shape a useful engineering feat into a viable product, but the point doesn’t change). Mind that this is different from PMs dictating specs for engineers to blindly implement — this is not a path you want to venture into, because it’s full of issues, and a plain wrong attitude to product design.
And for these reasons, I couldn’t care less if you can code Fibonacci in closed form or not.
Of all the PMs I worked with, their ability in writing real code has never been a key aspect I expected from them, nor it determined how good they were at their job.
That said, we are still an IT company, so here are the things that I expect you to be really good at, if you want to make it through the interview. As you’ll see these aspects aim at verifying your liaison skills.
Understand an engineering design doc: Design Docs explain the architecture of a system in broad and general terms. You should be familiar with the terminology, be able to read it and explain it back. Design docs rarely venture deep into code (more frequently on algorithms) but cover the whole gamut of topics you’ll find in any IT project: scalability, reliability, system architecture, persistence schemes and whatnot. Understanding a design doc means you’ll understand what the engineering team works on, what the project can do and what features you can’t have on top of it. Start by having a look at our publications, such as the famous Google Filesystem or Megastore. During the interview, I might offer you a flawed architecture design and ask you to point out all the issues you can find in it, as a way of gauging your understanding of engineering matters.
Describe a moderately complex system design: it’s not enough to draft the product requirements for your system. You should have an idea about how those requirements can be turned into a working system in broad terms. For example, given the requirement of tracking visitor page views on a website, you should be able to design how a system like Google Analytics works. The more details the better: how page views are collected from the browser, stored and aggregated server-side. Throughput and sizing estimation. Reliability and scalability considerations and what limitations those impose onto the system (is it ok to lose some pageviews? is eventual consistency on replicated data good enough for a pageview collection system? What does it take to offer realtime stats? what stats can I collect from a browser if javascript is disabled?)
Be open and communicative: if you don’t know something, I want you to say it. It’s ok. You don’t have to know everything. Delegate to the engineering team when needed. Keep them in the loop, outline roadmaps early and often. The last thing I want to happen once you’re hired is you overpromising product features because you have no clue about how they translate in engineering work, resulting in unnecessary crunch times to squeeze them through anyway. On the other side, expect push backs from engineering. If it can’t be done, it can’t be done, and sometime engineers have good product insight too (the same openness should apply to customer-facing relations). This is tricky to test for in an interview, but I may probe your past experience, especially for signs of troubled relationships with development teams. It also shows when you feel cornered on a question you don’t know how to answer, and you start escalating on buzzwords to cover it up. I’m sorry but you are not fooling anybody. And, for the record, the cloud does not exist. It’s a messy bunch of servers, storage, network protocols, quirky browsers, master-election protocols, latencies on the wire and whatnot. So “I’ll store it in the cloud” is not an answer. Equally well, you can’t “put it in Oracle an it’ll deal automatically with replication”. Details, please.
Be able to keep it simple: and by simple, I mean much simpler than what you’re thinking right now. You should be able to distill a product definition into the most basic set of requirements and features. We are all time-constrained and we will never be able to do everything. For this reason I may end up asking you to do some object oriented design (or even venture into UX design). I marginally care about whether you remember what ‘class’, ‘instance’ or ‘composite pattern’ means (although it’s good if you do), but I do care about whether you can trim down a set of requirements to the simplest form that will address them efficiently — in an applied context. Reasoning in object-oriented form, rather than in abstract, imposes a defined context that will force you to navigate tradeoffs in your solution, while still keeping it simple.
So, yes, your technical interview might touch system design, architecture, object oriented design and (depending on the interviewer) possibly even coding. They are all proxies for the aspects I described. See you in the interview room.
Update: it’s worth pointing out that I focused on the technical interview only. I have not discussed all sort of other skills that you should have: soft skills, product insight, market awareness, the whole thing about “getting” the user and not being an over-rational engineer like I am.
—
Image credits for this article to Manu Cornet. Image taken from Bonkersworld.net. If you don’t know him, you have been missing a great comic.
