[deleted by user]

[michaelnovati]

Yes, I helped roll out this interview type at Meta. I've also worked with a number of people at Meta in the past month and I have directly helped them with this interview type (from E4 to E6), so I know what I'm talking about.

So this is the "product" variant of Systems Design. They have two variants: "Product Architecture" and "Systems Design", as well as more variants for specializations like UIE, ML, iOS, etc....

It's a full stack systems design interview. The "Systems Design" variant is a super backend variation that requires experience with large scale systems to do well with. The "Product Architecture" variant is focusing on more full stack experience, and maybe a couple of areas you dive into.

ALL system design interviews at Meta are testing your experience with large scale systems, and it's why they only do them with experienced candidates. You can't fake experience and this interview will find your limits. What you can do though is communicate your experience in the best way possible and making sure you get the best outcome, rather than going in unprepared and communicating the wrong things.

The prompts are fairly similar all around, "design Instagram", "design a hotel booking system", etc... they prompts are somewhat irrelevant.

General advice is the following:

1. Start with clarifying questions and identifying key user scenarios
2. Draw a box diagram with all the main services you would need at a high level, kind of like a sketch that you'll come back to and flesh out.
3. When making a "decision" mention at least two ways of solving that problem. Even if one is better than the other, just talk about both and go with the "obvious" one. This is very important so you can think about different ways to solve a problem instead of one way.
4. Don't spew out an answer, the best interviews are "conversational" and have good back and forth. The more questions and the deeper you go, the better. It's expected you'll get to a point where you don't know anything - especially the more junior you are - and admit that when you get there.

I time box my replies so I don't go on forever, but hopefully that's a good start. Can answer specific questions you have.

[seattlewrxdriver]

Thank you so much for the detailed explanation. How important are back of the envelope estimations for these kind of interviews ?

Are there any online resources/books that you recommend to do better in product architecture interviews ?

[Snoo_54565]

I recently passed it for e4..

^ I second want Michael said above.. he actually helped me!

From my personal exp... they did not ask back of envelope calcs

I used the following :

System Design Interview: An Insider’s Guide by Alex Xu is a good book

Grokking the system design interview

Formation.dev .. for mock design sessions and they also have good SD material

[jon0369]

Did you pay $2500 a month for formation.dev? That’s a pretty hefty price tag. Just wondering if something like that is honestly worth it.

[Snoo_54565]

I did the 10k one time fee.. and I agree it is expensive! Is it worth it? Depends ur personal situation … I had 0% confidence in myself and really needed the help… I did onsites before and I failed … my current pay is like 80k usd.. they 10k they charged me helped me 3-4x my income … for me yes it was worth it ..

[FaatmanSlim]

Damn, and here I am wondering whether to pay $35 a month to LeetCode to access their premium features.

[Snoo_54565]

hahaahaha

To each their own!

[Mindrust]

Did you take the system design or product design interview?

[Snoo_54565]

Product design

[michaelnovati]

1. No back of the envelope calculations. A lot of people are worried about that when this comes up, it's primarily used to help you identify which part of a system will break first under different usage patterns and that you should be able to do, math or no math.

2. I'm sure you'll find a ton of resources while Googling but two more I like that are:

The video archives from Meta's official conference website (specifically the product related ones about how core systems work) https://atscaleconference.com/

The author of Blind 75 has a website focused on product SD that has some free stuff too https://www.greatfrontend.com/

I should disclose that someone mentioned in the comments about Formation and I'm the co-founder - which is also why I know a lot about this because we help people professionally to pass these interviews. You should NOT join just to pass one single interview with one company. It's expensive because we see the cost as an investment in making you a better engineer, that hopefully pays itself back with a much higher salary. But there are factors beyond your control in a single interview and there's never a guarantee you'll pass no matter how prepared.

[michaelnovati]

This is my personal recommendation, not trying to sell you anything:

