Mobile System Design Mock Interview: Spotify

[@samk9212]

I'm glad this resource exists (there's nothing out there for mobile system design!). What's valuable about this is that we see the interviewer's point of view. On the other hand, I think seeing the "good" solution thought process would be immensely useful. Maybe, you could do some videos with someone else interviewing you.

[@George-nx8zu]

I would have liked to have seen an ideal mock solution.

[@ronee3959]

at 33:50 , why is it better to keep song data to file system instead of ORM store. For iOS perspective, is Data quality can reduce if I keep data on CoreData? If so, why?

[@mumtazhussain2449]

songs are audio files... you don't store files in databases. You put files into Files folder of app.

[@ronee3959]

@@mumtazhussain2449 thank you.

[@JurisAndersons]

one of the guys has no idea, what he is talking about. made my day 😅

[@hafizawaiskhan5427]

Any clear system design for spotify app that you have created ?? How to gather requirements ? How will be high level diagram ? How things will work according to you ?

[@dralism123]

Is this valid for Android dev roles where its mostly front-end? this looks like mostly backend?

[@romankucherenko355]

Kudos to Alfredo for a nice attempt to construct a system design for a spotify. That is not an easy task and it's hard to come up with all the nuances and the most elegant solution especially during the tech interview. I have only nice vibes from Alfredo and a good overall perception about his knowledge, even considering that he got in the wrong way a bit when describing the components and security details. On the other hand is Alex. At first, there was no mental support nor the directional help for Alfredo. Instead, it was a very detached approach with very little attempts to guide and direct the interviewee. Second, and the most annoying aspect of many-many interviews I have been on myself, is a poor pronunciation from the interviewer. My advice to Alex is to speak slowly and clearly, since I am a native russian speaker as well and I know how hard it is for others to understand the ascent. Don't put candidates in the situation where they are even more nervous because of your poor language skills. The commitment should go from the both sides of the interview.

[@AshutoshRautela]

Great video. But backend was missing

[@houstonduane]

This is a mobile system design interview, it's common to only focus on the client side

[@theAppleWizz]

Lol this is a mobile engineer not an backend engineer it would be crazy to expect detail backend knowledge

[@getreferral]

First of all - I would like to appreciate Alfredo on attempting this question and also coming up with a nice representation of the app. Although System Design questions are vague, this type of question tops the list. The problem with this question is this question is too open ended. Therefore I guess we should ask who is the target audience for the design. Is it a regular consumer like a Product Manager, a more technical person - Engineering lead, or any developer on the team. Without this the initial path flow, there is no goal of this design, this does not provide or add any value either to the system nor to the consumers(interviewer, interviewee, audience) Alfredo has taken few assumptions, but I felt Alex did not pursue them and guide Alfredo to a destination I will be critical here. Alex seemed distracted throughout the interview. I understand that this is a complex problem, but from the beginning Alex did not have any path in his mind, so he was clueless and did not find a path. In my opinion, he moved from one topic to other as the interviewee moved and that lead to too many details on the screen. Sorry man, you were harsh for no reason. It would be nice if the feedback was more on defining this problem into a goal based problem In comparison, the Image Loader library is more concise, it has a problem statement and both the interviewer and interviewee work towards a common goal and the interviewer was clear in his path and guided the interviewee accordingly. Also I appreciate Alex for calling out on the diagram template, though it fits the problem here, it felt too overkill. I appreciate Alex on calling out on copying hehe System design template as it is, instead of focusing on problem based flow. I would like to call out on the naming pattern, this would be a link to the consumer of this design, if it is a Product person, they wouldn’t need *Service style naming. Thanks Alfredo and Alex for sharing this.