https://documents.lucid.app/documents/24a2a903-a2ce-4689-a326-754f49024f94/pages/0_0?a=694&x=62&y=-138&w=1150&h=249&store=1&accept=image%2F*&auth=LCA 61eddb84014c2fc8d566ea01f4ad07ecd59567f6db68098745ce31cfb80f114f-ts%3D1718386741

This solution is tailored for those interviewing for senior-level positions, such as staff engineers and above. It focuses on high-impact topics, bypassing low-information areas like back-of-the-envelope calculations or basic API design. Instead, it dives directly into advanced design challenges and complex problems. If you're aiming for a senior role, this resource is perfect for you.

Interviewer’s problem statement

URL shortener is a service that takes a long URL and converts it into a shorter one. This shorter URL redirects users to the original long URL. URL shorteners are widely used for sharing links on platforms where character count is limited, such as Twitter, or to make links easier to remember and share. Examples include bit.ly, tinyurl, and rebrandly. Now, let’s design the software architecture of such a service.

Applicant Step 1: Write down user experience flow

This is the first challenge for the applicants: Disambiguate the vague problem statement. One strong strategy is to convert the vaguely described product into a clearly defined user experience flow. This will both clarify any functional requirements and set up the framework for the formal technical discussion. Here, let’s assume the agreed upon user flows are the following.

[W] Shortening URL Flow

1. The user client send the original URL to our service. For example,

   https://lucid.app/lucidchart/24a2a903-a2ce-4689-a326-754f49024f94/edit?invitationId=inv_1909caf5-437a-4b9f-a0db-1b797eaedad2&page=0_0#

2. Our service short the URL and store the result in DB.

   • The result URLs are in the format of https://short.ed/[hash]. “hash” is a six character string consists of [a-zA-Z0-9]. (The encoding length and character choice – how many distinct URLs can this schema store and so on – makes a boring topic for staff-plus level interviews, so I won’t bring it up voluntarily.)
   • The short URL must be unique by every user ID and original URL combination. That means if two users short the same URL, they must get two different short URLs.

3. The user client receive the short URL of the above result. For example: https://short.ed/Jke83A

[R] Redirecting URL Flow

1. The user client send the short URL to our service. For example, https://short.ed/Jke83A.
2. Our backend service look up the hash (Jke83A) from DB and fetched the original URL.
3. The client received the original URL and was redirected accordingly.

Applicant Step 2: Identify the hard questions

Here comes the second challenge which is a strong indicator of the interview result: To identify the hard questions which is the real meat of the interview. This naturally follows the user flow specification step and further defines the focus for the rest of the interaction between the applicant and her interviewer.

Below are the hard questions I would bring out in an interview.

• Collision Prevention: With multiple servers for [W], how to avoid encoding collisions from different servers? For example, when two servers both use 4bSPl2X for two different input URLs.
• Database Sharding: When the URL shortening result becomes too large to be stored in one machine, how to shard the DB?
• Scaling Reads: How to scale [R] for both concurrent request volume and speed?