Mobile System Design Mock Interview: Shopping App (like Amazon)

[@macankurprakash]

Thanks for the efforts you are putting in and helping others!

[@alekseyblekot119]

Thank you guys! This is very helpful for me while preparing for the interview in Lyft)

[@oleksiisosevych]

Thanks for the video! Great interview and post-analysis, constructive feedback on candidate performance and design process is very insightful

[@ankyan5472]

I'm preparing for an interview next week. I really enjoyed this video especially the part you gave feedback. thanks

[@user-sq1sc]

Thank you Alex for sharing.

[@Ethan-uz4pd]

Thanks Alex, that's very helpful.

[@nikprabha9099]

Great feedback Alex

[@stavklass]

Guys, could someone help me to figure out Anton’s idea with domain layer, please? I was totally confused when he told that it can be on both client and backend side. So backend is a separate thing which returns unprepared data, and is just a mediator between a server and a client, which do nothing than just prepares data to right format? Or it contains ability to adjust business logic somehow? Or something else? Thanks in advance

[@blundellappdev]

You could google "Back end for frontend" (BFF) for more on the topic.

[@smilebot484]

Is it reasonable to design the whole app in a 1 hr interview? I would say design the cart or the main feed or something.

[@otifelix]

Thank you Alex you are amazig

[@ravishankarasrinivasa241]

Alex, great videos on Mobile System design. Learning a lot.. But I am trying to understand one thing.. How important it is know the size of the team, team structure etc, in order to come up with the system design. Also, why is that information required?

[@jerry-r-4067]

just my opinion, I don’t think it’s required in most cases. That info doesn’t impact our mobile side design that much

[@maksymfedoriaka2851]

Team size can impact approach to modulatization and repo management. In a very small team with a small app you can get by with the simplest setup. As you grow, modularization becomes important, you may want to split up the features into separate modules so that separate sub-teams don't interfere with each other. Also you might consider tools that make living in a large team easier (on iOS it's Tuist for example, that allows you not to have a project file in the repo, avoiding tons of conflicts). In a massive organization like Google you may put those modules into separate repos even. For example, tons of their apps share functionality

[@rachitmishra1]

I have no body to guide except me 😭

[@ihwandotid]

Nice

[@qqu2mc79]

To me the candidate did better than the feedback made it seem