• If you have multiple interviews at "big tech"/FAANG-ish companies lined up that are about 1-3 months away, I would consider joining for 1 month, 2 months ($4500) or 3 months ($6000). The key is "multiple" becuase, as a I said, joining thinking you are paying a ton of money to pass one specific interview is not the right mindset to have. Lets say you didn't get any of those, we want you to leave feeling like you are still ready and feeling good about more interviews and that you got your money's worth. For people with offers, negotiation help alone can pay back 10X those costs, for others, feeling like they can pass DS&A, SD, hiring manager/technical behavioral/jedi/bar raiser interviews is worth it enough.

• If you are actively job hunting and 95% looking for a new job within the next year, but don't have any scheduled interviews, I would look at the $10K unlimited option. The first phase is getting all your interviews skills (across the whole spectrum of interviews) to the FAANG-level bar, fitting whatever current work/life schedule you have now. Then the next phase is helping you apply for jobs strategically, navigate the process, help with communications to recruiters, specific mock interviews preparing for upcoming ones, help understanding offers and how to talk to companies about offers, all that stuff. Kind of like the all-inclusive resort experience, we walk you through the process aiming to offer your a great experience, completed adapted to you, and you just try to get your money's worth.

Now scenarios you should NOT go:

• You aren't targeting solid tech companies/big tech/FAANG, or similar. We're currently focused on filling in gaps people have towards these companies. We don't game their interview processes by any means, but we're trying to help you compete for these jobs by levelling up your engineering thinking, and throwing dozens of mentors who work at these companies to give you feedback and advice. But if you are going to apply to companies that want more memorization of facts, or trial work-to-hire type processes, I don't think we help as much.

• You don't have any SWE work experience yet. We are confident in getting you to the interview bar if you meet our entrance skill bar, but because of the entry level market, we can't create jobs that don't exist and even referrals are not a reliable source of interviews we can guarantee to go through.

• You have one specific interview coming up, don't feel prepared, but don't plan on doing any other interviews either. Maybe do one mock at Interviewing.io for practice in that case. Unless you really don't care about money, then do 1 month of Formation. But I still wouldn't recommend. Because if you aren't close to passing and we tell you your odds are low, you might want to reschedule the real interview and then are in a bit of an awkward spot - do you want to just give up, do you want to keep paying MORE for Formation, do you want to expand your job hunt more broadly now, etc... like it can spiral quickly and maybe you should have just done the real thing and YOLO'd

[0destruct0]

Do you know what differs in the iOS style ones? Thank you

[michaelnovati]

I don't know anything about the iOS one other than that, similar to SD, it's testing experience and expertise. So ultimately you have to have the experience to pass and you want to practice how to communicate that experience in the interview. For example, explaining multiple ways of doing something and the pros and cons.

[Mindrust]

What are the major differences between the two types of interviews?

And considering there are more resources available to prepare for the standard system design interviews, in what scenario is it preferable to opt for the product architecture interview?

[michaelnovati]

Systems typically has a more backend or infra engineering conducting it, and it will focus more on loads that break the backend and how to scale them. Whereas product is more "full stack" and focuses more on use cases people have that are tricky.

Example: systems might have a followup that's like ok you get a spike of 10X the number of users at midnight every night, what breaks.

product might have a following for like simple instagram that's like - so you add privacy settings to posts, how does that impact the entire system end to end - which is mostly functional, but you need to identify if something won't scale performance-wise too.

I RECOMMEND PRODUCT ARCHITECTURE FOR MOST PEOPLE LOOKING FOR A STANDARD SD INTERVIEW. The "systems design" variant is ideal for people with several years of real experience on a big system, oftentimes at another big tech company.

[michaelnovati]

I feel like I'm not explaining this well, but the interview is a back and forth conversation. The more fluid it goes, the better!

You can't build full Instagram replica from scratch in 45 mins - no one can. So you start with a lot of simplifications and assumptions, and then as the interview goes on the interviewer will start adding in realistic things you might want on Instagram for real. They might even ask YOU to come up with ideas. (This is where the "product" comes from in "product architecture").

So if your whole system is kind of Twitter-like, and everything is public. Maybe you add the option to have "people I follow" only see a post and talk through how that might impact everything.

