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
github.com/systemdesignfightclub/SDFC youtube.com/@SDFC https://discord.gg/fJvKBAK6vD
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 😂