Can I use AI to practice system design interviews?

If AI immediately supplies a finished architecture, you lose the chance to practise making decisions. The setup below keeps you responsible for the answer, with a concrete interviewer prompt and rules for delaying hints.

Use this prompt in an AI tool that accepts conversational instructions:

Act as a system design interviewer for a senior backend engineering role. Ask me to design a webhook delivery service. Let me clarify requirements before proposing components. Ask one question at a time and wait for my answer. Challenge my assumptions about traffic, delivery guarantees, and failures. Do not show a reference architecture or offer hints unless I ask. After I finish, identify omissions and questionable claims using specific examples from my answers.

Replace the role and problem with your target. If the AI starts completing the design for you, ask it to return to questions. Answer aloud and draw alongside the conversation, even if you must type a summary into the tool.

For SubcueAI's practice offering, visit the mock interview page.

Set a practice budget before starting. This suggested 40-minute structure is a rehearsal plan, not a claim about any employer's interview format:

• Requirements, 5 minutes: Identify users, essential operations, excluded features, and acceptable delays. For webhooks, clarify whether ordering matters and what a successful delivery means.
• Estimates, 5 minutes: State event volume, payload size, destinations per event, and a peak-load assumption. Keep units visible.
• Initial design, 15 minutes: Sketch event ingestion, durable storage, a delivery queue, workers, and customer endpoints. Trace one event through the system and explain each acknowledgment.
• Deep dive, 10 minutes: Choose a risk such as duplicate delivery, overloaded destinations, or worker failure. Explain a response and its cost.
• Recap, 5 minutes: Summarize the design, its weakest assumption, and what you would investigate next.

Let the requirements justify the components. For example, explain what must survive a process crash before choosing how to persist events. If the mock exposes a knowledge gap, finish the attempt, study that gap, and rehearse the explanation again.

Imagine a backend engineer preparing for a senior platform role with a webhook delivery mock. The hypothetical workload is 10 million events per day, one destination per event, and a 1 KB payload. The AI asks what happens when a customer's endpoint becomes unavailable for an hour.

Start with arithmetic you can explain: 10,000,000 divided by 86,400 is about 116 events per second on average. A separately chosen peak assumption of ten times average gives roughly 1,160 initial delivery attempts per second. Retries add traffic beyond those initial attempts.

With decimal units, the event payloads total approximately 10 GB per day, before metadata, indexes, replication, and other overhead. These are exercise assumptions, not production measurements. To estimate the unavailable customer's backlog, first establish what fraction of events targets that customer.

Then ask the AI to probe these cases individually:

• Lost acknowledgment: The receiver processes an event, but the sender never receives its response. Explain how retrying can repeat a side effect and where deduplication belongs.
• Slow destination: One customer consumes worker capacity. Explain how concurrency limits, retry backoff, and isolation could protect other customers.
• Worker crash: A worker stops during delivery. Identify what remains durable, when work becomes eligible for another attempt, and how duplicates are handled.

For another practice problem, explore the interview question bank guides.

Ask for evidence before accepting a score. A useful review identifies something you said or omitted, explains its consequence, and gives you a specific issue to revisit.

• Requirements: Did your design address the agreed scope and delivery expectations?
• Numbers: Were units consistent, and did you distinguish average load, peak load, and retries?
• Architecture: Could you trace both a successful request and a failure through the diagram?
• Trade-offs: Did you explain a plausible alternative and the consequence of rejecting it?
• Communication: Did you explain why a component was needed before discussing its implementation?

AI can invent service capabilities, miscalculate estimates, or recommend a component that does not solve the stated problem. Recompute the math yourself and check disputed technical claims against authoritative documentation. Ask the reviewer to distinguish a violated requirement from a preference between valid designs.

Keep drawing in the practice loop. Text-only feedback cannot inspect a diagram it has not received, and image-capable feedback can still overlook inconsistencies. Check that your arrows, data stores, acknowledgments, and spoken explanation agree.

Repeat the weakest part without hints, then attempt a related problem with a changed constraint. Track whether you can explain your decisions independently. A peer or experienced interviewer can provide another check on unclear reasoning; an AI score alone cannot establish readiness.