Meta Product Architecture/Design Interview - Part II - Design Code Judge Mock Interview

แชร์
ฝัง
  • เผยแพร่เมื่อ 29 ก.ย. 2024
  • Discord Link: Channel Discord Community: / discord
    Part 1: • Meta Product Architect...
    Today's video is the follow-up to the video I did explaining the Product Architecture interview. Today we are going over a leaked question and how you might want to approach this in terms of the things you need to discuss.
    I purposefully did not make this a complete solution because there are too many things to discuss and it's based on you as to where you want to deep dive and discuss further. Every interviewer will want something different so it's pointless to try and copy other people's designs.
    That being said, the video is meant to provide for you the frame of mind you'd want to be in to approach this interview and how you should be tying in your design into the user experience.
    TIMESTAMPS:
    00L00 Introduction & Disclaimer
    01:45 Question Presentation & Basic Requirements
    05:10 SQL DB Models + Schema
    09:25 System Diagram
    19:25 APIs
    27:20 Mock UIs
    31:30 Deep Dive into User Experience During Contest
    43:39 Outro Ramble

ความคิดเห็น • 18

  • @CSwithSolve
    @CSwithSolve 5 หลายเดือนก่อน

    Very Insightful Thanks 🙏 Subscribed.

  • @zkkzkk32312
    @zkkzkk32312 5 หลายเดือนก่อน

    thank you so much for the content

  • @bharatjain6930
    @bharatjain6930 3 หลายเดือนก่อน

    Hey, I really appreciate your efforts to make this video. There are very less resources on prod arch and earlier I was left confused about the expecatations of the interview.
    I've worked primarily as a frontend engineer with little backend knowledge. I'm targetting Full stack E5 role and I have my interview in couple of weeks.
    Would you say that in broad sense, prod achitecture is majorly about Frontend system design + Low level Design (Backend -> APIs, schema)?

  • @LuisRoel
    @LuisRoel 3 หลายเดือนก่อน

    Hey! Big fan! Thank you so much for the great content!
    I tried to design this myself before watching your video, and I got almost the same design by deeply analyzing the first video in this series...I'm in between roles right now, so my apologies for not being able to subscribe. I have been trying to scrounge the money to get your highest tier before my full loop at the end of this month...but if you have the time, I would really appreciate your feedback.
    I'm stuck as to what the best way to serve the leaderboard would be...Thinking about latency in terms of "real-time" is difficult because it really depends on what the tolerance for latency is.
    Assuming a latency of 1-2 seconds is acceptable, I've come up with a couple of solutions.
    What option is best for a product arch interview? I'm pretty sure I'm thinking about this too deeply, but I'd love to know your thoughts/insights.
    Option 1:
    Those instances (of the leaderboard service) read directly from the in-memory DB.
    The tradeoff is while you gain a lot of speed doing it that way and always have the most current data (which is great for user exp.),
    it leaves the system vulnerable to load spikes on the in-memory DB , which if by some miracle (and assuming we had no replication),
    was brought down, our entire system would fail (which is horrible for user exp).
    If getting the data is O(1), then these spikes might be neglible to
    the stability of our system, but it opens us up to a (extremely unlikely but possible)
    DDoS attack if somehow, bad actors are able to bypass mitigation at the load balancer by forging headers
    or using a network of proxies.
    These issues would mostly be mitigated using streaming replication, but then that would also add some (probably neglible) latency...
    Option 2:
    There is a "Leaderboard update service" which hits the In-memory DB every few milliseconds and publishes updates to a queue,
    which is then consumed by the "Leaderboard service" instances.
    The tradeoff is, you drastically reduce the load on the in-memory DB and the system becomes able to handle large traffic spikes
    with little instability using the queue as a buffer. You're able to scale and be more resilient, with less resources...at the expense
    of adding complexity and latency to the system. You're also moving the "source of truth" (in the eyes of the client) from the actual DB
    to this queue, which means that data might stale by a few milliseconds, to perhaps a second or so, maybe more.
    Added latency in this case is neglible (?), but is bad for User exp, considering Users will want updates constantly
    to see where they stand in the ranking. Also, some messages might be lost, which is acceptable (to a degree), as
    all we care about is the latest state of the leaderboard.
    When the contest ends, the result will be written to the relational DB + we will grab the leaderboard from relational DB
    which is how we'll determine the winner as submission with timezones AFTER the contest end date probably should not be considered.
    PS: Please "ramble" more, your "rambling" is very insightful

  • @jiminy-nf1os
    @jiminy-nf1os 6 หลายเดือนก่อน +1

    thanks for this! where would you rate your performance in terms of E4 / E5 / E6?

    • @crackfaang
      @crackfaang  6 หลายเดือนก่อน +4

      Well it's hard to say because I purposefully didn't present a complete solution but probably the E5 level. I think to make it a solid E5 hire mark you'd need to also deep dive into how to support multiple programming languages and perhaps a bit more details on the in-memory DB which would handle the real-time leaderboard.

  • @mindrust203
    @mindrust203 5 หลายเดือนก่อน

    I have my onsite interview for meta in 6 weeks, do you have any recommendations for resources to study for the product architecture interview?
    I have Alex Xu's book which I'm going through, but it is more standard system design and doesn't quite cover API design and user experience in depth. Would Grokking the API Design Interview be a good resource to try?
    Also thank you so much for this content, it is absolutely invaluable

  • @siulrose
    @siulrose 4 หลายเดือนก่อน

    Love your videos! Can we get more Product Architecture Mock interviews?

  • @suri4Musiq
    @suri4Musiq 5 หลายเดือนก่อน +2

    This came in at the perfect time, I have my Product Arch interview the coming week and these kind of resources are a gem!

    • @elkingthemc
      @elkingthemc 3 หลายเดือนก่อน +1

      I have mine coming up. How’d it go?

    • @denver4denver
      @denver4denver 22 วันที่ผ่านมา

      I hope you either passed the interviews or gained some valuable insights. If there are any differences from this guide, it would be great if you could share them. Thanks in advance!

    • @denver4denver
      @denver4denver 22 วันที่ผ่านมา

      @@elkingthemc ​​⁠ I’d love to hear your thoughts too, as there’s so little information about product architecture available online. If you’ve come across a more relevant guide, please share it. Thank you!

  • @parkerdollar
    @parkerdollar 5 หลายเดือนก่อน

    We can introduce a service on the server for sanitizing the submitted code to prevent in code injection per se.

  • @adityaveda2995
    @adityaveda2995 5 หลายเดือนก่อน

    thanks for this video, it gives me good food for thought!

  • @tunepa4418
    @tunepa4418 4 หลายเดือนก่อน

    Do we really have to draw the UI in product architecture interviews?

    • @crackfaang
      @crackfaang  4 หลายเดือนก่อน

      Depends on what the interviewer wants to discuss. It's definitely not off the table

    • @tunepa4418
      @tunepa4418 4 หลายเดือนก่อน

      @@crackfaang waoh I have been trying to make a decision whether to switch to systems design. I guess this answers my question. I don’t have so much experience with user experience applications but I have read much more about systems design. What do you think

    • @denver4denver
      @denver4denver 22 วันที่ผ่านมา

      @@tunepa4418 System design is somewhat easier to cover because it has defined boundaries, and there are courses available on the topic. If you have strong knowledge of backend tools (not so many gaps in that area), I would recommend focusing on system design. In my view, you should only choose product architecture if you can thoroughly discuss any level of the stack, including the client-side tech and user experience.