My 45-min Product Design Interview Experience

Intro

I would like to share my experience passing 45 min product design interview(NOT a system design interview) in a 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 in the following picture.

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 that we can 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 the 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 the next posts during scrolling? If we are going to make another request, 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 a 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 the 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 proportionally.

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 helps us to avoid rendering the same post twice.

To solve 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 two fields: how to sort and what to sort. For example, sort in ascending order by comments_ammount field. It makes our solution flexible but increases complexity.
2. More simple. If we are talking about news feeds, in 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 a 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 problem #3 – how to see comments and likes. Again, we have multiple ways of solving this:

1. Implement a separate endpoint to get all comments/likes for posts by post_id. This approach will have better performance for feed loading, as we will get less data. But it makes users wait when they want to see comments.
2. Include comments/likes in the 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 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": ""
    }
  ]
}

The 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 the speed of pictures loading? Should we add multiple options for 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 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.

Also Published here