Section 1: One Word, Three Products - Problem Understanding & Clarifications

Executive Summary: This section covers the first ten minutes of the interview. The obvious answer to the prompt, a many-to-many join table, is correct and nearly irrelevant. Breaking the prompt down shows the real shape: the tagging service owns the tags but not the content and not the permissions. Six clarifying questions settle scope, tenancy, vocabulary, visibility, counts and freshness, and one of them, "should clicking a tag show me items I can't see?", changes the design more than the other five together. We meet Dana, whose checkout-outage tag we'll follow through every section.

The interviewer reads from a card:

"We run a suite of work tools: an issue tracker like Jira, a wiki like Confluence, and code review like Bitbucket pull requests. Think Azure DevOps work items, tasks and bugs if that's your world. We want one tagging service shared by all of them. Anyone can add tags to an issue, a page or a pull request, click a tag to see everything carrying it across every product, and get suggestions as they type. Design it."

Most candidates feel relief. Tags are a tag table, a content table and a join table, the first many-to-many relation anyone learns. A minute later the whiteboard has three boxes and fifty-nine minutes left to fill.

That table is right, and you'll build it in Section 5. It's also the easy part. The harder problem hides in three words: "click a tag."

Key Insight: The join table answers "which items carry this tag?" The tag page must answer "which items carry this tag and may this person see?" Those answers differ for almost every user, and the data that decides the difference lives in three other systems.

Decomposing the Prompt

Break it down out loud before asking anything.

• What it does: Tag an item, browse by tag across products, suggest tags while someone types. A tag is a user-applied label scoped to one customer: a folksonomy, where people invent words as they go, not a curated taxonomy.
• Who uses it: Everyone in a customer organization, through the product UIs. The less obvious callers are the product backends: every issue view, board card, wiki page and pull request renders its tags, so products call this service far more often than people do. Admins will want to rename, merge and delete.
• Why it exists: Work cuts across tools. An incident lives in a bug, a postmortem and a fix at once. Jira and Confluence have "labels" and Azure DevOps work items have "tags", but each product's labels see only that product. The ask is one vocabulary and one page that joins the pieces.
• How it's used: Tags are read on nearly every page render, written in bursts, and browsed by clicking, which is rare but expensive. Section 3 puts numbers on each.