What to do different for E6 System design at Meta
Failed this twice. Will try again soon. In total had 4 of those. 3 were yes / strong yes for E5. One weak no for E5. Got asked proximity svc, design memcache, design messenger and design ticketmaster. Bloody ticketmaster was no. Grooking design on that question is horrible. I am wondering for the next time what I could do different to get yes at E6? Meta folks, would you mind sharing the expectations / suggestions? š¬ I usually follow a good framework and managed to get offers from Spotify, Apple and Twitter with it in the past for Staff in the past. Not sure whatās not happening at Meta. Recruiters provided feedback in the past but itās vague. Current comp: 0, recovering after Elno. #meta
System design is a little subjective for sure but the biggest gaps Iāve seen are: 1. TC has a very shallow understanding of systems and isnāt interested in thinking about a problem beyond what they have read. Load balancers, sql vs no sql are good examples - they have 3 things to say about these, but if you dig a little bit further, itās obvious they donāt know about it. 2. For E6, I think the interviewer has to be convinced you understand a reasonable set of things to a decent extent (beyond the initial description). You have to understand how you build the system end to end, make real trade offs based on what weāre optimizing for and describe the second order problems and how you might address them
Hereās a general guideline that I think is reasonable - if i talk to an e6 about a certain subject for 40 minutes, they will understand what Iām saying completely and offer atleast 2-3 new ideas/ perspective about the problem. If you are consistently doing that In conversations with you, youāll likely meet the bar.
Thanks!
What was the E5 offer? Why not take it and try e6 internally?
Well, it didnāt happen thatās why.
You mean that they didnāt downlevel you? Straight reject? Why?
Join https://discord.gg/yM3K3XmP for more discussions around system design.
^ this is great too
Hi, why do you say Ticketmaster in grokking is horrible? I see the same thing mentioned by apple here in the first comment/chart. (ānot done the stupid grokking lld wayā). I would like to understand what should be done differently. If there are better resources for this problem please let me know.
itās designed in the old school SQL way with literally 12 different tables. At senior+, it should be a high-volume āflash saleā scenario where you canāt handle the full traffic with a single DB node. The author of grokking had the āgeniusā idea to do some handwaving and say something like āsee my other chapter about partitioning keys because youāre going to need those hereā ā completely skipping any actual discussion about how to make the problem scale. TRASH. šļø hereās my take that actually tackles the issue with multiple acceptable approaches, none of which involve literally dismissing the big question of how tf to make it scale like grokking did: https://www.youtube.com/live/vhHMEJ_BMh8?si=Y8et2Ys1_R1ub9G_
Excellent, thank you so much.
I used to work at meta and do interviews and I have one guess in to why Meta expects you to lead the entire conversation during the design. They donāt want to ask you any clarifying questions. So for E6 itās your job to clarify all requirements do estimations do overall design low level design all that unprompted and address all concerns for scalability reliability etc proactively
sounds like Behavioural
They were strong yes E5 as well. But I know those were mostly the scope of the work and conflict examples I gave. Have new stories š