Machine coding round
URL Shortener Coding Interview Problem
What this interview round tests
The URL shortener is probably the most famous backend interview question in existence — "design TinyURL" opens a thousand system design books. This problem takes the half that can actually be graded and makes it concrete: a working shortener service where aliases must be unique, users have quotas, links expire, and only owners can delete.
What interviewers grade in the implementation round is not the architecture diagram but the invariants. Two users claiming the same custom alias must get exactly one winner. A user’s quota counts active links — so expiry and deletion must free capacity correctly. And resolution must respect expiry at read time, not trust a cleanup job that may not have run. Each of these is a classic check-then-act trap wearing a friendly domain.
The scenario
You are handed a URL shortener backend: users create short links with generated codes or custom aliases, resolution redirects to the target, quotas cap how many active links a user may hold, and links can expire or be deleted. Every feature exists, and the test suite fails across all of them.
Duplicate aliases get accepted, quota checks count expired links (or miss deleted ones), resolution happily serves expired short codes, and any user can delete anyone’s link. Your job is to enforce uniqueness, make the quota reflect reality, and gate deletion on ownership until the suite goes green.
What you’ll practice
- Alias uniqueness: claiming a name as one atomic check-and-reserve
- Custom aliases vs generated codes living in one namespace safely
- Quota accounting that counts exactly the active links, no more or fewer
- Expiry-aware resolution: a link is dead the moment it expires, not when swept
- Owner-only deletion: access control enforced in the service layer
- Deterministic behaviour so identical requests always resolve identically
How to approach it
Treat the alias namespace as the contended resource: creation must check availability and claim the name in one step, because two requests racing the same alias is the first thing the tests (and interviewers) try. Generated codes share that namespace — a generated code colliding with someone’s custom alias is the edge candidates forget.
Then make "active" a single, derived definition: not expired and not deleted. Quota checks, listings, and resolution should all ask that one predicate, so a link expiring implicitly frees quota and stops resolving at the same instant. Scatter the definition across call sites and the tests will find the seam — one path will count a link the other path refuses to serve.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Is this the "design TinyURL" system design question?
It is the implementable core of it. Instead of hand-waving about base-62 encoding and cache layers, you make a real service enforce alias uniqueness, quotas, expiry, and ownership — the invariants any shortener must hold at any scale, and the part a machine coding round can actually grade.
What is the trick in the quota requirement?
The word "active". A naive counter increments on create and never decrements, so expired and deleted links consume quota forever. Deriving the count from live state — or maintaining it transactionally with expiry and deletion — is the difference the tests check.
Do I need to set anything up to try it?
No. Open the problem to read the full brief with no signup, then solve it in the browser workspace or download the starter repo and run the bundled verify script locally in Java, Python, or C++.