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.
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.
u/BoredGuy2007 wrote (the comment Michael replied to):
If you’re expecting URL shortener you need to ask them to switch to infra system design
u/michaelnovatireplied·
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.
u/seattlewrxdriver wrote (the comment Michael replied to):
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 ?
u/michaelnovatireplied·★ FEATURED
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.
u/0destruct0 wrote (the comment Michael replied to):
Do you know what differs in the iOS style ones? Thank you
u/michaelnovatireplied·
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.
u/BoredGuy2007 wrote (the comment Michael replied to):
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
u/michaelnovatireplied·
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.
u/sytem32config wrote (the comment Michael replied to):
So what should I expect for Product architecture design? Any idea?
u/michaelnovatireplied·
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!
u/Plastic_Scale3966 wrote (the comment Michael replied to):
Design rounds for 1-2 yoe :/
u/michaelnovatireplied·
Netflix does them for interns!
u/Mindrust wrote (the comment Michael replied to):
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?
u/michaelnovatireplied·
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.
u/la-Crow-10 wrote (the comment Michael replied to):
Curious, I've seen good things about formation, but given the current job market, would you say most of us mid-level should hold off on getting a service like that until we have a bunch of interviews lined up?
u/michaelnovatireplied·★ FEATURED
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
u/BoredGuy2007 wrote (the comment Michael replied to):
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.
u/michaelnovatireplied·
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 sentance - Product System Design === Full stack typical system design, System Design === infrastructure focused sysem design.
u/BoredGuy2007 wrote (the comment Michael replied to):
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 see numerous accounts of unaware engineers plowing ahead with product design and getting gril
u/michaelnovatireplied·
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 peopel I work with take ABOUT A MONTH OF PREPARATION before feeling good about it and passing mock interviews .
u/la-Crow-10 wrote (the comment Michael replied to):
Sorry for spamming you with replies but -- theres very little prep material on how to add privacy settings, vs a ton on how adding a queue could help absorb spikes in events. It seems to be a very hard interview to prepare for (im guessing privacy settings would mean you add a pr
u/michaelnovatireplied·
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.
u/la-Crow-10 wrote (the comment Michael replied to):
Could you elaborate on this? Its common for people in tech to say the answer doesnt matter, its the process of problem solving, but in my experience, everyone i know who passed meta and others \*had\* to get the right answer for coding and design, yet ive never seen someone give
u/michaelnovatireplied·
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.
u/sirius_basterd wrote (the comment Michael replied to):
Do you have more info about ML/AI design interviews? Thanks!
u/michaelnovatireplied·
I don't personally, this was after my time!
u/New_Artichoke2438 wrote (the comment Michael replied to):
Hi Michael, 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 focus just on APIs as well as more full system type high level designs with deep dives l
u/michaelnovatireplied·
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.
u/New_Artichoke2438 wrote (the comment Michael replied to):
>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
u/michaelnovatireplied·
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..