Imagine that Hubspot would like to create their own URL shortener service how would you design that. Again here i was pretty familiar with the subject as again I implemented this in one of my personal projects so I did a lot of research on this topic. Anyway, here I went again from describing the DB table to describing the REST API design as related to all HTTP requests, like POST and GET methods. Going even into details like examine the "path" associated with the incoming URL, validation, ways of shorting the URL like saving the url into a table and return the ID and convert it to base-62 or 64 to provide an unique identifier that you'll return to the user. Covered also the topic of maybe not directly leaking the DB ids to the URL (even so convert it to a base 62), in which case you can easily salt the IDs as you choose appropriate. How to save and reverse the salt. Covered as well a different implementation, this time which involved keys and hashing. Top of that I also mentioned that apart from the normal implementation we can build a REST API that does the same thing, allowing other services to use the Hubspot URL shortener, providing examples on how the structure of the rest endpoint name would look like, explain that we can also rate limit the API...etc I even covered the topic of that if I have like thousands of request per minute, here I said that I would probably use additional Web servers on the front end and, while behind I would use a load balancer so it can handle with the amount of incoming requests, make use of extensive caching to resolve the new URLs without having to go every time to the master table. In addition to that I could have multiple DB's a master and a few slaves, write only in my master and read only from the salves...There was a lot of taking and the interviewer seems really pleased with my answers.