What this prompt does
This prompt runs a full system design interview with the AI acting as your interviewer. You set the [level] and the [system] to design, and it drives four timed phases: requirements gathering with clarifying questions about your [scale], high-level design covering API, data model, and architecture, a deep dive that pushes you on [deep_dive_areas] with "what happens when..." questions, and a trade-offs round challenging you on [tradeoff_topics]. Afterward it scores you 1-5 on requirements, architecture, scalability, and communication, lists strengths and gaps, gives an ideal-answer outline, and recommends resources.
The structure works because system design interviews are evaluated on process, not a single correct diagram. By enforcing the real phase sequence and reserving deep-dive pressure for [deep_dive_areas], the prompt forces you to defend choices under questioning the way a live interview does. The [scale] variable anchors the whole conversation in concrete numbers, which is where vague candidates usually fall apart.
When to use it
- You are preparing for a
[level]system design round and want realistic pressure. - You want to practice the full arc: requirements, high-level design, deep dive, trade-offs.
- You need to be pushed on specific
[deep_dive_areas]rather than coast on the happy path. - You want a 1-5 score across requirements, architecture, scalability, and communication.
- You need an ideal-answer outline to compare your design against.
- You want targeted resource recommendations for your weak areas.
Example output
Expect an interactive, phased session: the AI asks scale and constraint questions, evaluates your API and data-model choices, presses you with "what happens when..." questions on [deep_dive_areas], and challenges your [tradeoff_topics]. It closes with a scorecard, a did-well/should-improve list, an ideal-design outline, and resource suggestions.
Pro tips
- Treat the
[scale]numbers as binding and reason about them explicitly — capacity estimates are where the deep dive gets hardest and where weak candidates stall. - Pick
[deep_dive_areas]that match your actual weak spots so the simulation pressures the parts you most need to rehearse. - Answer the clarifying phase as if it counts; rushing to architecture before nailing requirements is the most common scoring miss this prompt will catch.
- Set
[tradeoff_topics]to the genuine tensions of your[system]— consistency versus availability, latency versus durability — so the challenge round is realistic. - Match
[level]to the role you're targeting, since a senior bar expects depth on failure modes a mid-level prompt would not press. - Lead with API design and the data model before drawing boxes, since a clear interface and schema make the rest of the high-level design follow naturally.
- After the score, redo the same
[system]addressing the gaps it flagged, rather than jumping to a new design — iteration is where the learning lands.
