Run a system design mock interview with a friend who is not an architect
Sergei Skrylkov, Founder, Trippi · facts checked against the product on 2026-09-30
A system design interview is one problem discussed for forty-five minutes, and what gets judged is how you move through it: whether you ask about requirements, estimate, draw the main pieces, and go deep where the interviewer pushes. A friend does not need to know the answer to run a useful mock. They need to know when to ask what. This script gives them one problem and ten questions tied to the minute they should ask them.
Setup
- Problem for this session: “Design a service that shortens links and counts how many times each short link is opened.” It is common, small enough for forty-five minutes, and has real trade-offs.
- Use a call in Google Meet, or in Zoom or Teams in the browser, and a shared drawing board (any online whiteboard, or paper held up to the camera).
- Your friend reads the questions below at the stated times, whatever you are doing. Real interviewers interrupt; that is part of the practice.
What the real round looks like: the system design interview page. How practice calls work in general: interview practice.
The script for the interviewer
- 1“Design a service that shortens links and counts clicks. Where would you start?” Follow-up: “What questions do you have for me before you draw anything?” — minute 0; your friend answers questions with invented numbers
- 2“How many links a day, roughly? How many clicks?” Follow-up: “How much storage is that in a year?” — minute 5; checks estimation
- 3“Draw the main parts and walk me through one request.” Follow-up: “Where does the short code come from?” — minute 10
- 4“How do you make sure two links never get the same code?” Follow-up: “What happens if that part is down?”
- 5“Clicks are a hundred times more common than new links. What changes?” Follow-up: “Where would you add a cache, and what goes in it?” — minute 20
- 6“The click counts do not need to be exact to the second. How does that help you?” Follow-up: “What would you use to collect them?”
- 7“A popular link gets a million clicks in a minute. What breaks first?” Follow-up: “How would you notice before users do?” — minute 30
- 8“What would you store about each click, and for how long?” Follow-up: “Is there anything you should not store?”
- 9“If you had to cut one component to launch next week, which one?” Follow-up: “What would you lose?”
- 10“What would you do differently if this had to work in three regions?” Follow-up: “none — last question” — minute 40
Timing
| Minute | Stage | What the friend does |
|---|---|---|
| 0–5 | Requirements | Answers questions with made-up but consistent numbers. Writes them down. |
| 5–10 | Estimates | Asks for rough numbers; accepts any reasonable method. |
| 10–20 | High-level design | Lets you draw; asks question 3 and 4. |
| 20–35 | Deep dive | Pushes on reads, counting and the hot link — questions 5 to 8. |
| 35–45 | Trade-offs | Questions 9 and 10, then time. |
| 45–55 | Feedback | Which stage took longest, where you went silent. |
What your friend should listen for
- Questions before drawing. Starting to draw in the first minute, without asking about scale, is the most common mistake.
- Numbers used later. Did the estimate from minute five affect any decision afterwards? If not, it was a ritual.
- Thinking out loud. Silence longer than about twenty seconds. Your friend should note when it happened.
- Trade-offs named. Each choice should come with what it costs. “A cache, which means counts can be a little stale” is the shape.
Switching roles
Swap with a different problem — a chat service, a file upload service, a leaderboard. Playing the interviewer for a design problem teaches the timing: you see how easily forty-five minutes disappear into the high-level drawing, and you will watch the clock differently in your own turn.
What Trippi Cue shows during this rehearsal
System design questions are often long — a minute of context and the actual question at the end. Each line your friend says appears in the Cue window as text, translated under it if you want, so “clicks are a hundred times more common than new links, what changes?” stays readable while you think. For that question the card might offer a few points to cover: read path, cache, what may be stale. It does not see the whiteboard or your drawing; it only hears what is said in the call.
It listens to the call tab after you click its icon, not to your microphone. It hears your friend and never hears you, so it cannot score or review your answer; the feedback comes from your friend. This is a rehearsal: use it to practise with a person until the answers come easily, then go into the real interview on your own. Where we stand on interviews.
FAQ
System design, specifically.
Can a non-engineer run a system design mock interview?+
Yes, with a script. They do not need to judge the design; they need to ask the right question at the right minute and note where you went silent.
How long is a system design interview?+
Usually forty-five to sixty minutes for one problem.
Which problem should I practise first?+
A small one with clear trade-offs, such as the link shortener above. Save large problems for later sessions.
Can Trippi Cue see my diagram?+
No. It hears the audio of the call tab and nothing else. It does not read the screen or the whiteboard.
Read next
One problem, forty-five minutes, a friend with a clock.
Trippi Cue is in the Chrome Web Store. One click on the icon when the call begins, and nothing before that.