How to practice system design interviews with ChatGPT

A copy-paste prompt that turns ChatGPT (or Claude or Gemini) into a system design interviewer, how to run a 45-minute round with it, a debrief rubric, and the four places it falls short with a fix for each.

Reading is half of it. See it used in a real interview.A strong candidate answers Design a URL Shortener turn by turn, drawing the design as they talk. Free, no sign-up.

Watch the walkthrough

You can get a useful system design mock interview out of ChatGPT, Claude or Gemini, and it costs nothing to start. What you cannot do is open a chat, type "interview me on designing Twitter", and expect it to behave like an interviewer. Left to its defaults, a chat assistant answers its own questions, praises vague answers, and follows you wherever you wander. It needs a role, rules and a structure. This guide gives you all three as a prompt you can paste, then shows where the setup still falls short and what to do about each gap.

The prompt

Paste this as the first message of a new chat, with your question in the first line.

You are a senior engineer at a large tech company running a 45-minute system design interview. I am the candidate. The question is: "Design <the system>".

How to run it:
- Open by stating the problem in one or two sentences, then ask where I would like to start. Do not list requirements unless I ask for them.
- Ask one question at a time and wait for my answer. Keep your turns short, like a real interviewer.
- Never design for me. Give a hint only if I am stuck for two turns. Do not praise an answer that is vague: if I say "add a cache" or "use Kafka", ask why, what the key is, and what happens when it fails.
- Push for numbers: requests per second, storage, the size of the largest key or user.
- Move through the stages: requirements (about 5 minutes), estimates (5), API and data model (5), high-level design (10 to 15), deep dives (15), wrap-up (5). I will mark time by writing [10 min], [20 min] and so on. Move me on if I overstay a stage.
- In the deep dives, pick the two or three parts of my design most likely to break at scale and probe each with follow-ups: a failure case, 10x traffic, and why not the obvious alternative.
- I will describe my diagram in text or attach a picture of it. Ask about anything on it that is unclear.
- Stay in role until I write END. Then give a debrief: a score out of 100, a hire or no-hire signal for a senior engineer, what was strong, what was missing, and one line per stage on what a strong candidate would have said.

The rules that matter most are "one question at a time", "never design for me" and "do not praise an answer that is vague". Without them the assistant drifts into teaching mode, which feels productive and is not an interview.

Running the round

Pick a real question. Use one that is actually asked, such as a URL shortener, Slack or a payment system, not one you invent, so you can compare your answer with a reference afterwards.
Start a timer yourself. The assistant has no clock. Write [10 min], [20 min] and so on as you pass each mark so it can move you on.
Say it before you type it. The real round is spoken, and practicing only in writing leaves most candidates fluent on the page and hesitant when they have to say the same design under a clock. Talk your answer out loud, then type a short version. Voice mode gets you closer still: you answer by speaking, and it answers back.
Keep the diagram somewhere else. Draw in Excalidraw or on paper, and after each stage either describe what changed ("added a Redis cache in front of the URL store, keyed by short code") or attach a fresh picture.
Do not ask side questions in the interview chat. If you need to look something up, open a second chat. A side question in the interview chat turns the interviewer back into a tutor for the rest of the round.
End it properly. Type END and read the debrief before you look anything up.

Make the debrief worth reading

A debrief from a chat assistant tends to be generous, because it has nothing to grade you against except your own answer. Two changes help.

Give it a reference. After the debrief, paste the deep dives and follow-up questions from a written reference design and ask: "Grade my answer against these. Which of them did I cover, which did I miss, and which follow-ups would I have failed?" Every question on this site has its deep dives, alternatives and follow-ups written out and free to read, which is what this step needs.
Ask for the rubric by stage. "Score each stage from 1 to 4: requirements, estimates, API and data model, high-level design, deep dives, communication. For each score below 3, quote the turn where I lost it." Quoting the turn stops it grading on vibes.

Where it falls short

Even with a good prompt, a general chat assistant is not built for this, and four gaps remain.

Gap	What happens	Workaround
It cannot see your board	It reads your description of the diagram, not the diagram, so a missing arrow or a store with no key goes unnoticed	Attach a picture after every stage, or describe each component with its key and its callers
Side questions break the round	A question in the interview chat derails it; a question in a second chat has no context, so you re-explain your design	Keep a running summary of your design to paste into the second chat
No reference answer	It cannot tell a merely plausible answer from a strong one, so feedback is generous and generic	Grade against a written reference after the round, as above
It follows your lead	It rarely steers you to the part of the design that is actually hard, and long chats drift	Name the stages in the prompt, mark the time, and start a new chat for each round

None of these makes it useless. A round with the prompt above is far better than reading another breakdown, because it makes you produce the answer under some pressure.

When something built for it helps

The gaps above are why this site exists. The walkthroughs let you watch a strong candidate answer the same question turn by turn first, with the design drawn on a whiteboard as they talk, so you know what you are aiming for. The AI mock interview then puts the interviewer, your whiteboard and an AI Mentor in one room: the interviewer sees what you draw, owns a 45-minute clock, has the reference design in front of it, and ends with a debrief stage by stage. Side questions go to the AI Mentor beside the interview, which knows every turn so far, so the round stays clean.

Whichever you use, the habit that matters is the same: practice saying a full answer out loud, against a clock, until the structure comes without thinking. See how to run a system design interview for that structure, and common mistakes for what to listen for in your own answers.

Questions people ask

Can ChatGPT conduct a system design mock interview?

Yes, if you set it up with a role, rules and a structure. Left to its defaults it answers its own questions, praises vague answers and follows you wherever you wander. A prompt that tells it to ask one question at a time, never design for you, push for numbers, move through timed stages and end with a scored debrief turns it into a usable mock interviewer.

What prompt should I use for a system design mock interview with ChatGPT?

Use a prompt that casts it as a senior engineer running a 45-minute round, gives the question, and sets the rules: ask one question at a time, never design for the candidate, challenge vague answers, push for numbers, move through requirements, estimates, API and data model, high-level design, deep dives and wrap-up, and give a scored debrief when the candidate writes END.

Can ChatGPT see my system design diagram?

Only if you attach a picture of it. It reads your description of the diagram, not the diagram, so a missing arrow or a store with no key can go unnoticed. Attach a fresh picture after every stage, or describe each component with its key and its callers so the interviewer has something concrete to question.

Is ChatGPT's feedback on a system design interview reliable?

It tends to be generous, because it has nothing to grade you against except your own answer. Make it more useful by pasting a written reference design's deep dives and follow-up questions after the round and asking which you covered and which you missed, and by asking for a score per stage that quotes the turn where you lost points.

Should I practice system design out loud or in writing?

Out loud. The real round is spoken, so talk your answer through before typing a short version, or use voice mode so you answer by speaking. Practicing in writing alone leaves most candidates fluent on the page and hesitant when they have to say the same design to an interviewer under a clock.