System Design Mock Interview Checklist for Senior Engineers

System design mock interviews are useful only if they test the right things.

Many engineers practice by drawing popular systems from memory. That helps a little, but interview performance usually depends on how you think when requirements are incomplete and constraints change.

Use this checklist to practice like a senior engineer.

1. Clarify the problem

Before drawing boxes, ask:

• Who are the users?
• What are the core use cases?
• What is explicitly out of scope?
• What scale should we assume?
• What matters most: latency, availability, consistency, cost, privacy, or speed of delivery?

Good clarification prevents over-engineering.

2. Define requirements

Separate functional and non-functional requirements.

Functional examples:

• users can upload a file
• users can follow another account
• users can search recent messages

Non-functional examples:

• p95 latency under 200ms
• regional availability
• eventual consistency is acceptable
• data must be retained for seven years

Senior candidates make constraints visible early.

3. Start simple

Begin with the simplest architecture that could work.

This might include:

• client
• API service
• database
• object storage
• cache
• queue

Do not start with every distributed systems pattern you know. Add complexity only when a requirement forces it.

4. Find the bottleneck

Ask where the design breaks first.

Common bottlenecks:

• database writes
• hot keys
• fanout
• large objects
• search indexing
• external API limits
• inconsistent reads
• slow background jobs

Your ability to identify bottlenecks is more important than the beauty of the diagram.

5. Discuss trade-offs

For each major choice, say what you gain and what you pay.

Examples:

• Cache improves latency but adds invalidation complexity.
• Async processing improves throughput but delays visibility.
• Sharding increases capacity but complicates queries.
• Strong consistency simplifies product behavior but may reduce availability.

Trade-off language is a senior-level signal.

6. Cover reliability

Interviewers expect senior engineers to think beyond the happy path.

Discuss:

• retries
• idempotency
• timeouts
• rate limits
• fallbacks
• monitoring
• alerting
• rollback

You do not need to cover everything deeply. You do need to show operational awareness.

7. Summarize clearly

End with a short summary:

• the core architecture
• the main bottleneck handled
• the biggest trade-off
• what you would improve with more time

This helps the interviewer remember your judgment, not just your diagram.

For deeper practice, work with a system design mentor or use engineering mentoring to review both interview answers and real architecture decisions.