7,000+ smart, curious folks have subscribed to the growth catalyst newsletter so far. If you are new here, receive the newsletter weekly in your email by subscribing 👇

Subscribe now

It was a sunny day in 2018, and I had flown to Hyderabad for my Google PM interview. Google usually does screening rounds before inviting for onsite interviews. I had terrific feedback in screening rounds.

In the onsite interviews, Google tests various hats of PMs - analytical, product design, business, strategy, and tech. I had prepared well for all, or at least I thought I had :)

The first onsite interview happened to be the technical round. I come from a chemical engineering background and don’t have coding experience. At various times, I had tried to learn Javascript, HTML, Python, etc., rather unsuccessfully because there was never enough incentive to do so. In preparation for Google’s technical round, I had covered the data structure and algorithm basics plus the system design questions.

The interviewer gave me one algorithm problem and one system design. I solved the algorithm problem. In the system design question, I mumbled a few things for the next 5 mins — sharding, database, table structures, etc. The interview got over quicker than expected, and I knew that my chances of cracking Google were over.

There is a quote I read sometime back,

“Without the fire, the phoenix never rises from the ashes”

Google interview served as the fire for my technical aptitude. I completed Machine Learning Nanodegree from Udacity, a few books on system design and algorithms, etc in the next 2 years. All of that helped me get the role of leading the deep tech products(Voice Search and Assistant) at Flipkart.

All of these experiences culminated in the book I published early this year “Tech Simplified for PMs and Entrepreneurs”, which I wrote to make sure people coming from non-coding backgrounds don’t struggle as I did. So looking back, you can indeed connect the dots.

Based on my learnings so far, here is how you could crack the technical rounds in all companies that you interview for. Please note that I will use some excerpts from the book wherever it helps.

Technical Rounds are Messy

Technical rounds of PM interviews are messy because every company does it differently. Google is famous for its algorithm and system design questions. A lot of companies focus on whether you understand technical complexities or not. Some don’t even have a tech round. I did a survey on LinkedIn, and around ~50% of PMs said they don’t have a technical round in PM interviews.

Based on the survey, some of the prominent companies which have technical rounds are:

Flipkart
Google
Coinbase
CoinDCX
Bukuwarang
Cred
Razorpay
Delivery Hero

Some of the prominent companies which don’t have technical rounds are:

LinkedIn
Facebook
Bigbasket
Microsoft
Tata Digital
Meesho
Ola

Please note that the data shared above is representative. For example, for AI/ML PM roles, almost all companies will have some sort of check on tech understanding. The same could be true about levels. At senior levels, they may check for tech understanding which isn’t required for APMs.

But it’s really important to prepare and be ready for all sorts of questions for technical rounds because it’s not standardized. And I am here to help you :)

Range of Questions

Usually, there are four categories of questions in tech rounds:

Behavioral questions around tech
Explainers for technical concepts
System design of the current product you are managing
System design of a popular product

It might seem random when you first look at various categories, but they aren’t for most.

Behavioral questions check how well you can work with engineers.
Explainers check how well you can explain technical complexities to non-technical teams like marketing and business.
System design of the current product checks whether you go to the details of the product you manage or not. Are you aware of trade-offs that your team has taken?
General system design questions check how well versed are you with tech, in general. This is the highest level in my opinion.

Depending on the kind of PMs an org needs, it may consciously or subconsciously choose to ask one or more categories of questions. Now that you understand why these various categories are important, let’s look at the details of these.

Behavioral Questions

A few sample questions here would be

The CEO is expecting a key piece of development on Monday. It's Friday and the engineers in your team call you to say that they had an unexpected issue and will need an extra week to finish. How do you tell the CEO?

Describe technical challenges from past projects

The beauty of such questions is that they reveal a lot about the depth at which a PM has operated in the past. The ideal way to answer such questions is to use examples and analogies wherever possible.

For example, in response to the first question, you could tell the approach you would take and that could be an okay answer. But a really good answer would be if you can draw similar situations from your past experiences and how you handled them.

As a checklist, you should do the following to prepare well for these questions:

Prepare your past projects well. Write them in detail to be comfortable when speaking about them.
Examples from the past are best while making a point. This also prevents any loss in communication because you always share examples with enough context.
In absence of a direct analogy or example, draw an indirect one
Put an ‘End-user > Org > Team > Individual’ lens in your responses when there is a trade-off.

Explainers

A few sample questions here would be

Explain DNS to a 5-year old

