How to Answer Technical Product Questions

Technical PM questions are technology and company-specific. The most common questions involve:

• Designing a system
• Explaining technology to a non-technical audience
• Explaining a technical decision

Here are a few general strategies for tackling each type.

How to answer system design questions

System design questions ask you to design the architecture behind a product.

These questions are rare in a PM loop. Your recruiter will let you know in advance if you’ll face one, but if you’re unsure, ask.

Resist the temptation to “become an engineer” for the sake of the interview. As a PM, we recommend keeping your discussion relevant to the product and the user experience. Don’t go into deep technical detail unless your interviewer asks you to.

For example, while building a system diagram, you might point out that a load balancer would be useful to manage traffic spikes and maintain a good user experience — but you likely won’t need to describe how the load balancer works. Instead, emphasize how software components can be combined to handle expected user behavior and mitigate risks to the user experience.

Let’s walk through a PM-centric approach to system design questions. Assume you’ve been asked:

“Design Instagram’s home feed.”

Step 1: Clarify and get context

First, ask questions to help you understand the product — specifically, what it does and how it serves users. Even if there’s no ambiguity in the question, it’s a good idea to summarize your understanding of the product back to your interviewer before moving on to the next step so they have a chance to correct any bad assumptions.

For our example, in designing Instagram’s home feed, you could ask:

“Does the home feed include Stories?”

“Should my design include functionality for users to upload photos as well as view them?”

Step 2: Identify requirements

Next, identify key requirements. Ask yourself “What functionality does this product need?” The requirements you identify will determine the system components needed.

It can be helpful to quickly walk through a user journey or break down important use cases. Core functionality includes everything that affects what users do and see. Then, translate those into requirements.

For example, a simple user journey for Instagram’s home feed would include:

• The user opens Instagram
• They see posts
• They have the option to scroll and interact with posts
• They can click a link to visit someone’s profile

Converting this simple journey into a set of key requirements:

• Requirement #1: A ranked list of posts is displayed, with metadata included.
• Requirement #2: Users have the ability to like and comment on photos.
• Requirement #3: The feed implements infinite scroll so users never run out of content.

Step 3: Identify system attributes

Next, identify system attributes.

Beyond core system requirements, consider how the system should work and feel from an empathetic, user-centric perspective.

Continuing our Instagram example:

"Users often open Instagram when they’re bored. Sometimes they only open the app for brief moments, so we want the feed to load quickly and feel relevant.”

System attributes will vary significantly depending on the product you’re asked to design. If you were asked to design a medical billing system, instead of speed, users would value correctness, consistency, and data security. If you have the technical knowledge, you could include attributes like scalability, but that’s not expected in a typical PM interview.

Step 4: Define a basic architecture

Once you’ve defined core requirements and key system attributes, it’s time to build a system diagram. Be sure to cover:

• All system components needed to meet the requirements you’ve outlined
• What each component does within the overall system
• How components communicate with each other

The systems you’ll be asked to design as a PM are typically simple. There are two common approaches:

• Approach 1: Start by outlining the components, then follow the flow of information.
• Approach 2: Define APIs first, and then outline components that would support them.

You can use any process you’re comfortable with, but, as always, be sure to explain each step to your interviewer.

For the example question “Design Instagram’s home Feed” recall the requirements you’ve set:

• Requirement #1: A ranked list of posts is displayed, with metadata included.
• Requirement #2: Users have the ability to like and comment on photos.
• Requirement #3: The feed implements infinite scroll so users never run out of content.

Given these requirements, your system diagram would look something like this:

1. The mobile client asks the server for the user’s feed.
2. The server asks its feed generation service (FGS) to generate a new feed.
3. The FGS begins generating post candidates by first getting a list of accounts followed by the user.
4. The FGS queries the post database for all new posts from followed accounts.
5. The FGS passes the set of new posts to a ranking service (RS).
6. The RS looks at a set of signals to rank the posts by relevance.
   • To rank, The RS will likely need access to information from both the post database and the user database (6a and 6b).
7. The RS passes the ranking back to the FGS.
8. The FGS passes the first batch of posts to the server.
9. The server pulls the actual images from object storage.
10. The server sends the whole feed back to the client.

These base components can handle likes and comments as well as implement infinite scroll - you’d simply need to keep track of the ranking and pull more post candidates after the user consumes a certain number of the original candidate posts.

Step 5: Discuss tradeoffs and propose system improvements

Close by considering any additions or changes you might make to enhance the system while acknowledging trade-offs and justifying your choices. Ask yourself:

• Is there anything in this system that might get in the way of satisfying the requirements I’ve defined?
• Are there any components in this system that are at odds with each other?
• Are there any edge cases to consider that would significantly degrade the user experience?

In closing the Instagram home feed example, recall that a key system attribute is that the feed loads quickly and feels relevant. Close by saying:

“Because load speed is critical, we could add a cache to improve the load speed. A tradeoff of that approach would be that the data surfaced to users could be stale. If users aren’t scrolling as fast as we expect, we could end up expending unnecessary resources precomputing feeds that may not be seen. The best approach would be to cache data from the last visit and replace it with fresh data as soon as it loads. This would be worth the effort because a fast load speed will be more important to users than the potential small decrease users might see in post relevance.”

How to communicate technical concepts

Technical communication questions ask you to explain a technical concept to a (typically) non-technical audience. This kind of communication is a core PM skill, as you’ll often explain your product’s technology to non-technical stakeholders such as members of the marketing team.

