A URL shortener looks like the easiest system design question you will ever get. Store a mapping, hand back a short string, redirect. You could write it in an afternoon.

That is exactly why it gets asked. The naive version really is trivial — so the interview is not about whether you can build it. It is about whether you notice the four decisions hiding inside the triviality:

1. How short can the code be? Not a guess — an arithmetic answer from the traffic estimate.
2. How do you generate the code? Hash the URL, or encode a counter? They fail in completely different ways.
3. 301 or 302? One of these silently destroys your analytics and makes links impossible to change. Most candidates pick it.
4. What stops your service becoming a phishing tool? Every real shortener spends more engineering effort here than on the shortening.

We will build it properly, in the order an interviewer expects, and then cover the production concerns the textbook treatment leaves out.