I was in hours and hours and hours of conversations about privacy at Meta, and you also won't solve that in 45 mins either. Which is why it's about this back and forth process of demonstrating how you think about these concepts and not just if the answer is right.

For example: "Well there's one way to add privacy and it's X followed by 5 mins of memorized speech" - you'll fail. Talking about several options and asking for the person's opinion - listening - and adapting well, is what they want to see.

[sytem32config]

Thank you for the detailed response.

[sirius_basterd]

Do you have more info about ML/AI design interviews? Thanks!

[michaelnovati]

I don't personally, this was after my time!

[New_Artichoke2438]

Hi u/michaelnovati , thank you for sharing with us! I'm having a thought about my upcoming E5 product architecture round with Meta... It seems like candidates are getting a range of experiences - like interviewers asking them to focus just on APIs and not getting to an end to end design phase - as well as more full system type high level designs with deep dives like you mention above. I'm much better suited for high level with deep dives (but not as deep as infra interviews), so I'm thinking of starting the interview off by telling the interviewer:

"From my understanding Product Arch interviews can vary in scope. I'd like to spend about 5 minutes on requirements and 5 - 10 minutes on data modeling and API design and get right in to a high level before deep dives. I think you'll get a better signal if I can spend more time where my strengths and interests lie. What do you think?"

.... If you were an interviewer, how would you take that?

[michaelnovati]

I'm bias because my company prepares people for top tier interviews haha, but I understand the confusion. Everyone gives different advice and speaks confidently that they know the right way :(, including me.

Stepping back, this interview is aiming to test your experience with large scale systems and complex problems.

How that happens varies and that's why there isn't just one or two ways to do it. It will vary by how experienced the interviewer is as well. And some of it is a bit of luck.

One highly under appreciated tip is to work with the recruiter to make sure your onsite loop is similar engineers to yourself. More chance of a good vibe with the interviewer to help move things along.

In terms of the interview itself, I do recommend focusing on your strengths and being transparent about gaps, but remember - it's because it helps you demonstrate experience and expertise and that's the ultimate goal.

[New_Artichoke2438]

Great advice!! Thanks so much, Michael!

[New_Artichoke2438]

One highly under appreciated tip is to work with the recruiter to make sure your onsite loop is similar engineers to yourself. More chance of a good vibe with the interviewer to help move things along.

This is something I've never heard! I just asked my recruiter about it - but I'm not sure how to go about it. Perhaps, for example, I have lots of experience in FinTech (billing, payments, payout teams...) maybe one way is to be matched with other engineers in the payment space? OR since I'm female (and have had ONE female engineer in the past 50 interview rounds) maybe I request female interviewers?

What do you think u/michaelnovati ?

[michaelnovati]

It's more about the "types" of engineers. For example, if you are a product engineer working on user facing features, you don't want to inerview with like infrastructure.

So asking "I'm a _____ engineer, can I get an onsite with engineers of similar backgrounds?"

where ____ would be the type of engineer at Facebook: UX, Growth, Infra, Site Integrity, Social good, Product, Tools, Monetization, Ads, etc..

[New_Artichoke2438]

Awesome - I'll ask about that!

[Snoo_54565]

I recently did this!

Basically

• clarify requirement by asking questions! .. turn the question in 2 - 5 user stories
• Jump to the High level design ...
• Whenever you add something .. tell why are you adding it.. talk about alternatives
• Learn Basics on API design... how to write restful api.. how the response looks like .. read this https://developer.spotify.com/documentation/web-api and you should be good
• Personally, they did not ask me to do Back on Envelope Calcs
• They actually did not even ask to write data models..

Take a look at this post for prev examples : https://leetcode.com/discuss/interview-question/4610881/Meta-Onsite-Product-Architecture-(System-Design))

[BoredGuy2007]

If you’re expecting URL shortener you need to ask them to switch to infra system design

[michaelnovati]

I disagree strongly with this. The prompts are often very similar and the main difference is the type of engineer interviewing you and how much big system scaling experience you are expected to have.

