System Design for PMs
System design questions never disappeared. They got quieter recently, pushed aside by the wave of AI-related technical questions. But companies like Amazon, Stripe, Uber, and Roblox still run them.
Why this matters now
The assumption that system design is an engineering concern has always been wrong, but it now costs more. PMs are taking on more ownership of technical decisions: scoping features against infra constraints, pushing back on complexity estimates, and making build-vs-buy calls without engineering in the room. Interviewers use system design questions to test exactly that capacity.
The bar isn't engineering depth; it’s product judgment applied to technical constraints. Those are different things, and this lesson shows you how to demonstrate the latter without needing to have the former.
What interviewers are scoring
Your recruiter will flag in advance if a system design round is in your loop. When it appears, the interviewer is not checking for code, implementation details, or infrastructure expertise. They're scoring four things:
- Whether you can translate user needs into system requirements
- Whether you can identify the components that matter and explain why they're there
- Whether you reason about tradeoffs before being asked
- Whether you're credible enough on technical constraints to be a real partner to engineering
The five-step framework
These steps work for almost any system design prompt. The order is deliberate: each step builds the foundation for the next. The most common failure mode is skipping straight from prompt to architecture and spending ten minutes designing the wrong system.
We'll walk through each step using a real, recent question from a Roblox PM loop.
The prompt:
Roblox has users in different languages and a machine learning system for auto-translation. Design a system that would automatically translate between different people on different servers.
Step 1: Clarify and scope
This is the step most candidates rush, and it's where interviews are lost.
Before drawing anything, ask questions. Who are the users and what are they trying to accomplish? Are there constraints worth knowing about: scale, latency requirements, data sensitivity? What functionality should be in scope, and what should be explicitly excluded?
Even if the prompt seems unambiguous, summarizing your understanding back to the interviewer before you start serves two purposes: it signals that you think before you build, and it gives the interviewer a chance to course-correct before you're ten minutes in.
Step 2: Define requirements from user needs
Now you translate your product understanding into concrete requirements in the form of a user journey: walk through what the user does step by step, then convert each step into a system requirement.
This step comes before architecture for a specific reason: requirements give you a principled basis for deciding which components belong in your diagram. If a component doesn't trace back to a requirement, it probably shouldn't be there. Candidates who skip this step almost always over-engineer or miss something obvious.
Step 3: Identify system attributes
Beyond what the system does, define how it should feel. These are qualities, not features. Common attributes in PM loops: speed, accuracy, reliability, privacy/security.
This step comes before architecture because your attributes determine your tradeoffs. Two systems with identical requirements but different attributes can look completely different in practice. A medical records system and a social feed technically have similar data requirements. Their attributes make them architecturally different products.
Step 4: Build the basic architecture
Now draw the diagram. Cover every component needed to satisfy your requirements, what each component does, and how components communicate with each other.
Stay at the right altitude. You're not writing pseudocode or specifying a schema. You're showing that you understand the pieces, why they're each there, and how data flows between them.
Step 5: Surface tradeoffs and improvements
Close by proactively raising the tensions in your design. Don't wait to be asked. This is the step where senior candidates set themselves apart. Not because they built a perfect system, but because they already know where it bends.
Ask yourself: what in this architecture is at odds with the attributes I defined? What are the failure modes? What would I change if scale doubled or latency requirements tightened?
Candidates who only describe what they built look like they're presenting. Candidates who also say, "Here's what I'd worry about and why," look like they're thinking.
Variation: Reverse system design
Many companies, such as Stripe, can put you through a reverse system design round (Stripe staff PM interview). The prompt is simply: "Walk me through a system you've previously designed. Describe the architecture, components, and how data flows through it."
They're testing whether you've actually shipped something technical and can articulate it precisely. You have to know the architecture, the data flow, the key tradeoffs, and one concrete technical decision you'd make differently in hindsight. A candidate who recently went through this question puts it plainly: "Go in with one system you know cold and be ready to whiteboard the architecture, the data flow, and one concrete technical tradeoff like conflict handling."
If you've led a technically complex product, this is your moment. If your background is lighter on technical ownership, use prep time to pick the most technical project you've touched and reconstruct it at this level of detail.
Common pitfalls
Don't try to be an engineer. The moment you start speculating about infrastructure tools or implementation details you're not confident about, you lose credibility. Stay at the product-architecture level. If the interviewer wants more depth, they'll push.
Don’t get intimidated by the prompts. If they just say “Design ChatGPT,” and give zero guidance, they are trying to scare you. You don’t need to build something as complex as ChatGPT. That took many people months. You need to buckle down, like you have 45 minutes and a team of engineers for whom you are the tech lead, and you need to come up with a plan for them to build an MVP. It doesn’t have to be fancy. It doesn’t have to be complicated. It just has to get done.
It’s more important to cut scope than it is to add functionality. The more senior a candidate, the more scope they will cut. They will abstract away components: “Let’s keep that as a black box for now, and we can come back to it later.” This is an excellent tactic. You have 45 minutes. Make the scope manageable.
Don’t name a specific brand of technology unless you know its alternatives. Don’t say “Let’s use Redis here” unless you’re ready to answer “Why not Memcached?” If you throw out a brand name, that is the most common follow-up. To be safer, simply say “Let's use a cache here.”
Don't skimp on questions, even if the prompt seems clear. Good system design interviewers purposefully withhold information. And candidates can only unlock that by asking questions. Many times, system design prompts have a linchpin, and the only way to crack it is to ask questions. Requirements gathering unlocks good designs that your interviewer actually wants. Ask away.