How to Nail Your Product Manager Interview in the IT Sector

Let's imagine a company invited you to an interview, and although you were clearly hoping for an invitation, now you are stressed. Below we will look at the mistakes people make during the interviews.

Throughout my hiring experience, I have been on both sides of the process, but more often, as a hiring manager and mentor. Therefore, I have accumulated enough knowledge to share.

Disclaimer: we will not discuss specific hard skills. There are lots of skill maps for product managers available. I have also written an article on resume writing tips. The text below is a logical continuation. The first part of the text is essential, but if you are in a hurry, you can skip directly to the case breakdown.

Interview with a recruiter/HR

I don't want to offend anyone, but it is a relatively easy interview so we won't dwell on it too much. Usually, it lasts 15-30 minutes, and the main goal is to verify your overall adequacy, the correspondence of your resume to reality, salary and other questions.

How to prepare: study the company, its mission and products, and salary ranges (for example, on Glassdoor). Come up with questions and write them down to ask at the appropriate time.

Mistakes: ask no questions, know nothing about the company, be silent and try to discount the significance of your achievements during a self-presentation.

Obvious tips: be yourself, open, confident, and maintain a dialogue. You can write a pitch in advance. Don't read it, but it will help you sound more confident. During the meeting you can try to find out the name of the next interviewer to prepare better: watch presentations, articles, or social media profiles in advance. And at the beginning of the following interview, compliment the interviewer on the materials you read/watched. It will help establish a connection.

All further interviews

These interviews often include an evaluation of behavioural skills and thinking patterns. They will also evaluate your skills: product, project, analytical, and sometimes technical. They usually start with very open-ended questions, gradually testing deep knowledge.

It is the part that many people cannot pass, and the reasons can be different, but we will try to increase the chances and make the market even more competitive =)

If you are good at solving cases described in a couple of sentences, you will most likely be able to answer specific questions like "We conducted an A/B test. The conversion rate for the first option was 1% and for the second one – 1.2%. Which one is better?" Therefore, we will not dwell on such questions in detail because the variations can be endless.

(Answer option: it is worth looking at the sample size, experiment duration, calculating statistical significance, or explaining how to do it).

Instead, we will analyze a specific open case.

Example case: Build a profitable video-streaming product.

Several of my acquaintances received such a task at an interview:

The company's founder wants to launch a new product - video streaming and make it profitable within 2 years. You are responsible for it. What will you do?

The company already has an audio streaming product with 1 million active monthly users (MAU) who purchase the subscription.

During an interview, you are in a stressful situation where you should compose yourself and deliver the best possible result within the given time frame. You are not expected to provide the one correct answer, as there may not be one or may several. The interviewer is interested in understanding how you came to your conclusion, which requires structured thinking and communication, and that's what we will focus on.

It's best to start by introducing the existing product if it's part of the case. Presenting and formulating derivatives can help create a foundation to solve the problem. For example:

• The existing business is almost the same as the case: essentially, we are reselling content from rights holders to end consumers.
• OK, this means we already know how to stream something lighter than audio content, so some of the necessary technology and product is already in place.
• We know how to work with subscriptions, which could be handy for video, so we don't need to create a new billing system for the MVP. The subscription model in this example is also subject to doubt. It's the simplest thing we can try, but for some audiences streaming the content with an ad model might be worth considering.
• We can research a loyal audience.

Other elements of this case include:

• Hidden desire not to start from scratch;
• Lack of research and strategy. It's unclear how the business owner believed that this was the way to go;
• Willingness to understand how you will build a profitable business, so you must include an economic component in your response.

Next, the task involves building a feature/product. Many people stumble here because they veer from the case into bookish musings. For instance, they provide vague answers like: "We will research to build the product, get results, evaluate development, and achieve success." Or on the contrary, they assume that the initial information is clear and immediately start considering what content they will provide without explaining how they came to that conclusion, except through their imagination and worldview.

Let's look at the main mistakes when interviewing for a product manager. And we will understand how to avoid them.

1. Responding with standard reasoning and phrases, forgetting the actual case.

   Always remember the case and the task you need to solve: in this case, to create a profitable video-streaming product. We already covered this mistake earlier.

2. Being passive and waiting for the interviewer to help you.

   The interviewer might intentionally provoke you by giving unclear facts, such as "We have 4 developers and 3 tasks, one of which has been estimated at 8 person-months. What will you do?" Or "We have already conducted research: our potential audience is people over 40 who want to relax." These seem like random facts from the interviewer's head.

