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 Modern 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.
Educative's system design courses helped fill exactly this gap — structured, on-demand prep with real-world systems broken down end-to-end, so you can practice anytime instead of waiting on a mock partner.
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. Educative's AI-POWERED Mock Interviews 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.
|