Jackie’s PM Interview Tips

The first time I applied to Google, I was rejected after the second phone interview.

Interview processes aren’t perfect, and companies are usually more willing to pass on a candidate who might be good rather than accidentally hire someone who isn’t. To get the best chance at being hired you need to not only be good at product management, you also have to be good at interviewing. You need to both have good ideas and present them in a way that makes it easy for the interviewer to realize they’re good.

Interviewers have a rubric in mind for the kind of answers they’re looking for, but people without pm experience rarely give responses that fit that mold.

I wrote Cracking the PM Interview to even the playing field a little bit — to teach people the rubric so that they can present their ideas in a way that’s easy for the interviewers to follow and appreciate.

The book is great, and you should definitely buy it. Check out how many people say the book helped them land a job. It goes into way more detail on what the PM job is, what it’s like at different companies, how to advance in your career, and how to answer questions with lots of examples than this article will.

But if you want a quick overview, this article is for you! It’s a consolidated repost of the tips I published in 2013.

The Résumé

Your resume is the first example of your work that a company sees, and so it should reflect well on you. It should show off your ability to understand the audience, communicate well, and pay attention to details.

Here are some common problems I’ve seen:

  • Misspellings — It takes an almost perverse carelessness to let spelling errors into a resume. This is one of the most basic cases of attention to detail.
  • Resumes that are more than one page, especially ones that go over by just a few lines. This is an example of poor prioritization. PMs need to be able to make hard cuts all the time, and I’ve never seen a 1.2-page resume that didn’t have obvious things to cut.
  • Resumes in Microsoft Word format (for a startup). Most people at startups don’t have Word installed, so those .docx files make candidates look out-of-touch. Use a PDF.

On the other hand, here are some things that make an applicant stand out:

  • A cover letter that shows a passion for our space
  • Experience launching products
  • A background in computer science
  • Bullet points that are easy to read
  • Well articulated description of the company or product if it’s less well known
  • Highlighting of key achievements (patents, well known awards)

If you don’t have much experience, one thing you can try is to build a web app or mobile app as a side project. It will give you experience in launching products and demonstrate your technical skill. A side project also shows off your motivation and ability to get things done, as well as providing anecdotes you can use during your interview.

Check out Marc Baselga’s post for some more details on resumes & cover letters.

Preparation

If you’ve gotten an interview at a company you like, you might wonder what you can do to increase your chances of getting hired. One way is by researching the appropriate areas.

I’ll admit that when I’m interviewing I usually go a bit overboard with research. Depending on the company, they might expect you to do more research, especially if they have a lot of information on their website or a product you can easily try. Doing the research shows the company that you’re interested in them.

Another reason to do the research: the people interviewing you won’t always be aware of what’s common knowledge and what isn’t. They’ll get so familiar with their area, they’ll forget which pieces other people don’t know.

I ran into this problem in my Google interview: I was asked questions about Adwords prices, but I hadn’t realized that the advertiser only paid when someone clicks on an ad. If I’d done my research and learned about click through rates and conversion rates the questions would have been a lot easier.

Here are some of the areas you might want to look into:

1. The Company
Companies, much like people, have a self image. Some companies are proud of their risk-taking culture. Others really emphasize their focus on design.

If you read what the company says about itself, you can get a sense of the company values, target customers, and what they think makes them special. You can start to learn if they’re a good fit for you, and tailor what you tell them about yourself. For example, when I applied to Asana I knew that the company valued mindfulness, and so I made sure to mention that I’d taken a meditation course in college.

If the company website or blog mentions a book or philosophy, you might want to brush up on it, so that you can understand assumptions the company might make. Conversations will go faster and more smoothly if you have more shared understanding.

2. The Customer
One of the most important skills in product management is being user-focused. This means understanding the customer and making decisions with the customer in mind.

If you’re not the company’s target customer, do some research to learn more about the target user. Look at blogs, articles, and websites to try to understand their needs and use cases. Also, you want to be sure that you understand how you’re different than the customer — in many cases the customer is less tech savvy, or less willing to spend time customizing product that you would be.

3. The Product
Some companies love to ask candidates questions about their products, while some try to steer away from them. When you look through your product, there’s a few different approaches you can take. One approach is to look from the customer’s point of view, another is to think about the broader vision, and another is to look for improvements.

4. The Competitors
In addition to the company and product, you can also research the competitive landscape. As you find differences, try to figure out why each side made the choices they did. In the places where you don’t know why they made the choices they did, you can write it down as a question to ask at the interview.