3. Trusting random questions and facts.

   In the example above the numbers could be anything, but that doesn't change anything fundamentally. To answer the question and build a Gantt chart, you need to understand if the developers can be interchangeable and what are the estimations of the other two tasks. As for the audience example, it's worth questioning it, as nothing is said about the content providers that we can offer to satisfy this demand, or why it's 40 years old and not 16+, who have endless time to watch everything and anything and can pay for subscriptions with their parents' money.

4. Being a proxy manager.

   The manager's job is to control, not to be managed. What does it mean to evaluate a task in 8 months? And what will be the intermediate results? It's better to decompose the task into subtasks, for example, up to 3 days, and to set milestones for when even intermediate results should be demonstrated.

   
   

   If you build a product based on these assumptions, you will not be able to manage risks: the timeline will increase from 8 months to a couple of years, and in the end, you will not even get the product you wanted.

   
   

   The manager's goal, in this case, is to make an MVP of the product with minimum cost, preferably in a couple of weeks, and test the value of the hypotheses.

5. Incomplete picture or jumping thoughts.

   If you do not have a complete picture of the product, it would be difficult to solve the case. Completeness is achieved by filling in unknown parts. The example above is worth finding out how the other two tasks were evaluated. Otherwise, it is impossible to continue working on the case.

   
   

   Sometimes thoughts can jump around because there are too many ideas. But the product manager must be able to prioritize and do it here too.

6. Lack of added value.

   This mistake is a scourge for many people. When launching a new product in a competitive environment, you must understand why the user will want to pay you and not your competitors. The "tax" on switching from other products should be minimal. Partly for this reason, all services usually make similar products. Secondly, you must have something for which users will switch, such as unique content or an excellent movie recommendation system.

   
   

7. Not trying to analyze competitors and the existing audience of the service.

   Everything is clear from the mistake itself. It is worth extracting the benefit from existing loyal users, including finding the non-obvious things about competitors' services.

   
   

8. Identifying only a part of the users.

   In our case, as mentioned above, we resell content. That means we have users from two sides: content providers and consumers. The product should deliver content on the last mile, just doing it better than competitors for a certain audience. For example, "ivi" launches movies on any TV model. I think this was their golden vein for a long time during penetration into the audience with the emergence of TVs with Android, and competition in this area intensified.

   
   

9. Not telling about what will be around the product.

   Marketing is crucial at launch, so make it a part of the product. How will you eventually bring users to the product? Will customer support be needed?

   
   

10. Don’t mention monetization.

    It's worth mentioning that you will be looking for a positive unit economics model, reducing the cost of customer acquisition. These could be goals for each stage of the product life cycle. For larger companies, it may be normal to start making money only in the maturity stage, while for smaller ones, the budget may simply run out. The more experienced the PM, the closer he is to economics, and the less it floats in the clouds of features or indicators that do not affect it.

    
    

11. Failing on questions about A/B tests.

    If you haven't done them yourself, don't worry. More than half of companies don't have the infrastructure for fair A/B tests. But firstly, you can talk about launches and the subsequent growth/decline of metrics, conclusions and actions. Secondly, you can read up on the theory and show that you understand what p-value, confidence interval, and statistical significance are, and how to calculate them.

    
    

12. Answering too quickly on metric questions.

    Imagine you were asked how to measure the success of a new search version. Or what are the 3 main non-technical metrics like CPO you would like to see on the dashboard every day if you are working on a taxi service? Think about what is critical in both cases. CTR of the first place in search is a good indicator, but there may be repeated searches behind it. And the number of taxi rides can increase due to launches in new cities, so you need to be able to count them correctly.

How to practice:

• Watch how others solve common cases. Before joining a company, I solved many job interview cases. They have answers and comments from other product managers, which is very valuable https://www.productmanagementexercises.com/interview-questions;
• You can go on interviews at companies where you don't want to work, but it's not a win-win strategy;
• Arrange interviews with colleagues or find a good mentor.

Like or comment — it's great feedback.

And follow me on LinkedIn and HackerNoon to get more valuable information.

My name is Lev Zabudko, and I'm a Senior Product Manager at Yandex, responsible for developing music and calling directions in the Alice speakers. I also believe that product managers are △-shaped specialists - the more experience they have from different areas, the more valuable the product is (you can argue about this in the comments).