Act as a senior engineering interviewer conducting a system design interview for [TARGET ROLE]. I have [TIME LIMIT] minutes and my background is [MY EXPERIENCE]. Use this question: [DESIGN QUESTION]. My priorities or weak areas are [PRACTICE GOALS]. Run this as an interactive interview, not a lecture. Start by stating only the scenario and let me drive. Answer my clarification questions as a realistic interviewer would, including reasonable scale estimates, product constraints, and non-functional requirements. Do not reveal a preferred architecture unless I ask or time expires. As I answer, assess whether I: 1. Clarify users, core flows, scope, scale, latency, availability, consistency, privacy, and cost constraints before designing.
2. Propose a high-level architecture with clients, APIs, services, storage, queues or streams, caches, and third-party boundaries where relevant. 3. Estimate traffic, storage, bandwidth, and hot-key risk using explicit assumptions. 4. Go deep on the most consequential components, including data model, partitioning, replication, cache invalidation, idempotency, retries, backpressure, observability, and failure handling as appropriate. 5. Explain trade-offs instead of presenting every choice as universally correct. Challenge gaps with concise follow-up questions. Give time checks at roughly the halfway point and five minutes remaining. At the end, produce: a scorecard for requirements gathering, architecture, scaling, trade-offs, communication, and depth; the strongest parts of my answer; the three highest-value fixes; a reference outline, not a word-for-word script; and five targeted drills. Self-check before feedback: distinguish facts I stated from assumptions you supplied. Flag any recommendation that would be inappropriate for the stated scale or requirements. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [TARGET ROLE] | Enter the job level, company type, and engineering role you are preparing for. | Senior backend engineer at a consumer SaaS company |
| [TIME LIMIT] | Enter the interview length, such as 45 minutes. | 45 minutes |
| [MY EXPERIENCE] | Summarize your relevant systems, seniority, and areas you have not worked on. | Six years in Java and AWS; built payment APIs and batch pipelines, but little hands-on streaming experience |
| [DESIGN QUESTION] | Enter the system you want to design, such as a URL shortener or collaborative editor. | Design a notification system for email, push, and in-app alerts |
| [PRACTICE GOALS] | Enter the skills you want to improve, such as capacity estimates or database trade-offs. | Practice clarifying requirements, choosing data stores, and explaining reliability trade-offs |
How to use
- Paste the prompt and replace every bracketed input before starting.
- Answer the interviewer aloud or in short written stages; do not ask for the solution immediately.
- Compare the final scorecard with the actual role’s interview rubric or job description.
- Follow up with: “Run the same question again, but interrupt me whenever I make an unsupported scaling assumption.”
Variations
Mock panel interview
Use this for a senior or staff-level interview with competing stakeholder concerns.
Run a 50-minute staff engineer system design panel for [ROLE]. Scenario: [SYSTEM]. My background is [BACKGROUND]. Simulate an engineering manager, product lead, and principal engineer. Let me lead after brief context. Each panelist should test a different concern: customer value and scope, delivery and team boundaries, and technical scale or reliability. At the end, provide a panel debrief with evidence from my answers, unresolved risks, and a sharper design narrative. Do not invent experience I did not state.
Architecture review
Use this when you already have a proposed design and need rigorous critique.
Review my proposed architecture for [SYSTEM] at [EXPECTED SCALE]. Here is my design: [DESIGN NOTES]. Evaluate it as an interview answer for [ROLE]. Identify missing requirements, invalid assumptions, single points of failure, data-consistency issues, unsafe retry paths, capacity bottlenecks, and unnecessarily complex components. Return a prioritized review with severity, why it matters, and a specific revision. Then give me a 10-minute explanation order. Flag claims that cannot be justified from my notes.
Company-specific practice
Use this after researching a company’s products and technical domain.
Create an interview practice plan for a [ROLE] system design round at [COMPANY], using these known products or domain notes: [COMPANY NOTES]. My experience is [BACKGROUND]. Propose six plausible design scenarios, ranked by relevance, without claiming insider knowledge. For the top two, list the likely requirements, useful clarification questions, architecture topics, and domain-specific pitfalls. Produce a two-week drill schedule with one timed session and one review exercise per scenario. Separate public facts from reasonable inference.
Tips
- State a credible scale only after you define the active users, request rate, object size, and retention period that drive it.
- A diagram is useful only when its arrows carry meaning; label sync versus async paths, ownership boundaries, and the data each store holds.
- When a requirement conflicts with another, name the chosen priority. For example, a notification feed may accept eventual consistency while payment delivery usually cannot.
- Interviewers often learn more from one component explored deeply than from a list of technologies; choose the component that carries the main risk.
FAQ
Should I use AI to generate a complete system design answer?
Use it to practice reasoning and receive critique, then explain the design in your own words. Memorized answers tend to collapse when the interviewer changes the constraints.
What scale should I use when the prompt gives none?
Ask for it. If the interviewer makes you assume, state a plausible estimate, show its arithmetic, and explain how the architecture changes if it is wrong.
How long should a system design answer take?
For a 45-minute round, spend the opening minutes on requirements, show a high-level design early, then reserve substantial time for the highest-risk components and trade-offs.