[Mobile System Design Interview] Step by Step Guide to Succeed in Mobile System Design Interviews

Photo by UX Store on Unsplash

Mobile system design interviews can be more intense than they initially sound. To excel in these interviews, you need to take control and not let the interview steer you. In this step-by-step guide, we’ll show you how to dominate your mobile system design interviews and make them feel like a walk in the park.

But before I dive into the intricacies of the interview process, it’s essential to grasp some fundamental concepts. Every mobile application is composed of several major components:

1. UX/UI — This encompasses controls like List controls (TableViewController, CollectionViewController), Image controls (caching and lazy loading), navigation handling, and more.
2. Network — Involves API handling, error management, response parsing, and response caching.
3. Models — Includes API models, mathematical services, and models if needed.
4. Functional Requirements — Features directly impacting the application and are part of the requirement.
5. Non-Functional Requirements — Features not directly specified by the interviewer but vital for the application, e.g., pagination, media caching, security, offline support, push notifications, and state management.

I recommend that you read my article on mastering these components before proceeding. You can find it here: Mobile Application Design Roadmap: Components to master before mobile design interview.

In the high-stakes world of mobile system design interviews, your first 10–15 minutes could make or break your shot at success. As you delve into my step-by-step guide for acing these interviews, remember: a strong start is your secret weapon. These interviews are often just 45–60 minutes long, and that initial introduction is your chance to set the tone for the remaining time. So, prepare, present yourself with confidence, and seize the opportunity to shine. Your first impression will last, carrying you through the crucial 45 minutes that follow.

Let’s start!

Mobile system design interviews present a formidable challenge. Imagine this: you receive a vague directive from the interviewer, like designing the High-Level Design (HLD) for an app akin to Instagram. With just 30 to 45 minutes on the clock, crafting a comprehensive Instagram-like HLD seems insurmountable. The question looms large: What’s the way forward?

In this high-pressure situation, you must rethink the scope of the task. Propose narrowing the focus to a manageable module within Instagram, such as the Home Feed or Reels. Your ability to redefine the challenge sets the stage for success, making the impossible, possible.

Step 0 — Redefine the Scope
It’s crucial to recalibrate the scope of the requirements, ensuring they align with the available time frame. Typically, you suggest focusing on a specific module within the application when tackling the High-Level Design (HLD). In the case of the Instagram app, you can propose a negotiation like this: “Given the limited time, designing the entire HLD for Instagram is quite ambitious. How about we narrow our focus to a particular aspect of Instagram, such as the Home Feed, Reels, Messages, or Instagram Stories?” More often than not, this proposition is met with agreement, and for this example, let’s say we opt for Instagram’s Home Feed.

Step 1 — Clear agreement on in-scope and out-of-scope features (Functional requirements)
It’s essential to document the list of features, possibly on a drawing pad, both for clarity and as a reference point for agreement with the interviewer. Engage in an ongoing dialogue while outlining these features, welcoming their valuable input.

Creating distinct lists for in-scope and out-of-scope elements serves as a helpful guide to maintain focus on essential features.

Now, let’s apply this approach to defining what’s in-scope and out-of-scope for the Instagram Home Feed. This feed comprises various cards that users access by interacting with the Instagram Feed API. Each card typically features a profile picture, profile name, handle, media content (photo or video), possibly a collection of media, a caption, likes count, share count, first comment, comments count, options to add new comments, like the post, share the post, and bookmark a post.

To manage this within a time constraint, you can further negotiate by marking “Add new comment,” “Like the post,” “Share the post,” and “Bookmark a post” as out-of-scope. These elements are self-contained features and can be excluded from the Minimum Viable Product (MVP) without affecting the core feed functionality. Additionally, you may also consider negotiating the exclusion of navigation elements.

Step 2 —Agreement on In-scope and out-of-scope non-functional requirements
Similar to Step 1, establishing consensus on the inclusion and exclusion of non-functional requirements is equally important. It’s vital to document these non-functional requirements and differentiate between what falls within the scope and what remains out of it. Consider aspects like the necessity of offline support, the temporary omission of push notifications and deep linking handling, the expected implementation of pagination for list feeds, and any mathematical or date models required. For instance, this might include displaying post ages or creation dates in terms of day of the week, days, months, and years, as well as the incorporation of analytics for each module.

Step 3— List out all the APIs and Models that would be required to build the feature
Identify all the APIs and define the necessary models you’ll require to build the features. This step is crucial for a well-organised design process. It ensures you won’t get lost when designing the HLD.

Steps 0 to 3 necessitate a thorough inquiry process to gain the clearest understanding of what should be incorporated into the High-Level Design (HLD).

