Mobile System Design Interviews (Android and iOS)— The Only Mental Model You Need

image source: ChatGPT

👋 Hellooooo and welcome to my article,

If you are here, it means that most probably you are preparing for your next Mobile System Design interview, either for Android or iOS roles. So, yes, you are at the right place 😍

NOTE: This series of articles is specifically prepared for Mobile System Designs and these should be helpful for both the devs — Android and iOS. Being an Android Developer, I will mostly refer Android framework related terminologies but will try to share the iOS counterparts as well.

In this article, I will talk about the strategies and mental model one should follow while preparing and appearing for a mobile system design interview. Let’s get started…

[embed]gif source: https://giphy.com/

1. Break the monologue 🗣

One of the main reasons to take a system design round is to not just evaluate the technical skills of a candidate but also to judge how well he/she discusses a solution or approach with other team members, and not only keeps speaking. You should make sure that you should keep the discussion both sided.

2. Become a painter 🎨

A picture describes more than thousand lines of text and it applies to System Design rounds as well. Whenever you are going to approach a solution, the best way to start it with a diagram. The diagram gives a pretty good understanding of how you are thinking about the solution. When you are able to describe a system in a diagram, half of your work is already done. There are few points I want to highlight regarding this:

a). Have a basic practice on one of your favorite Diagramming tool. Practicing on it before appearing for your interviews gives you a sense of how things work on that particular tool and does not make you nervous if you are not able to find a two way arrow during the interview 😉 Few mostly used such tools are — Miro, Whimsical, Excalidraw

b). Give meaningful names to the components in your diagram. Don’t use abbreviations or short forms to save few milliseconds.

3. Limit your requirements 🫠

Think about creating an MVP(Minimum Viable Product) i.e. while discussing the functional and non-functional requirements, you should limit yourself to include only the most important and valuable features of the product. Adding and discussing about so many unnecessary requirements will eat lots of your time and it may leave you with very short amount of remaining time for few important requirements which the interviewer was most interested in.

4. Don’t go directly to Android terminologies 🫷

When you start creating the high level diagram and speaking about the high level view of your approach, try not to explain it in Android or iOS specific terminologies, try to be generic to Mobile technology.

What do I mean with that, let’s say you start explaining a solution and speak like: “First we will save the data in local SQLite database and then call an api using Retrofit and once data is saved in the backend, we will receive Firebase Push Notifications in the device.” Instead, if you speak it in this way: “First we will save the data in local database and then call a REST api and once data is saved in the backend, we will receive a notifications in the device.”

See the difference here, in the first approach you are being limited to Android, Firebase and SqLite but in the second approach you are thinking like a Mobile Engineer who is thinking in more generic way i.e. he/she is explaining the approach for every platform be it iOS, Android, web etc.

After the initial HLD discussion, the interviewer themself will go deeper into each of the component and there you can tell which specific technology, service provider or framework will be best suitable here amoung various possible options.

5. Think about mobile first 📱

Backend and Mobile system design approaches differ for a single problem statement. When appearing for Mobile System Design rounds, you should think about mobile specific constraints like how will you load the app when the internet is very slow, should you think about offline data storage, how will your app perform the same way in a lower-end device as it does in a high-end device, how will you minimize the data storage and battery usage and so on…

When you think and include all these constraints while proposing the solution in front of the interviewer, your chances of getting hired increases drastically.

6. It’s okay to change the approach midway 🛣️

There might be cases when you are explaining your approach and you are going in a wrong direction. A good interviewer will try to correct you in between and will indirectly ask you a cross question e.g. how will you handle X case with this approach. In that case, you should think about the way to handle that case or if that is not possible with your current approach, you should be happy to change the approach.

You should not get demotivated there feeling that my approach was wrong or they will judge me wrongly. It’s okay to change the approach because they are not expecting you to give the perfect solution in one go. What they will check is how you adapt your approach if a missed case or something different is to be handled.

7. Not knowing everything is totally OKAY ☺️

There are a lot concepts or frameworks you explain while explaining your solution to the interviewer. And it’s totally okay to not have hands-on experience with all of them.

Let’s say you are tackling a problem statement where the best approach to call the backend is using GraphQL, so you will explain that there are few options to call the backend but in this particular use case GraphQL will be the best. And here you should be honest in telling the interviewer that I have not worked with GraphQL but as per my basic knowledge of GraphQL v/s other ways of achieving this task, GraphQL wins the race.

NOTE: Here I would suggest that you should at least know the basics, pros and cons of each frameworks like this so that your interviewer is impressed that you have a broad understanding of various technologies.

8. Don’t chase perfection 📝

One of the most important things to understand about System Design rounds is that there is no single perfect solution to a problem statement. One problem statement can have many solutions. What your interviewer tries to evaluate is how broadly you think, how you think about all the possible cases a real user can face, how you modify your approach if a new requirement comes in between etc.

9. Practice makes a man perfect 🏋️‍♀️

At last, all I can say is that there is no alternative to practice. If you want to ace an interview, you need to keep practicing the previously and most asked questions.

Practicing previously asked questions help you understand what can be the expectations from you in the real interview. The more you practice, the higher your chances of getting your dream job.

This was it about this article. If you liked my effort and it helped you in any way, please clap 👏 as many times as you can(you can clap at most 50 times on an article) ❤️

Do follow me on Medium and **LinkedIn** for more such articles on Mobile System Design. I am planning to cover more real life Mobile System Design interview questions in the upcoming articles.

All the best for your interviews ❤️