Explain APIs to your grandmother

To answer these questions, you should know about the terms. My book covers almost everything a PM is supposed to know, so you could read that. The book is also written in a very simple language at an 8th-grade level, so it may help with explanation in simple terms as well.

But even if you have read the concepts, you should do a mock practice by actually explaining something to a kid or your mom. It helps you assess your gaps and fill them.

System Design of the Current Product

For freshers, this question isn’t relevant. It is relevant for existing PMs. First, let me explain what system design is. From the book —

System design is an important topic for PMs for multiple reasons. Before we go into reasons, let's talk briefly about what system design is.
A system is a set of things working together to achieve the objective of the system. Depending on the objective, the system can be designed in multiple ways. For example, we design the railway system to help people travel via trains from one place to another. The railway system designed for maximum revenue from stations A to B will differ from the one optimized for minimum journey time from stations A to B.
Apart from objectives, every system comes with its own set of constraints. The most common constraints are time, money, and quality. Whenever we design a system, we have to keep the objectives and constraints in mind.
For software system design, we define how different software and hardware components will work together to achieve the objectives. For example, the system design of Youtube ensures that billions of people can watch videos every day. System design is also known as system architecture.

If the interviewer asks about the system architecture of your current product, you have to explain how various pieces of software come together and make the magic happen. So how do you prepare for it?

The best way here is if you don’t have to prepare at all. One of the best habits that I keep recommending to PMs is to continuously understand the system design of the product they are managing and its tradeoffs. If you aren’t doing it, start on it.

If you are already in the interview process, talk to an engineer/EM and understand how the current product is built. Write it someplace so that you don’t forget (when it comes to system design, don’t rely on your memory), and understand it well.

A couple of things to keep in mind are:

Be comfortable with saying “I don’t know”, when you don’t know the answer to some detail interviewer asked. Don’t try to wing it.
Keep gauging the interviewers’ reactions. When asked to explain how your current product works, try to give a summary first. Wait for the reaction of the interviewer and follow-up questions. Never make it a monologue for 5-10 mins.

System Design of the Current Product

A few sample questions here would be

How do the content recommendations work for a streaming services platform like Netflix?

Design a photo-sharing app like Instagram

Before we go into how to answer these, it’s important to understand why it’s important for PMs so that you could keep these in mind while answering these questions. From the book,

But why should PMs care about system design? There are three reasons in particular:
Any system design will involve trade-offs since it has time, money, and resources constraints. A PM knowledgeable enough to have a conversation with engineers around these trade-offs can add value to the decision-making. This is the major reason why PMs should understand system design.
System design determines the user experience. For example, the time taken to load a page increases as the number of requests increases beyond a point. A PM who understands the relationship between system variables and UX can anticipate the problems and act proactively.
In the technical round of PM interviews, system design questions are common at top companies like Google, Facebook, Amazon, Microsoft, etc. Over time, even smaller companies have started including a similar tech round in their PM interviews.
When it comes to learning tech, system design brings everything you have learned together. It will help you see how everything works in sync.

And that’s why companies ask this question. You could go to any depth in system design. Here is a suggested 5-step approach for system design questions:

Define the scope of the product: No one expects us to design a product like WhatsApp or Instagram within 45 mins of an interview. So it's important to define the scope. In an interview setting, defining the scope shows your decision-making and prioritization skills. Here is what you can cover as the scope:
- Functional requirements — what features do you need?
- Non-Functional Requirements (NFRs) — measure the quality of UX like latency, page load time, successful OTP generation rate, etc.
- What’s not in scope — equally important to state things not in scope
High-level design as per functional requirements: Defining how the system works on a high level can be quite helpful. It helps in identifying key components of architecture and how they interact with each other.
Details of important components of high-level design
- Database choices
- APIs
Details of how we are going to meet NFRs
- Scalability
- Latency
- Availability and robustness through replication/redundancy
- Anything else that affects NFRs
Close by summarizing and asking the interviewer if there is anything else to cover

It is easy to build insecurity while working in tech if you don’t come from a CS/coding background. But once you start understanding the tech, it builds up your confidence to operate and make decisions magically. Invest your time early in your career in learning the nuts and bolts of tech, and you would be happy for it :)

This would be all for this post. If you are looking for more practice questions for the tech round, here is a list I prepared.

Thanks for reading this one, and all the best!

Deepak

The Growth Catalyst Newsletter

How to Crack the Technical Round of PM…