Product design interview. My experience
Tags: interview, productdesign, architecture, api
Published: 2022-09-10 16:10:41

---
title: Product design interview. My experience
published: true
description: How to answer on product design interview question. How to make right decision and choose correct approaches.
tags: interview, productdesign, architecture, API
# cover_image: https://direct_url_to_image.jpg
# Use a ratio of 100:42 for best results.
---

## Intro
I would like to share my experience passing 45 min product design interview(NOT system design interview) in tech company. Everything described below is my experience, it is NOT a benchmark answer and does not claim to be one.

## Task
You need to design an API to implement a news feed like on the following picture.
![Product design interview task](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d1wzenapuggkbydab6qn.png)



## Solution
### Task understanding
As usual, the task itself is very high level and unclear, and our first goal is to ask as many important questions as possible to understand the context of the task.
Let's ask the first portion of questions:
1. Are there restrictions on the use of API types?
	It allows us to get rid of the first decision, which API should we use: REST, Web socket, GraphQL, etc. Or at least shows the interviewer that we care about it.
2. How many users do we have, and what is the expected load?
	This is one of the main factors that influence all decisions during the interview, and it is better to understand this requirement right away to save time.
3. How many client types(iPhone, Android, PC, etc.) are expected? Will the design vary?
	If there is only one client type, or at least the design is the same for all clients, this will allow us to make only one version of the API, otherwise we will have to solve an additional problem.

There are definitely much more questions which we can to ask, but we should remember that time is limited, and we only need to get the most critical information to make decisions.

### First steps
Based on answers above, we decided to start designing the required API. Let's imagine that we have to use REST API. So we need at least one endpoint to get a list of recent posts:

###### Endpoint 
`GET /posts`
###### Request 
```
{
	"count": 2
}
```
###### Response
```
{
  "posts": [
    {
      "picture_url": "",
      "text": "",
      "comments_ammount": 42,
      "likes_amount": 146
    },   
    {
      "picture_url": "",
      "text": "",
      "comments_ammount": 22,
      "likes_amount": 246
    }
  ]
}
```

This endpoint allows us to render the exact layout we need, but it has multiple problems:
1. How are we going to load next posts during scrolling? If we are going to make another request with `count: 2`, we can get the same posts.
2. How are we going to sort posts? What if returned posts will be the oldest ones, but we require the newest?
3. How can we get exact comments or list of people who liked the post?

This is not an exhaustive list of issues, but in my opinion they are the most critical, so let's try to fix them.

### Improvements
So how can we solve **issue #1**? 
I can see two ways here:
1. Simple but limited. Load the maximum amount of posts, let's say 1000, and allow users to scroll feed only to this amount.
2. Use pagination and get the posts in batches.

It's hard to even call it a trade-off, as the choice is obvious. The best option is to use pagination, it allows us to get posts portionally.

###### Request 
```
{
	"offset": 0,
	"limit": 2
}
```
###### Response
```
{
  "offset": 0,
  "limit": 2,
  "posts": [
    {
      "picture_url": "",
      "text": "",
      "comments_ammount": 42,
      "likes_amount": 146
    },   
    {
      "picture_url": "",
      "text": "",
      "comments_ammount": 22,
      "likes_amount": 246
    }
  ]
}
```

Now we can get posts batch by batch, which help us to avoid rendering the same post twice.

To solve the **problem #2** we need to add more fields to be able to sort our posts. We have at least 2 ways here:
1. More flexible. We can receive to fields: `how` to sort and `what` to sort. For example, sort in `ascending` order by `comments_ammount` field. It makes our solution flexible but increase complexity.
2. More simple. If we are talking about news feed, in the most cases users want to sort posts by date only. So we can just have only one field: `how` to sort. For example, sort in `ascending` order – get the oldest posts first.

