The Mobile System Design Interview: My FAANG Prep Journey + Free Practice Resource

Context

When talking about System Design, most resources, experiences written online focus heavily on backend system designs. But if you’re aspiring to be a mobile (Android, iOS) engineer at one of the FAANGs, you’ll have to go through a rigorous mobile system design interview.

I’ve interviewed at 3/5 FAANG companies, and have cleared their system design rounds. And after about 6 years as a mobile engineer, I feel I have a fairly good experience about what consists of a system design round at these companies.

But there’s a dearth of mobile focused system design preparation material. So in this blog, I’ll share my experience interviewing at these companies, and a few tips on how to prep for one. I hope this will help any aspiring mobile devs who have an upcoming interview.

My Experience

The interview at FAANG consists of 3 main components:

1. Coding interviews: can range from 2 - 3 rounds of Data Structure and Algorithms focused interview.
2. System Design interview: While mostly 1, recently there’s been a push for 2 rounds of system design interviews. I’ve experienced it at one of the big techs.
3. Behavioural Interview: These are interviews focused on your past experiences. Questions are situation based and the best way to answer these is using the STAR method.

So let’s talk about System Design.

Here’s some of system design questions I’ve encountered so far in my interviews:

1. Design an image caching library like glide.
2. Design a 1 to 1 Chat application which can also send images, videos.
3. Design a App Store.
4. Design an e-commerce app’s homepage.
5. Design a stock market app’s ticker page. The page which displays the prices of stocks.

These are some of the major ones that I remember.

And while you can find answers to most of them online, just mugging up is never the solution. When I tried mugging up initially, it made me anxious as the interview day got closer. I became anxious that I might forget to draw a component.

After failing a few interviews, I realised I wasn’t failing because I lacked knowledge, I was failing because I obsessed over details instead of thinking like an architect.

See, for system design interviews, you can direct them in any way you want. It’s up to you how you steer the interview. You can go down the rabbit hole of discussing very specific details, or you can focus on the building blocks of the design and if need be, explain the block which you’re most confident about. Let the interviewer grill you on a component. Don’t make it hard yourself.

My Preparation

As a mobile (android, react native) engineer, I couldn’t find many resources to prepare for the interviews. There were questions sprinkled here and there, but nothing like Grokking the system design interview which was heavily backend focused.

I tried doing some mock interviews with my friends, but they weren’t necessarily helpful. Most of my friends were backend engineers + it was hard to schedule time with them due to our heavy workload. Weekend plans never materialised.

I came across some websites which offered system design interviews with engineer from FAANGs but it was too costly for me.

Plug: I created mockingly.ai to solve for this problem. The first mock interview platform with mobile-specific system design questions, instant AI feedback, and on-demand practice. It’s like having a FAANG engineer available 24/7 to mock interview you. Right now, the first session is free!

Next up, weebox’s github repository was the first resource that was actually helpful for me. It had mobile focused system design questions.

Then I did the worst thing possible, I tried mugging up all the answers. As I said, design interviews are very subjective and mugging never helps. I failed miserably at a design interview for a job I desperately wanted. I was disheartened. I had been fairly confident that I could clear the design round as I had all the answers in my head, so I couldn’t believe I screwed up the interview.

I had screwed up some sys design interviews before, but those weren’t for jobs that I was desperately aiming for, this time it hit different. Something had to change.

And that change was my preparation strategy. I realised that mugging up won’t help. I needed to really understand how system design worked, what are the components to focus on and the concepts. Also, my approach to interviews had to change.

Here’s what I did:

1. I looked at weebox’s mobile system design questions not as an Android, iOS engineer. But as an architect.
2. I started thinking in terms of Screens, presentation layer, data layer. I read how repository pattern works.
3. Actively tried not to think in terms of Android concepts like work manager, foreground services, etc…I wanted to think high level, like an architect.
4. Picked up 1 question from Weebox, and tried to solve it myself.
5. Reviewed my diagrams comparing it to Weebox’s answers.
6. Next, pick up some concepts which I wanted to learn such as http vs https, rest vs WebSocket vs GraphQL.
7. Started actively critiquing my design choices. eg. why did I choose REST and not WebSocket? What’s the difference, how do they both work.
8. I tried mock interviewing, but couldn’t find people for it. Moreover, our timings never matched. mockingly.ai would have been really helpful for preparing for system design interviews. I could do the mocks on demand.
9. Designing libraries was no different. Even though they have no screens, they have an entry point. for example: CacheManager for a caching library, which would talk to other components like repository, file cache, sqlite etc…

It took me almost 4-5 months to get my head around system design interviews. The major change was my thought process. I started to think like an architect instead of a domain expert (like android engineer, iOS engineer).

Then I scheduled some interviews.

Interview experience

Once I got done with my prep, I decided to appear for some interviews, and luckily got a chance at one of the FAANGs.

This time I wasn’t anxious. At least not about my system design interview. I knew I had the concepts in my head, I knew I had prepared well. And if only I could communicate what I was doing and thinking and explain my decisions, it’d be a breeze!

And it was, I got the feedback, and even though I didn’t make it (due to a coding round), I had cleared the system design interview and it was s STRONG hire. Yay! I was overjoyed, I had overcome the only obstacle I had in my interview preparations.

System design had always been a mistery to me. And I had finally solved it.

I still need to prep for system design rounds, just as I need to do for coding rounds, but it’s not daunting to me anymore. I now have my resources that I can pick up just a month before the interview and be ready.

Preparation tips:

Here I’ll collate all the things that you’ll find helpful for your system design interview prep. I’ll keep it mobile focused (sorry backend engineers):

1. mockingly.ai for practicing system design interviews whenever you like.
2. Weebox’s Github repository for reading up on the questions and answers. It’s like a question bank.
3. Alex Lementuev’s youtube channel. Some interviews are helpful. I would not take the answers on face value, but watch the flow of the interview and the candidate’s thought process.
4. Speak. Speak a lot! Practice thinking out loud. You’ll need this to direct the interview.
5. Understand how things like http, rest, GraphQL, WebSocket work and why would you pick one over the other.
6. Think like an architect and not a XYZ engineer.
7. Practice…

Next up, a step-by-step framework for any system design interview:


1. Clarify requirements.
2. Identify users and flows.
3. Break down into layers (UI, data, networking).
4. Highlight trade-offs.
5. Deep-dive into one component.

Let me know if you found this blog helpful. I wished a guide existed for mobile engineers to prepare for mobile system design interviews. Here’s my attempt at creating one :)

If you’re prepping for mobile interviews, give mockingly.ai a try and tell me what you think. I’d love your feedback — and maybe your success story will be the next one featured there.