What this round is testing

A whiteboard / system-design round for frontend looks for:

• Scoping: do you ask the right questions before designing?
• Altitude control: can you move between architecture diagram, API contract, data model, and a single component?
• Trade-off naming: do you say 'X over Y because Z' instead of just listing tech?
• Data modeling: can you design schemas that serve the read paths the UI needs?
• Scale thinking: do you know where it breaks at 10x, 100x?
• Communication: can the interviewer follow your diagram?

Phase 1 — Clarify (5 min)

Never start drawing immediately. Ask:

• Users: who, how many, growth rate?
• Scope: what features are in vs out for this design?
• Constraints: latency, uptime, regions, devices?
• Data shape: rough volumes, hot vs cold?
• Read/write ratio: read-heavy → cache; write-heavy → queue.
• Real-time?: WebSocket / SSE / polling?
• Auth model: tenancy, sharing, permissions?

The interviewer will steer you toward the parts they want explored.

Phase 2 — High-level architecture (10 min)

Draw the boxes:

┌─────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ Browser │───▶│  CDN /   │───▶│   API    │───▶│ Postgres │
│         │    │  Edge    │    │ Gateway  │    │          │
└─────────┘    └──────────┘    └────┬─────┘    └──────────┘
                                    │
                          ┌─────────┼─────────┐
                          ▼         ▼         ▼
                      ┌──────┐ ┌──────┐  ┌──────┐
                      │ Redis│ │ Queue│  │  S3  │
                      └──────┘ └──────┘  └──────┘

Narrate as you draw. Label arrows with protocol. Group by tier.

Phase 3 — APIs (10 min)

Pick the 3-5 most important endpoints. For each:

• Method + path: GET /api/v1/feed?cursor=...
• Auth requirements.
• Response shape (sketch JSON).
• Pagination model (cursor > offset for scaling).
• Caching headers / strategy.
• Error semantics.

Discuss REST vs GraphQL vs RPC if relevant. Justify the choice.

GET /api/feed?cursor=abc&limit=20
→ {
  items: [{id, title, author, createdAt, snippet}],
  nextCursor: 'xyz',
}

Phase 4 — Data model (10 min)

Sketch the core tables:

users(id, email, name, created_at)
posts(id, author_id, title, body, created_at)
follows(follower_id, followee_id, created_at)

Talk about:

• Primary keys (uuid v7 for sortability, snowflake for distributed).
• Indexes for the read paths.
• Denormalization where needed (counts, hot rollups).
• Soft delete vs hard delete.
• Audit log if relevant.

Tie this back to the API: which queries each endpoint runs, what indexes support them.

Phase 5 — Scaling (5-10 min)

The interviewer will push: "what breaks at 10x users? At 100x?"

Common bottlenecks and answers:

Don't just list — pick the bottleneck the interviewer points at and go deep.

Phase 6 — Trade-offs (ongoing)

Every decision should come with a trade-off statement:

• "Cursor pagination over offset because at 100k items offset cost is O(N)."
• "Push-on-write fan-out for users with <10k followers; pull-on-read for celebrities."
• "GraphQL for the dashboard's nested reads; REST for write endpoints."
• "Redis for hot leaderboards; Postgres materialized view for slow ones."

Communication tactics

• Diagram first, words second. The interviewer's eye follows the whiteboard.
• Color or group by tier if the marker allows. Edge / API / Data should be visually distinct.
• Number your boxes when you're about to reference them.
• Pause to invite: "Does this make sense so far? Anywhere you want me to go deeper?"
• Flag explicit punts: "I'm going to skip the auth model unless you want me to dive in."

What seniors do differently

• They surface constraints the interviewer didn't mention but should care about.
• They name the boring failure modes (cold start, region failure, idempotency).
• They reason about cost, not just feasibility.
• They sketch the migration / rollout, not just the steady state.
• They explicitly note what they're NOT optimizing for ("OK to drop some events on partial outage").

Common mistakes

• Drawing for 20 minutes before clarifying.
• Listing 17 technologies — picking microservices, Kafka, CQRS, K8s — for a 10k-user app.
• No trade-offs — every decision sounds free.
• All architecture, no data model.
• All data model, no architecture.
• Not inviting the interviewer to steer.

Mental model

A whiteboard round is a structured conversation, not a complete design. Phase: clarify, sketch, drill into APIs + data model, discuss scale, surface trade-offs. Move between altitudes as the interviewer steers. The diagram is the anchor; the trade-offs are the substance. Done well, you finish with a coherent system on the board and a clear sense of what you'd build first, what you'd skip, and where it'd break at scale.