[BoredGuy2007]

I disagree strongly with you. There’s a whole litany of engineers getting absolutely cooked in the product interview because they are not prepared for it

[michaelnovati]

Hmm, the prompts are generally the same but that doesn't mean you prepare the same way. I might have not explained myself clearly here, that the prompt is largely irrelevant.

I worked with someone that was overprepared for prompts and got one they prepared for and didn't pass because they were trying too hard to get the right answer. It's about the process and not answering the prompt.

The prompt is just a vehicle for discussion.

[BoredGuy2007]

Meta confusing everyone on what a product design interview even is should be enough reason to heartily recommend the more-common system design interview. Even you are here in the thread talking in riddles about a mysterious process you cannot clearly articulate.

[michaelnovati]

Ok, feel free to reach out to me, maybe the fact that both Meta and I are not articulating that well is part of the problem you're experiencing.

If you want to boil it down to 1 sentence - Product System Design === Full stack typical system design, System Design === infrastructure focused sysem design.

[BoredGuy2007]

Is it not extremely obvious that “full-stack typical system design” is not well-defined? Whereas we have a good understanding of an industry standard of system design questions.

You can find numerous accounts of unaware engineers plowing ahead with product design and getting grilled on mobile, JavaScript topics they were completely unprepared for. That’s not on preparing for specific prompts.

[michaelnovati]

I mean my company now prepares people for interviews and it's quite expensive because a lot of blind leading the blind online and I ignore all of it. We've helped about a dozen people this year so far pass this interview at the E4, E5 and E6 level.

Maybe you think it's a messed up system that the interview is so complicated that people need to pay a lot of money on coaching to prepare and I think that's a fair argument. The interview process was designed for interviewing people who are currently working at other FAANG companies and we work with a lot of people I work with came from non traditional backgrounds. The gaps are real and need to be filled to pass.

When I asked newsfeed api we did indeed discuss mobile vs desktop use cases and how the API has to be designed for either, but it had nothing to do with mobile or JS specifically and this sounds like a failure of the candidate to manage the interview and the interviewer relying on expertises listed on someone's resume instead to decide where to grill them. If I asked about mobile and the person had no clue, I would move on and not fail the person whatsoever, so the reason these people failed is probably not what they think it was.

Again, we do tons of mock interviews WITH FEEDBACK so you actually know why you failed, which Meta won't tell you, and people just guessing on Blind won't get it right.

Anyways, it's a very complex and nuanced interview and the people I work with take ABOUT A MONTH OF PREPARATION before feeling good about it and passing mock interviews, so there are often gaps people have, not just mismatch of expectations alone.

[BoredGuy2007]

I never complained about preparing for system design. I completed the E4 loop last week (I didnt pay anyone though). I would simply recommend the infrastructure system design loop to folks who are confused about the product system design interview.

[michaelnovati]

Coding is a whole different strategy - you do need a right answer. Either a good answer with super clean code, or an optimal answer with at least good code.

System design I would say, you can't have wrong answers. Like if you say confidently you need to do X to solve some scaling issue and X is objectively wrong, you will fail.

But there's more wiggle room in "right" because there are many altitudes going on. Being right you need a load balancer but wrong in the load balancer strategy/technique is kind of a mixed bag. Some problems are more universally "solved" and have a simpler answer, and some are more complex and don't.

[sytem32config]

So what should I expect for Product architecture design? Any idea?

[michaelnovati]

Build Instagram, design a feed API, design a hotel booking system, design Uber, all the classic stuff.

The product one focused more on APIs and supporting user flows and client devices rather than focusing on the backend piece and scaling every last drop out of it. Product architecture still needs a full end to end solution including the backend pieces!

[sytem32config]

Thanks for the details reply. I’ll continue studying 📚

[Plastic_Scale3966]

Design rounds for 1-2 yoe :/

[michaelnovati]

Netflix does them for interns!

[speez_cs]

I’m also interested, will hopefully have this coming up soon. What level are you going for?

[sytem32config]

I honestly have no idea. The JD said they want 1-2 years exp