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: 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. 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. 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: 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. How are we going to sort posts? What if returned posts will be the oldest ones, but we require the newest? 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 ?
I can see two ways here: issue #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. 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 we need to add more fields to be able to sort our posts. We have at least 2 ways here: problem #2 More flexible. We can receive two fields: to sort and to sort. For example, sort in order by field. It makes our solution flexible but increases complexity. how what ascending comments_ammount 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: to sort. For example, sort in order – get the oldest posts first. how ascending 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: Implement a separate endpoint to get all comments/likes for posts by . 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. post_id 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 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. What if new posts will be created during scrolling? It means that will be shifted and on the next request, we will receive a duplicated post. offset What about the speed of pictures loading? Should we add multiple options for pictures URL: – small but low-quality and – big with good quality? preview fullsize 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

Read My Stories

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

My 45-min Product Design Interview Experience

Too Long; Didn't Read

Vadim Beskrovnov

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

My 45-min Product Design Interview Experience

Too Long; Didn't Read

Vadim Beskrovnov

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES