How the interviewer opens it
“Let's design a URL shortening service, something like bit.ly. A user gives us a long URL and gets back a short link; anyone who opens the short link ends up at the original page.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- custom aliases
- expiry
- analytics
- scale / links created
- read:write ratio / clicks
- latency
- availability vs consistency
- short code length
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Create a short link from a long URL
- Redirect a short link to its long URL
Usually out of scope
- User accounts and billing
- Malware scanning pipeline
- Link editing
What interviewers probe
- Short code generation
- Codes must be short and never collide, across many servers.
- Read path and hot keys
- Massively read-heavy and skewed: one viral link can get millions of clicks.
- Redirect semantics
- A subtle product/infra trade-off most candidates get wrong.
Common mistakes
- No clarifying questions; jumping to Kafka/sharding at 40 writes/s
- Choosing NoSQL 'because scale' rather than because of the access pattern
- Ignoring the read:write skew and hot keys
The bar by level
- Mid-level (L4/E4)
- Clean API and data model, a working ID scheme with collisions handled, cache-aside for reads.
- Senior (L5/E5)
- Drives the discussion: block-based ID allocation, hot-key mitigation, 301 vs 302 trade-off, failure modes of the counter and cache.