By this point, you’ve not only introduced yourself but also recalibrated the scope of the task, documented both functional and non-functional requirements, and created a comprehensive list of the APIs and their corresponding models necessary for High-Level Design (HLD). Remarkably, you haven’t initiated the actual HLD phase yet, and around 20 minutes have already elapsed. Now, you find yourself with a tight window of approximately 25 to 40 minutes to tackle the core HLD. The interview dynamics have shifted, and you have greater autonomy.

To optimize this critical stage, practice becomes your best ally. It’s through consistent and rigorous practice that you can refine your approach, ensuring a more efficient and successful design process.

Step 4 — Design the HLD
Remember that your HLD is frontend-facing, so you don’t need to delve into the complexities of the backend system. However, having knowledge of the backend is an advantage.

Your HLD should encompass module-specific logic(VIPER, MVVM, etc), business logic (both module-level and app-level), caching (includes DB like CoreData, Realm and also media caching), and network modules. Explain each module’s design and observe the interviewer’s level of interest. You may need to deep-dive into a specific module if requested.

Step 5 — (on interviewer’s demand only) Deep dive
High-Level Designs (HLDs) typically provide a broad overview of your logic. However, it’s equally essential to delve deep into the specific module that piques the interviewer’s interest. For instance, in the context of an Instagram feed HLD, the interviewer might be particularly intrigued by your approach to handling the media resolver. This component encompasses various media types, including images and videos, which must start playing when they appear on the screen and stop when they leave it.

During this deep dive, discuss the design patterns you intend to implement, elaborate on your chosen caching techniques, and more. For instance, you might opt for URLCaching or SDWebImage to efficiently cache and load images in the background while optimizing network calls. In the case of videos, the object pool design pattern could be employed to restrict the number of video players and reuse already created instances. To manage video playback, you may describe how you’ll monitor scroll events and determine which video cards are currently visible, ensuring a seamless media experience.

Step 6 — Class Diagram
In some cases, the interviewer might ask you to switch to a Low-Level Diagram (LLD) or a class diagram for a specific module. This involves designing the class-level interactions within that module.

What else to expect?

At times, it’s crucial to provide explanations for the following concepts, making it essential to possess a solid grasp of these topics:

1. WebSocket Utilization: WebSocket is employed when maintaining an open, bidirectional communication channel is necessary. For instance, it’s utilized in scenarios like real-time chats or updating locations on maps during food orders or cab bookings.
2. Distinguishing REST, GraphQL, and gRPC: Proficiency in distinguishing these communication protocols — REST, GraphQL, and gRPC — proves invaluable.
3. HTTP Methods (GET, POST, PUT, DELETE): Understanding the distinctions between these HTTP methods (GET, POST, PUT, DELETE) is pivotal.
4. Multipart Upload Insights: Multipart upload knowledge is pivotal, particularly in cases involving substantial file uploads, such as zipped event analytics or video file uploads.
5. Caching Techniques and Third-Party Solutions: Familiarity with caching techniques and third-party solutions like SDWebImage and Kingfisher enhances your capability.
6. Database and Persistent Data Storage: Knowing when to apply various data storage methods like CoreData, RoomDB, Realm, Sqlite, file system storage (UserDefaults), KeyChain, or CloudStorage is essential.
7. Distinguishing Push Notifications from Local Notifications: Recognizing the disparities between push and local notifications and understanding the appropriate scenarios for their use is critical.
8. Video Understanding: Discerning the distinctions between video formats (MP4 vs. M3U8 vs. FMP4) and video encoding (H264 vs. H265) is vital.
9. Design Patterns: Having a grasp of design patterns, including Creational, Structural, and Behavioral patterns, is paramount.
10. SOLID Principles: Understanding SOLID coding principles is fundamental to robust software design.
11. Data Structures and Algorithm Techniques: Proficiency in data structures and algorithm techniques, such as managing conflicts, implementing bloom filters, solving island problems, and employing two-pointer strategies, is indispensable.

If you’re interviewing for a higher position, a general understanding of how backend systems work can be beneficial. This might include topics like DNS, load balancers, scaling techniques, CDNs, caching, network protocols (TCP, UDP), HTTP, HTTPS, response codes, SQL vs. NoSQL databases, message queues, and more.

Lastly, maintain a positive and engaging demeanor throughout the interview. Communication and a friendly attitude can make a significant difference.

Wishing you the best for your upcoming interviews, and we hope this guide helps you succeed. If you have any questions or need further clarification on any steps, please don’t hesitate to leave a comment. Feel free to share this article with your friends and colleagues who are also preparing for mobile system design interviews. Your support is greatly appreciated.. Link to previous article:

• Mobile Application Design Roadmap: Components to master before mobile design interview

How you can support me?

• For any queries related to the article or mobile system design interviews, please leave a comment.
• If you have doubts about any of the steps, drop a comment.
• Share this article with friends and colleagues preparing for mobile system design interviews.
• Show your appreciation by clapping as much as you like; it encourages me to create more content.
• Follow my profile to stay updated on new articles.
• Bookmark this article for future reference and quick access.