search

weeeBox / mobile-system-design

A simple framework for mobile system design interviews
Other
4.12k stars 429 forks source link

readme

A Simple Framework For Mobile System Design Interviews (work in progress)

Below is a simple framework for Mobile System Design interviews. As an example, we are going to use the "Design Twitter Feed" question. The proposed solution is far from being perfect but it is not the point of a system design interview round: no one expects you to build a robust system in just 30 min - the interviewer is mostly looking for specific "signals" from your thought process and communication. Everything you say or do should showcase your strengths and help the interviewer to evaluate you as a candidate.

Join the "Mobile System Design" Discord server for general discussions and feedback.

[discord](https://discord.gg/AWDNrvqban)

Disclaimer

The framework was heavily inspired by the similar "Scalable Backend Design" articles. Learning the framework does not guarantee passing the interview. The structure of the interview process depends on the personal style of the interviewer. The dialog is really important - make sure you understand what the interviewer is looking for. Make no assumptions and ask clarifying questions.

This guide does not reflect the interviewing policies from Google (or any other company).

Interview Process (45–60 min)

Acquaintances

Your interviewer tells you about themselves and you tell them about yourself. It's better to keep it simple and short. For example, "My name is Alex, I've been working on iOS/Android since 2010 - mostly on frameworks and libraries. For the past 2.5 years, I've been leading a team on an XYZ project: my responsibilities include system design, planning and technical mentoring." The only purpose of the introduction is to break the ice and provide a gist of your background. The more time you spend on this, the less time you will have for the actual interview.

Defining The Task

The interviewer defines the task. For example: "Design Twitter Feed". Your first step is to figure out the scope of the task:

Gathering Requirements

Task requirements can be split into functional, non-functional and out of scope. We'll define them in the scope of "Design Twitter Feed" task.

Functional requirements

Think about 3–5 features that would bring the biggest value to the business.

Non-functional requirements

Not immediately visible to a user but plays an important role for the product in general.

Out of scope

Features which will be excluded from the task but would still be important in a real project.

Providing the "signal"

System design questions are made ambiguous. The interviewer is more interested in seeing your thought process than the actual solution you produce:

Your best bet is to ask many questions and cover as much ground as possible. Make it clear that you're starting with the BFS approach and ask them which feature or component they want to dig in. Some interviewers would let you choose which topics you want to discuss :  pick something you know best.

Clarifying Questions

Here are some of the questions you might ask during the task clarification step

High-Level Diagram

Once your interviewer is satisfied with the clarification step and your choice for the system requirements  - you should ask if they want to see a high-level diagram. Below is a possible solution for the "Twitter Feed" question. High-level Diagram

Server-side components:

Providing the "signal"

The interviewer might be looking for the following signals:

Frequently Asked Questions

Why using a high-level diagram is necessary? Can I skip it altogether or draw a detailed diagram right away?

A high-level diagram is by no means necessary - you can take any other approach which seems more appropriate for a specific interview case. However, there are some advantages in starting with a high-level approach:

Still not sure? Ask your interviewer if they want you to draw a high-level diagram or skip it and jump to some concrete components.

Deep Dive: Tweet Feed Flow

After a high-level discussion, your interviewer might steer the conversation towards some specific component of the system. Let's assume it was "Tweet Feed Flow". Things you might want to talk about:

Details Diagram

Components

Providing the "signal"

The interviewer might be looking for the following signals:

Frequently Asked Questions

How much detail should I provide in the deep-dive section?"

There's no rule of thumb here. Work closely with the interviewer: ask them if you need to go deeper or move on to the next topic. If you have an in-person/video interview - watch their facial expressions. For example, if you see that the interviewer wants to interrupt you - stop talking and ask if they have any questions. The whole point is to work together - that provides a good signal for you as a team player/collaborator.

Why didn't you mention specific classes (like RecyclerView/UICollectionView) and vendors (like Room, CoreDate, Realm, etc)?

What drawing tool should I use?

At the time of this writing - Excalidraw, Google Jamboard, and Google Drawings could be the most popular choice. Some interviewers would skip diagramming altogether and prefer a collaborative editor and a verbal discussion. Due to privacy issues, some companies would not let the candidate share the screen and use a tool of personal choice.

API Design

The goal is to cover as much ground as possible - you won't have enough time to cover every API call - just ask the interviewer if they are particulary interested in a specific part, or choose something you know best (in case they don't have a strong preference).

Real-time notification

We need to provide real-time notifications support as a part of the design. Bellow are some of the approaches you can mention during the discussion:

The interviewer would expect you to pick a concrete approach most suitable for the design task at hand. One possible solution for the "Design Twitter Feed" question could be using a combination of SSE (a primary channel of receiving real-time updates on "likes") with Push Notifications (sent if the client does not have an active connection to the backend).

Protocols

REST

A text-based stateless protocol - most popular choice for CRUD (Create, Read, Update, and Delete) operations.

GraphQL

A query language for working with API - allows clients to request data from several resources using a single endpoint (instead of making multiple requests in traditional RESTful apps).

WebSocket

Full-duplex communication over a single TCP connection.

Learn more about WebSockets:

gRPC

Remote Procedure Call framework which runs on top of HTTP/2. Supports bi-directional streaming using a single physical connection.

The interviewer would expect you to pick a concrete approach most suitable for the design task at hand. Since the API layer for the "Design Twitter Feed" question is pretty simple and does not require much customization - we can select an approach based on REST.

Pagination

Endpoints that return a list of entities must support pagination. Without pagination, a single request could return a huge amount of results causing excessive network and memory usage.