I would choose more simple option here for now, anyway it can be improved later. 
###### Request 
```
{
	"offset": 0,
	"limit": 2,
	"sort": "ASCENDING"
}
```
###### Response
```
{
  "offset": 0,
  "limit": 2,
  "posts": [
    {
      "picture_url": "",
      "text": "",
      "comments_ammount": 42,
      "likes_amount": 146,
      "date": "2022-09-08T09:45:55Z"
    },   
    {
      "picture_url": "",
      "text": "",
      "comments_ammount": 22,
      "likes_amount": 246,
      "date": "2022-09-10T09:45:55Z"
    }
  ]
}
```

Let's move on to the problem #3 – how to see comments and likes? Again, we have multiple ways of solving:
1. Implement separate endpoint to get all comments/likes for post by `post_id`. This approach will have better performance for feed loading, as we will get fewer data. But it makes users wait when they want to see comments.
2. Include comments/likes in feed response. This approach is the opposite of the previous one. It will slow down feed loading, but it will speed up comments/likes viewing
3. Hybrid approach. Include top N comments/likes in feed response and implement separate endpoints to get full data. This one is the most complex, but the most optimal. 

The hybrid approach looks like the most appropriate here, and it doesn't require a lot of effort, so let's use it.
###### Endpoint 
`GET /posts`
###### Request 
```
{
	"offset": 0,
	"limit": 2,
	"sort": "ASCENDING"
}
```
###### Response
```
{
  "offset": 0,
  "limit": 2,
  "posts": [
    {
      "id": 12345,
      "picture_url": "",
      "text": "",
      "comments_ammount": 42,
      "likes_amount": 146,
      "date": "2022-09-08T09:45:55Z",
      "top_comments": [
        {
          "id": 1,
          "author_id": 2,
          "text": ""
        },
        {
          "id": 2,
          "author_id": 4,
          "text": ""
        }
      ],
      "top_likes": [
        {
          "id": 1,
          "author_id": 5
        },
        {
          "id": 2,
          "author_id": 8
        }
      ]
    },   
    {
      "id": 12346,
      "picture_url": "",
      "text": "",
      "comments_ammount": 22,
      "likes_amount": 246,
      "date": "2022-09-10T09:45:55Z",
      "top_comments": [
        {
          "id": 4,
          "author_id": 10,
          "text": ""
        },
        {
          "id": 5,
          "author_id": 11,
          "text": ""
        }
      ],
      "top_likes": [
        {
          "id": 6,
          "author_id": 12
        },
        {
          "id": 7,
          "author_id": 16
        }
      ]
    }
  ]
}
```

###### Endpoint 
`GET /posts/{id}/comments`
###### Request 
```
{
	"offset": 0,
	"limit": 4,
	"sort": "ASCENDING"
}
```
###### Response
```
{
  "offset": 0,
  "limit": 4,
  "comments": [
    {
      "id": 4,
      "author_id": 10,
      "text": ""
    },
    {
      "id": 5,
      "author_id": 11,
      "text": ""
    },
    {
      "id": 6,
      "author_id": 10,
      "text": ""
    },
    {
      "id": 7,
      "author_id": 11,
      "text": ""
    }
  ]
}
```
Endpoint for likes looks the same, so we omit it here.

### Time ended
It is likely that by this point the 45-minute interview will have come to an end, and it is worth finalizing the decision. We have certainly prepared a working API, but there are still a lot of problems, and it is worth going over them quickly.
1. What if new posts will be created during scrolling? It means that `offset` will be shifted and on the next request we will receive a duplicated post.
2. What about speed of pictures loading? Should we add multiple options of pictures URL: `preview` – small but low quality and `fullsize` – big with good quality?
3. How to deal with new posts loading? Should we use long pooling or publish/subscribe model?

### Conclusion
Note that there are several options for solving an issue (trade-offs), your job as a candidate is to show that you see them and try to justify your choice of the one best option. And don't worry if after the interview you understand, that you miss something. The goal of the interview is to see the way, you're thinking, not to prepare the real design of the product.