LESSON 2.5
Deep dives, and what each level is expected to show
Use the non-functional requirements to find the weak spots in your design, fix two or three of them well, and know what mid, senior and staff answers look like.
6 min read
Your high-level design works. Now you make it good. The deep dives are where you show judgment, and where most of the interview signal comes from.
Find the weak spots
Go back to your non-functional requirements and check each one against the design. For the URL shortener:
| Requirement | Does the simple design meet it? | Deep dive |
|---|---|---|
| Redirects under 100 ms at 10k/s | One database doing 10k lookups/s is at its limit | Cache hot links; add read replicas |
| Highly available redirects | One server, one database: any failure takes it down | Several stateless servers behind a load balancer; database replicas with failover |
| Short codes are unique | Random codes plus retries get slower as the table fills | Counter-based IDs with base62 encoding, or pre-generated code blocks |
| Never lose a link | One disk | Replication and backups |
Pick the two or three that matter most and go deep. You will not have time for everything, and depth on the right things beats shallow coverage of everything.
What a good deep dive sounds like
A deep dive has a shape: problem, options, choice, consequences.
- Problem, with numbers. "Peak redirects are about 12,000 a second. A single Postgres primary handles a few thousand indexed reads a second comfortably. So reads are the bottleneck."
- Options. "Read replicas, a cache in front of the database, or both."
- Choice and why. "Redis in front, with cache-aside. Links never change after creation, so staleness is not an issue, and a small set of popular links gets most of the traffic. A cache with a few GB of memory should absorb over 90% of reads."
- Consequences. "A cold cache after a restart sends a burst to the database, so I'd keep two replicas behind it as well, and warm the cache with the top links."
What each level is expected to show
The same question is asked at every level; the expectations differ.
Mid-level
- Clear requirements and API
- A complete, working high-level design
- Sensible answers when the interviewer probes
Pick it when: Breadth and a correct design matter most; you may be guided toward the deep dives.
Senior
- Drives the conversation to the hard parts unprompted
- Compares options with trade-offs
- Uses numbers to justify choices
Pick it when: Expected to own the deep dives and spot bottlenecks before being asked.
Staff+
- Spots the one or two decisions that really matter
- Reasons about operations, failure modes, evolution and cost
- Simplifies where others over-engineer
Pick it when: Judgment and depth on what actually matters, often drawn from real experience.
Close the loop
End by walking quickly back through the requirements and pointing at how the final design meets each one, and what you would do next with more time: monitoring, rate limiting, analytics. It turns a set of boxes into a story the interviewer can repeat to the hiring committee.
Try it
Distributed ID Generator HLD
Go deep on one hard part: generating unique IDs across many machines.