Interviewers are assessing your technical knowledge as well as your ability to anticipate and tailor your communication to different audiences.

Let’s work through an example. Assume you’ve been asked:

"Explain DNS resolution to a 12-year-old.”

Step 1: Clarify the question

Begin by clarifying any ambiguity in the question to ensure you and the interviewer are on the same page about the technology and audience.

If your interviewer doesn’t offer any further context around the intended audience, assume you’re speaking to an average member and list the assumptions you’re making.

For example, when clarifying what your interviewer means by a 12-year-old boy:

“I’m assuming I’m talking to an average 12-year-old boy. I assume that he has basic familiarity with computers, especially browsing the internet and perhaps playing games. I’ll also assume that although he sees computer technology in his life and is perhaps curious about it, he doesn’t have an innate understanding of it. He may be perplexed and even a little fearful of it.”

Step 2: Summarize key points about the technology

Instead of jumping straight into an explanation of the technology, list the main points you want to get across — especially those that relate specifically to your audience. Taking a few moments to summarize the core concepts you want to explain gives you a chance to showcase your knowledge and helps the interviewer understand where you’re trying to go.

Continuing our example question:

“The main points I want to get across include:

• How webpages are organized and distributed across the internet, i.e. that websites are hosted on servers. Each website has a human-friendly URL, like google.com, and a machine-friendly IP address. In order to navigate to different websites, a translation between the URL and the IP address must happen behind the scenes.
• What the Domain Name Service, or the DNS, is, and what it does in the process of browsing the web, i.e. that the DNS “translates” a website’s URL to the IP address of the server hosting the site, making it possible to navigate to that site.
• How DNS works, i.e. that the process of DNS resolution comprises a series of queries to different servers with the goal of eventually finding the URL-in-question’s IP address.”

Step 3: Describe what’s familiar to your audience

Next, explain any familiarity your audience would have with the key points you listed above. Note any particular aspects of the technology that would be most relevant to them.

For our example question:

“It’s reasonable to assume this 12-year-old uses the internet regularly and knows what a URL looks like.”

Step 4: Explain

Finally, explain the technology to your audience.

It’s helpful to find a metaphor the audience will be familiar with that maps well to the technological concepts. Consider everyday objects and systems that have analogous behaviors.

For example, returning to the example question, the metaphoric approach might look like this:

“Imagine you wanted to get a book from a huge library. You know the name of the book you want, but you don’t know where it is in the library. In other words, you don’t know it’s “address.” You don’t know how the library is organized — what would you do? You’d get help from someone who can find the book for you using its name only. A similar thing happens when you’re trying to visit a website. That website lives somewhere on the internet, which is like a really huge library. The URL of the website you want to visit (say google.com) is just a name, though, and in order to navigate to google.com, your computer needs to know that website’s address on the internet. Now, let’s talk about how to find that book…”

Another approach is to explain the technology directly, at a level that fits your audience’s understanding.

The direct approach would look like this:

“The internet is a big, global network of computers. When you type in the URL of a website, you’re actually loading it from a computer somewhere else in the world. But in order to load that website, you have to find that specific computer. Every computer on the internet has an internet-specific address, so if we can find the address of the computer with our website, we can navigate to it. To do that…”

How to explain technical decisions

Questions on past technical decisions ask you to discuss previous projects and the technical decisions you and your team made.

Interviewers will evaluate your understanding of the technical considerations and business implications, your contributions to the decision-making process, and your familiarity with the software development process.

In addition to walking through the situation and the core decision made, be sure to cover:

• The different options you explored before making a decision
• The trade-offs you considered
• Your justification for your decision
• Any key takeaways or lessons you took from the experience

Imagine you’ve been asked:

“Tell me about a previous project where your team had to choose between two technologies with trade-offs. Why did you choose what you did?”

The STAR framework is appropriate:

• Situation: Briefly explain the project for context
• Task: Explain the decision to be made, the technologies considered, and the trade-offs with each
• Action: Explain your team's choice and the reasons behind it
• Result: Share the outcome and lessons learned from the experience

Let’s say you decide to discuss a computer vision app project using machine learning. Your team had to choose between building a custom model or using an off-the-shelf model.

You’d want to explain the trade-offs in training velocity, model flexibility, and accuracy for each option against an initial feature set you’d come up with together.

Then, you could share that you and your team realized that the inaccuracy inherent in an off-the-shelf model would not hamper the initial feature set and that it would be faster to deploy. As a PM, you were leaning towards going with the off-the-shelf model initially, with the expectation that you’d build a custom model later.

Given the tradeoffs, you were able to convince your team to go with the off-the-shelf model. You’d want to share concrete details with your interviewer; in this case, the model worked as intended, and you were able to deploy in more locations, which made training your own custom model easier down the line.

Common pitfalls

Here are some common pitfalls when answering technical questions.

• Be a PM first; don’t try to be an engineer. Especially when answering system design questions, rely on your PM instincts to decide what system requirements and components are critical. What technical considerations impact users most? What will get in the way of a good user experience?
• State all assumptions you’re making about your audience. Given a question like “Explain how the internet works to a grandmother” a common mistake is to forget to explicitly state assumptions about what a grandmother might know about the internet. You likely have a mental model of a grandmother in your head, and if you dive into the explanation without making this model explicit to your interviewer, it’s easy to gloss over biases you have that could detract from the quality of your answer.
• Prepare a list of technical decisions you can speak to before your interview. System design and technical communication questions aren’t common in PM interviews, but questions about technical decisions are, so be sure to include a few when you build your story bank.