5. Modern Products
Finally, spend some time brushing up on products in general — find some product you love, some you hate, some you think are well designed, some that are marketed well. Choose a variety of products — from different companies, for different platforms, with different audiences, from niche to general purpose.

Think about how you would take each product and make it grand and important. What features would you add? What vision would you have for it? How would you measure success for the product?

The Product Question

A key part of any PM interview is the product question. This is a question that’s designed to test your product sense — how good you are at thinking of, prioritizing, and designing features.

There are a lot of varieties of product questions, but they’re pretty easy to spot — “What’s your favorite website and what features would you add to it”, “Design a calendar app for a fisherman”, “How would you make a better toaster”.

The thing that might not be obvious is that there’s a right way to answer these questions, and it probably goes against your first instinct. You don’t want to just start spitting out ideas — you need to take a structured approach to the problem, and you need to start with the customer.

This doesn’t mean focus groups or asking the customer what they want. Instead it means to think about what kind of person will be using the product, and why? What are the use cases? For example, for the toaster you might think about people who are in a rush and care primarily about speed, people who are foodies and want quality, and people in commercial businesses who want quantity and consistency.

Stating these cases explicitly explains the assumptions behind your features and helps make sure you’ve considered all the aspects of a product. It also helps avoid one of the biggest mistakes people make — designing the product just for themselves. When you start to talk about features, you’ll want to tie them back to the use cases. You want to pick important features and explain why they’re important — how they will change the customer’s lives.

Here’s a framework I use to answer these questions

  1. Who are the customers?
  2. What are their use cases? / Why are they using this product?
  3. How well is the product doing for their use cases? Are there obvious weak spots?
  4. What features would improve those weak spots?
  5. How could this product get more users?

One thing that differs from interviewer to interviewer is how much they want you to ask them questions vs. make reasonable assumptions. Some interviewers will hold back specifics about the target customer (oh, actually he’s a fisherman) until you ask.

So to be safe, check in with your interviewer, ie. “Is this for a specific customer?” or “Do we know what problems fishermen have with regular calendars?”. You can also phrase this as “Here are the questions I would try to answer before designing…” and see if they’ll jump in with answers.

However, be careful about being too pushy with questions if your interviewer isn’t playing along. Some interviewers (me included) will hold it against you if it seems like you can’t make any reasonable product choices without research.

Using a framework like this won’t guarantee you do well on product questions — you still need to do a good job of identifying the customers, understanding their motivations and the tradeoffs that would be best for them, figuring out what problems are worth solving, and come up with good solutions for them. But structuring your answer like this will help put you on the right path and help you interview like a more experienced PM.

The Quantitative Question

How many pizza parlors are in the US? How many ping pong balls would fit into a 747? How much do I dread questions like these?

While the Product Questions are designed to tell how good you are at making product decisions, the Quantitative Questions are designed to test your analytical abilities.

A lot of product management work is highly analytical, especially if you’re going to work on a team with a lot of access to data and A/B tests. For example you might want to look for places in your product where users aren’t achieving their goals. Or you might take data from an experiment and try to decide if your change was good or not.

The reason I dread questions like these is that they feel like they require a lot of specialized knowledge. I have a pretty bad memory for numbers, and always worry that I just don’t know some facts that would make the question easy.

Luckily, the interviewer isn’t trying to test which facts you know, so with some structure you can make it through these questions. In fact, one of the top things interviewers are looking for is ability to make progress on tough questions. Just trying to answer the question will be a good start.

Here are some tips for solving this kind of problem.

1. Say everything you’re thinking out loud and ask questions
This is generally good practice for any interview question. Once you’ve said something, pay attention to how the interviewer reacts. Many will encourage you when you’re on the right track, or steer you away from dead ends.

For quantitative questions, it’s especially useful to ask questions. The interviewer knows how to solve the problem, and will generally tell you the facts you need if you ask. Even better, they’ll sometimes give you approximate numbers that they know will make the math work out easier in the end.

When you’re asking questions, there is a balance. I think it’s fine to ask for the population of the US, since that sounds like something that regular people might just know. I wouldn’t ask for the volume of a 747, since that’s clearly part of what the question is asking you to solve. Definitely ask clarifying questions that will impact the answer, like whether you’re counting only places that specialize in pizza or every restaurant that serves pizza.

2. Catalog what you know or wish you knew
Start with a quick brainstorming of useful facts. Do you know how large a ping pong ball is? Do you know how many pizza parlors are in your home town? How tall a 747 is? Do you know how much money is spent on pizza annually?

Take a look at what you’ve written down and try to get a feeling for which facts you think you could figure out or estimate, and which are probably too hard to get.

3. Turn the question into an equation
Based on those facts, start to write an equation. For example, maybe you write:

# pizza parlors = $ spent on pizza / revenue per pizza parlor
or
# pizza parlors = # people eating pizza / capacity per pizza parlor
or
# pizza parlors = # pizza parlors in The Sims * Scaling factor between The Sims and the real world

This basically represents the approach you’re going to take for your estimate. As you might see, not every equation is equally good. Some equations don’t work because it’s too hard to estimate one of the variables. Others don’t work because they don’t accurately calculate the answer.

If you see that you’ve written down a bad equation, acknowledge it, point out what the problem is, and then move on to find a better equation. It’s natural to make mistakes at this point, but it’s important to recognize them.

4. Estimate, or find ways to estimate the variables in your equation
Once you have a general approach, you need to start filling in the blanks.

Maybe you heard on the radio how much Americans spend on pizza each year. Otherwise, maybe you can estimate how much you personally spend on pizza each year, how that relates to the average spending, and then multiply by the population.

5. Think about corner cases and adjustments
Take a pause at this point to see if there’s anything you might have missed. This part might be your biggest change to influence how the interviewer judges you.

Is there anything that might throw your equation off? Is pizza illegal in some towns? Are the ping pong balls going to collapse under the pressurization? Will the vegan movement scare pizza lovers away? These examples are a little silly, hopefully yours won’t be.

If you came up with anything good, adjust your equations.

6. Do the math
Now you’ve got an equation with lots of numbers, so it’s time to solve it. Generally, you want to give off the impression that you’re comfortable with math, so try to avoid self-deprecating comments or a terrified look on your face. Also, try to get the math right.

One trick is that you can adjust the numbers a bit to make the math easier to solve. If you think your original numbers were more accurate than the new numbers, you can later on adjust the final number up or down to account for the change.

7. Sanity Check
Great, you’ve got a number, but you’re not done yet! The final step is to sanity check your answer. This is basically saying “200 Billion, does that sound right?” and thinking about other facts you might know to see if it’s in the right order of magnitude.

If your answer is way off, that’s okay, and it’s great that you found it yourself. Now go back to your equation, estimates, and corner cases to see if you can figure out where you went so wrong. If you find a clear mistake you can fix it and redo the math, but usually it’s enough to point out where you went wrong, and then let the interviewer tell you if you should fix it, or if they’re ready to move on.

If your answer passes the sanity check, a great way to finish is by confidently presenting the answer to the interviewer. You’ve hopefully been speaking out loud and explaining your thinking the whole time, but if not, you can take a final, brief run through the steps to the final answer.

Talking Points

When I was first trained on talking to the press, I learned a surprising thing. When you talk to a journalist and they ask you a question, you don’t just answer it. Instead, you think about all of your pre-written talking points, pick the one that best fits, and then use it as an answer to the question.

Don’t be this evasive in a job interview (your interviewer will count it against you if you don’t actually answer their question), but there are some lessons that can be applied.

After your interviews, when everyone is sitting in a room discussing whether to hire you, what do you want them to be saying? What do you want them to remember? What parts of you should stand out?

You can influence what people remember about you by planning out your talking points in advance. Preparing a list of your best anecdotes and accomplishments will make it easier to answer questions like “Tell me about yourself” or “Describe a time that you and a coworker disagreed”. With some practice you can even learn to fit them into answers for other questions like “Where do you see yourself in five years”.

The core part of a talking point is usually an accomplishment you’re proud of or some other “wow” factor you can describe. Then you want to expand the idea and add details to make it clear what you actually did. Decisions can look obvious (and less impressive) in retrospect, so talk about the alternatives you considered. Did you learn anything surprising? Any lessons you can teach your interviewer?

In picking your talking points, you want to balance between how good the points are and how diverse they are. If you just have one story and tell it to each person, they’ll probably remember it, but you won’t make as positive of an impression as if they remembered a few great stories. On the other hand, if you tell too many stories, the best ones might not stick.

When you have an onsite interview, each interviewer will give you a weak or strong hire or no-hire. If you’re going to get the job, you generally need at least one person to give you a strong-hire. If you just do a decent job of answering the questions, you’re still at risk of getting a weak-hire when the interviewer is indecisive. To make it easy for the interviewers to give you a strong hire, make sure to share one of your talking points in each interview.

Good Luck! And of course check out Cracking the PM Interview for many more details on what the PM job is and how to answer interview questions.

Co-Author of Cracking the PM Interview, the best selling book on product management http://amzn.to/2dLr46H. Advisor at Asana. Previously @ Google & Microsoft.