Product Management Interviews Part 1/3: Screener and Take Home Assignment

Niki Birkner
6 min readSep 1, 2021


I recently went through the PM interview process at a few companies, and since many of you have asked me to give pointers on how to prepare for Product Management interviews, I wanted to take some time to outline what I did to prep, explain what resources I used, and reflect on where I thought I was successful/unsuccessful. This is the first installment of a four part series that I will post over the next month.

The structure of product management interviews

This varies from company to company, but it generally follows this pattern:

  1. A screener with your recruiter or somebody in HR
  2. A take home assignment
  3. A phone interview with a product manager
  4. An onsite, which includes interviews with an engineer, a designer, and a few product managers

Let’s dive into what each of these stages entail.

The screener

At this point, the recruiter and team have read your resume and like your profile. Next step is getting to know you through an informal call. This call can go in either of two ways:

  1. The recruiter takes up the majority of the time to tell you about the company, the role and the interview process
  2. The recruiter asks you get-to-know-you questions (tell me about yourself, why do you want to join this company, etc.)

Whatever way it goes, this is not meant to be a stressful conversation, it’s just a way for the recruiter and team to know you’re a real person and everything your resume says adds up.

Photo by Daria Nepriakhina on Unsplash

The take home assignment

You may or may not get a take home assignment, depending on where you’re interviewing, but it’s become increasingly common primarily because it is an “additional” filter before product managers at the company spend time interviewing candidates. The take home assignment allows the recruiter and team to see how you generally think about vague product-related problems. Some examples of past take homes assignments I’ve done:

  1. You’re the PM for an app, redesign a feature or propose a new feature to add
  2. What is your favorite product and why?
  3. How would you improve X feature from our product?

The good news is that the way you approach any one of these questions is very similar.

You need to clearly outline: 1. Assumptions, 2. Target Users & Needs, 3. What & Why, 4. Goals & Success Metrics, 5. Wireframes, 6. Tradeoffs and 7. Risks. Here’s some guidance on how to approach each of these sections:

1. Assumptions

For PM assignments, you will likely be given a vague problem and zero opportunities to ask questions. Because of this, it’s important that you outline every single assumption you make along the way.

2. Target Users & Needs

Who are all affected users? What are their pain points? Where are these pains felt? Who is your target user? What is their biggest pain point? I often use the User Stories or Jobs To Be Done frameworks to outline target users and needs.

  • User Stories Framework: As a <user role>, I want <goal>, so that <benefit>
  • Jobs To Be Done Framework: When <situation>, I want to <motivation>, so I can <expected outcome>
User Stories

3. What & Why

Describe succinctly what you’re building and why you’re building it. Include “Spec Notes” or a list of key pieces of functionality you would like to build. Bonus points if you can estimate how expensive it would be to build each piece (ballpark estimates — low, medium, high— are fine). Extra bonus points if you can prioritize the features based on customer impact.

Make sure your why is strong enough — many times PMs need to rely on their intuition but still justify their decisions to all cross-functional partners and stakeholders. The stronger your why is, the easier it is to justify your decisions.

4. Goals & Success Metrics

How are you measuring success? I would use Objectives and Key Results. Here’s an example of an OKR you could use in your take home assignment:

Objective: Launch major product initiative by end of quarter

  • Key Result: Recommendation score of 8 or above
  • Key Result: 40% of MAU use new feature
  • Key Result: Increase sign-up-to- conversion rate from 15% to 25%

As PMs, one of your responsibilities is drafting your team’s objectives and KRs and making sure they roll up nicely to the company-wide objectives and KRs. This should be good practice!

If you’re interested in learning more about OKRs, I highly recommend reading Measure What Matters by John Doerr. I am also thinking of posting a summary of the book in my blog at some point in the future, so keep an eye out for it.

5. Wireframes

I would include both paper and Sketch/Figma wireframes if possible. If you don’t know or don’t have access to Sketch or Figma, paper wireframes are just fine. The idea here is not to design a fully functional feature or product. In fact, these are supposed to be really low-fidelity (meaning, not that realistic). But mocks provide a good opportunity to show your thought process and product intuition.

A quick note— it’s important to highlight why you made certain decisions along the wireframes. For example, you might say: I chose to add this button here instead of there because, or I chose the user flow to be like this instead of that because…

6. Tradeoffs

Discuss all the alternatives you could have pursued and why you chose not to. I like to use matrices to describe tradeoffs, and while I was working on my take home assignments for PM interviews I heavily relied on this one.

I first physically sketched out where my brainstormed solutions would lie in the matrix above, and then I turned it into a table that looked like this:

7. Risks

Here are some of the risks I’ve thought through when doing these assignments (and when doing any real product work) —

Customer Risk:

  • Are there real customer pain points?
  • Will the user buy this (or choose to use it)?
  • Can the user figure out how to use this?

Solution Risk:

  • Can this feature help my customers to achieve what they want?
  • Does it add value to them?
  • Does this feature solve the pain point of people feeling bothered by how impersonal online invitations feel?

Competitor Risk:

  • Is my product superior to the alternatives that customers have at their disposal?
  • Is it adequately differentiated to compete favorably in the market?

Development Risk:

  • Can our engineers build this?

Some final higher-level tips on how to rock the take home assignment:

  • Be as concise as you can: Communication is an essential PM skill. As a PM you’ll be writing specs, justifications for decisions, decks — and it’s important that you learn how to communicate what you need in a crisp way.
  • Show your whole thought process: This may seem contradictory given the first tip, but hear me out. As a PM, you constantly need to show others (engineers, product marketing managers, customer success managers, sales representatives, data scientists, and the list goes on), how you’re thinking about a problem. You can’t just say “This is what we’re going to do”, you need to explain your reasoning and make sure everyone understands and is on board with your plan.
  • Don’t jump to solution mode too quickly: As a PM you can go into failure mode if you think about solutions first. Most of the times, when you think through target customers and pain points you come up with solutions you wouldn’t have otherwise. Working backwards (i.e., starting from the solution and then brainstorming target user and pain points) is not the best way to approach this either, as it can narrow down your solutions and you’re not going to think as creatively as you could.

That’s it for now!

Keep an eye out for parts 2, 3 and 4. I will be covering: the product, engineering and design interviews, resources to prep, and more tips.