Build an internal go-link URL shortener with an AI assistant: CRUD, sessions, ownership, analytics

Build an internal "go-link" tool: a URL shortener for one organization, where a short link such as `go.internal/ifd` redirects to a long URL, for example a team's Notion page. The tool serves about 100 users, so scale and distributed-systems concerns are out of scope, and in-memory storage (a string-to-string map) is acceptable. The namespace is global: any user can visit any short link. The round is 60 minutes of working code in an online IDE with a built-in AI coding assistant. The interviewer evaluates how you scope the work, direct the assistant, and verify what it produces, not whether you type every line yourself. ### Constraints and Clarifications - In-memory storage is fine; links do not need to survive a restart. - About 100 users: no sharding, caching tier or replication is expected. - The result should run, and you should be able to show each feature working end to end. - Time is tight, especially in Part 2, so decide early what to build, what to test, and what to skip. ### Clarifying Questions - Does the user choose the short name (`ifd`), or should the tool generate one? What happens when someone creates a name that already exists? - Which characters are allowed in a short name, and are names case-sensitive? - What should a visit to an unknown short link return? - Is there a required language or framework? - How are users provisioned for the login in Part 2: a fixed list of accounts, self-registration, or a stub for single sign-on? ### Part 1 — Core create and visit API Implement creating a short link (a mapping from a short name to a long URL) and visiting a short link, which redirects the browser to its long URL. Also support deleting a link, which Part 2 builds on. Show that create, visit and delete work end to end. ```hint Decide before you generate Write down the endpoints, their status codes, and the behavior for a duplicate or unknown name before asking the assistant for code, so you have something to check its output against. ``` ```hint Small enough to read Ask for pieces small enough that you can read every generated line in the time you have. A large scaffold costs review time you will want in Part 2. ``` #### What This Part Should Cover - An API for create, visit (redirect) and delete with explicit status codes - Validation of short names and long URLs, and a policy for duplicate names - A working end-to-end demonstration and a few tests that pin the rules - A plan given to the assistant before code generation, and visible review of what it produced ### Part 2 — Authentication, ownership and analytics Extend the tool: - Add a login and session flow. Unauthenticated users cannot create links. - Track link ownership: anyone can view all links, but users can delete only their own. - Analytics: the most-visited links, the number of links per user, and who created each link. ```hint Where the user comes from Decide where the server learns who is making a request, and make sure the client cannot simply claim to be someone else. ``` ```hint Three rules, one place each Sort the operations into open to everyone, logged-in only, and owner only, and enforce each rule in exactly one place. ``` ```hint Record it on the way through Decide what a visit and a creation must record so that all three analytics questions can be answered from data you already keep. ``` #### Clarifying Questions for this Part - Does visiting a link or listing links require a login, or only creating and deleting? - Do visits by people who are not logged in count toward analytics? - For "most-visited": how many links, and over all time or a recent window? - When a link is deleted, should its visits still appear in analytics? #### What This Part Should Cover - A session mechanism: credential check, session token, expiry and logout - Server-side authorization: not logged in versus not the owner, with the matching status codes - Data kept per link and per visit that answers all three analytics questions - Prioritization under time pressure, including which tests are worth keeping when time runs short ### What a Strong Answer Covers - Scope set before code: a short plan of endpoints, rules and data model that the assistant works from - Every generated piece read, run and checked against the plan, with tests on the rules that matter (duplicates, login, ownership) - A design proportional to about 100 users, without layers that add nothing - Correct HTTP semantics for redirects, missing links, unauthenticated requests and forbidden requests - Shared in-memory state that stays correct when requests run concurrently - Time management that delivers a working Part 2 rather than a polished Part 1 ### Follow-up Questions - Two users try to create the same short name at the same moment. What does your code do, and how would you show it? - The assistant generated a delete handler that takes the requesting user's name from a request header. What is wrong with it, and how would you catch it in review? - Should a visit return a permanent or a temporary redirect, and how does the choice affect analytics and later edits to a link? - What is the smallest change that makes links survive a restart, and what else would have to change?