Types of pagination

You need to select a single approach after listing the possible options and discussing their pros and cons. We'll pick Cursor Pagination in the scope of the "Design Twitter Feed" question. A sample API request might look like this: 

GET /v1/feed?after_id=p1234xzy&limit=20
Authorization: Bearer <token>
{
  "data": {
    "items": [
      {
        "id": "t123",
        "author_id": "a123",
        "title": "Title",
        "description": "Description",
        "likes": 12345,
        "comments": 10,
        "attachments": {
          "media": [
            {
              "image_url": "https://static.cdn.com/image1234.webp",
              "thumb_url": "https://static.cdn.com/thumb1234.webp"
            },
            ...
          ]
        },
        "created_at": "2021-05-25T17:59:59.000Z"
      },
      ...
    ]
  },
  "cursor": {
    "count": 20,
    "next_id": "p1235xzy",
    "prev_id": null
  }
}

Additional Information

Although we left it out of scope, it's still beneficial to mention HTTP authentication. You can include an Authorization header and discuss how to properly handle 401 Unauthorized response scenario. Also, don't forget to talk about Rate-Limiting strategies (429 Too Many Requests).
Make sure to keep it brief and simple (without unnecessary details): your primary goal during a system design interview is to provide "signal" and not to build a production ready solution.

Providing the "signal"

The interviewer might be looking for the following signals:

Data Storage

Data Storage Options

Bellow are the most common options for local device data storage:

Best Practices

Approach

You need to select a single approach after listing options and discussing their pros and cons. Don't worry about building a complete solution - just try to lay out a high-level idea without going too deep into details.
A possible breakdown for the "Design Twitter Feed" question might look like this:

Feed Pagination Table

Create a "feed" database table for storing paginated feed response:

item_id:        String
author_id:      String
title:          String
description:    String
likes:          Int
comments:       Int
attachments:    String # comma separated list
created_at:     Date   # also used for sorting
cursor_next_id: String # points to the next cursor page
cursor_prev_id: String # points to the prev cursor page

Attachments Storage

A possible follow-up question might require you to handle sensitive media data (private accounts, etc). In this case, you can selectively encrypt image files with encryption keys stored in Keystore/KeyChain.

Providing the "signal"

The interviewer might be looking for the following signals:

Additional topics

Major Concerns For Mobile Development

Here's a list of concerns to keep in mind while discussing your solution with the interviewer:

Privacy & Security

Cloud vs On-Device

At some point, during the interview, you might need to choose between running some functionality on a device and moving it to a cloud. The approach you select would have the biggest impact when it comes to On-Device AI but can also be extended to any kind of data processing as well.

Advantages of running things in a cloud:

Advantages of running things on a device:

Things you should never run on a device:

Offline and Opportunistic State

Adding an Offline State ensures the app's usability without a network connection:

Local Conflict Resolution
A local device pulls the remote state from the backend after going online, merges it with the local state, and upload changes.

pros:

cons:

Remote Conflict Resolution
A local device sends its local state to the backend after going online, receives a new state, and overwrites the local state.

pros:

cons:

More Information

Resumable-Uploads

Advantages of resumable uploads:

Disadvantages of resumable uploads:

Note: Resumable uploads are most effective with large uploads (videos, archives) on unstable networks. For smaller files (images, texts) and stable networks, a single-request upload should be sufficient.

More Info:

Prefetching

Prefetching improves app performance by hiding the data transfer latency over slow and unreliable networks. The biggest concern while designing your prefetching solution is the increase in battery and cellular data usage. TBD

More Info:

Frequently Asked Questions

How do you know this approach works? Why is this necessary?

Can you go a bit deeper at X?

This is not necessary since there might be lots of alternative solutions and the guide does not provide the ground truth. The implementation details should depend on the personal experience of the candidate and not on an opinionated approach of some random people from the Internet.

I'm an interviewer - this ruins the process for all of us: now the candidates just memorize the solutions to cheat during the interview.

Additional Information

More System Design exericses here!

Junior, Middle, Senior, and Staff level interviews

The system design experience would be different depending on the candidate's target level. An approximate engineering level breakdown can be found here.

NOTE: There's no clear mapping between years of experience and seniority - some ranges might exist but it largely depends on the candidate's background.

Junior engineers

The system design round of junior engineers is optional since it's pretty unlikely they would have experience designing software systems.

Middle level engineers

The middle-level engineering design round might be heavy on the implementation side. The interviewer and the candidate would mostly talk about building a specific component using platform libraries.

Senior level engineers

The senior-level engineering design round could be more high-level compared to the previous levels. The interviewer and the candidate would mostly talk about multiple components and how they communicate with each other. The implementation details could be less important unless the candidate needs to make a decision that drastically affects the application performance. The candidate should also be able to select a technical stack and describe its advantages and trade-offs.

Staff level engineers

The staff-level engineering design round moves away from technical to strategic decisions. The candidate might want to discuss the target audience, available computational and human resources, expected traffic, and deadlines. Instead of thinking in terms of implementation tasks - the candidate should put business needs first. For example, being able to explain how to reduce product time-to-market; how to safely rollout and support features; how to handle OMG situations and large-scale outages. The user privacy topics and their legal implications become extremely important and should be discussed in great detail.

Looking for more content?

System Design Exercises

Check out the collection of mobile system design exercises.

Common System Design Interview Mistakes

Check the guide here.

Mock Interviews

Check out the mock interview archive or sign-up to be a candidate yourself!

Consider "starring" the repository to help other people discover the guide! Thank you!