System design
System design mock interviews with a whiteboard you share
Practice the system design round with someone you trust playing the interviewer. InnerViewHub opens a room with the prompt, a shared whiteboard and video side by side, and ends with a scorecard built for design interviews, not a generic “how did it go?”.
What the room gives you
When you create a system design interview, the room opens with the tools that round needs and nothing else in the way.
- A shared whiteboard. Boxes, arrows and handwriting on one canvas that both of you draw on, synced as you go.
- The prompt beside it. The interviewer can load a problem statement into the room so the candidate isn’t working from memory.
- Video in the room. No separate call link; faces stay next to the diagram instead of covering it.
- Private interviewer notes. The interviewer can jot down signals as they happen; the candidate never sees them.
- Chat for pasting a number or a link without interrupting the drawing, saved with the interview.
- A summary afterwards. The whiteboard, notes and chat are saved, so you can look back at how the design evolved. The video is not recorded.
You choose who interviews you: invite them by email or share the room link. Anyone else has to ask to join, and you decide whether to let them in. A third person can join as a read-only observer, which is a good way for a mentor to watch two peers practice.
A 60-minute session plan
Most system design rounds last 45 to 60 minutes. This plan leaves time for feedback, which is the part that makes a mock interview worth doing. The interviewer keeps time and says when a phase is over.
| Minutes | Phase | What the interviewer listens for |
|---|---|---|
| 0–5 | Framing | Does the candidate restate the problem and ask who the users are before drawing anything? |
| 5–12 | Requirements | Functional requirements, then non-functional ones: scale, latency, consistency, availability. Rough numbers, out loud. |
| 12–30 | High-level design | Main components, how data flows between them, the core APIs and the data model. |
| 30–45 | Deep dive | One or two hard parts in depth: a bottleneck, a failure mode, a hot key, a consistency problem. |
| 45–50 | Wrap-up | What would they change at 10× the load? What did they leave out on purpose? |
| 50–60 | Feedback | Scores and written feedback first, then a conversation about the two biggest gaps. |
If you only have 45 minutes, shorten the high-level design and keep the deep dive: it is where senior candidates separate themselves, and it is the part people skip when they practice alone.
How the candidate is scored
After the session, the interviewer rates the candidate from 1 to 5 on each criterion below and writes a few honest sentences. These are the exact criteria InnerViewHub uses for system design interviews.
| Criterion | What a strong score means |
|---|---|
| Communication | Explained their thinking clearly and asked good clarifying questions |
| Requirements | Clarified functional and non-functional requirements and scale |
| High-level design | Sensible components, data flow and APIs |
| Deep dive | Went deep on the hard parts: data model, bottlenecks, failure modes |
| Trade-offs | Weighed alternatives and justified decisions |
The interviewer also gives an overall hire signal on a six-step scale: Strong hire, Hire, Lean hire, Lean no hire, No hire, Strong no hire. Feedback runs both ways: the candidate rates the interviewer on clarity, helpfulness, professionalism, so the person playing interviewer gets better too. The full feedback rubric explains how to score each level.
Prompts to practice
Pick a prompt the candidate hasn’t prepared. Each one below has a natural place to go deep; the interviewer should steer there if the candidate doesn’t.
| Design… | Where to push in the deep dive |
|---|---|
| URL shortener | Read-heavy traffic, ID generation, caching hot links, what happens when the cache is cold. |
| Rate limiter | Where it sits (gateway or service), token bucket vs sliding window, sharing counters across nodes. |
| Chat / messaging | Delivery guarantees, ordering within a conversation, online presence, offline delivery. |
| News feed | Fan-out on write vs on read, the celebrity problem, ranking vs chronological. |
| Notification service | Multiple channels, retries and idempotency, user preferences, rate limits per user. |
| File storage and sharing | Chunked uploads, metadata vs blob storage, sharing permissions, deduplication. |
Tips for the person playing interviewer
- Hold the numbers back. Give scale figures (users, requests per second, data size) only when the candidate asks. Asking is part of the requirements score.
- Pick one deep dive and stay there. “What happens when this database goes down?” followed by two follow-ups tells you more than five shallow questions.
- Ask for the trade-off, not the answer. “Why a queue here instead of a direct call?” Good candidates name what they gave up.
- Write notes with timestamps. “At 22 min, chose SQL without discussing write volume” is feedback the candidate can act on; “needs more depth” is not.
- Swap roles next time. Interviewing someone else is one of the fastest ways to see what a strong answer looks like. One click swaps interviewer and candidate in the room.
Common questions
Do both people need an account?
Yes. Everyone in the room signs in, which is how the room knows who is the interviewer, the candidate or an observer.
Can we use our own problem?
Yes. You can write your own problems in InnerViewHub and load them into the room, or just say the prompt out loud and start drawing.
Is it free?
Creating an account and running interviews is free.
Can I practice coding rounds in the same place?
Yes. A coding interview opens with a shared editor you can run code in instead of the whiteboard, and a “technical” interview gives you both.
Run your first system design mock
Create a room, pick “System design”, and send the link to the person who will interview you.