Domain glossary for the SA interview

Why interviewers ask about glossaries

If you have ever sat in a planning meeting where one engineer said order meaning a paid purchase, while a designer said order meaning a pending cart, you already understand what a domain glossary fixes. A glossary is the single source of truth for what words mean inside your product, and for a systems analyst it is one of the highest-leverage artifacts you own. Interviewers at Stripe, Notion, Linear, and DoorDash love this topic because it is a clean proxy for two real skills: negotiating shared meaning with stakeholders, and turning fuzzy business language into something engineers can implement without guessing.

The question usually arrives in three flavors: how do you bootstrap a glossary on a new project, what do you do when two teams use the same term differently, or — the trap version — do we even need a glossary if the team is small. Each variant tests the same thing: do you treat ubiquitous language as a serious deliverable, or as wiki hygiene. The answer that lands describes the glossary as the input to specs, code identifiers, and UI copy, not as a side document.

A senior systems analyst owns the glossary the way a tech lead owns the codebase. Nobody else will do it for you. In the interview, lean into ownership language — "I drive the term review", "I mediate conflicts", "I publish the diff when meaning changes" — rather than passive framing.

What a glossary actually is

A domain glossary is the documented, versioned terminology specific to one product or one bounded context. Each entry pins down a noun (Order, Customer, Reservation), a verb (Cancel, Refund, Settle), or a status (Paid, Disputed, Shipped) so that there is exactly one meaning in scope. It exists for four concrete reasons, and you should be able to cite all four in an interview.

The failure mode is concrete. One person says order meaning an unpaid reservation. Another says order meaning a settled transaction. The spec gets written with both interpretations inside it, an engineer picks one, and the bug shows up six weeks later when finance reconciles revenue. The glossary is the cheap upstream fix for the expensive downstream incident.

Anatomy of a glossary term

A good entry is structured, not prose. Here is the template I use and recommend repeating verbatim if the interviewer asks for it on a whiteboard.

## Order

**Definition:** A financial transaction between a customer and the
company to purchase goods or services. An Order exists only after
payment intent is captured.

**Synonyms:** Purchase order (formal contracts), order (common usage).

**Not to confuse with:**
- Reservation — a hold on a resource without payment intent.
- Subscription — a recurring purchase agreement.
- Cart — pre-checkout state with no commitment.

**Statuses:**
- Pending — created, awaiting payment capture.
- Paid — payment captured successfully.
- Shipped — fulfillment dispatched.
- Delivered — confirmed receipt by customer.
- Cancelled — terminated before delivery.

**Owners:** Sales department, Order Management team.

**Used in:**
- Sales context (primary; full lifecycle).
- Billing context (financial view; ledger entries only).
- Logistics context (shipment view; references OrderId).

**Related:** OrderItem, Customer, Payment, Refund.

Notice the Not to confuse with block. This is the most underused field in real-world glossaries and the one interviewers reward most. Defining a term by its neighbors is more useful than defining it in isolation, because confusion almost always comes from a sibling concept (Cart vs Order vs Reservation), not from the term itself.

The Owners field matters too. Every term needs a name attached, because terms drift, and drift needs an owner to either ratify or reverse. Without a named owner, the term becomes everyone's problem, which is the same as nobody's problem.

Bounded contexts and shared terms

The same word can mean different things in different parts of the system, and that is fine — as long as the glossary names the context. This is Domain-Driven Design 101, and it is the cleanest answer you can give when the interviewer pushes on what if two teams refuse to agree.

Consider Customer:

• In the Sales context, a Customer is a person or company that has placed at least one paid order.
• In the Marketing context, a Customer is anyone in the outreach funnel, including prospects who have never paid.
• In the Support context, a Customer is anyone with an active ticket, regardless of purchase history.

All three are correct. The glossary records all three with the context explicit, and the code uses qualified names — SalesCustomer, MarketingLead, SupportContact — to keep the boundary visible. In DDD vocabulary, this is the difference between shared kernel (terms that mean the same thing everywhere) and context map (terms that translate at the boundary between teams).

Conflict resolution playbook

When two stakeholders disagree on a term, your job as the systems analyst is to be the mediator, not the arbiter. You surface the conflict, map the uses, and let the business owners choose. Then you write down what they chose.

The five-step playbook to recite in an interview:

1. Surface the conflict explicitly. Ask both parties to define the term in their own words. Write both definitions on the same page. Do not paraphrase.
2. Map all current uses. Search Confluence, Jira, the codebase, Slack history. Where does the term appear, who uses it, and what does each occurrence imply?
3. Decide: align or separate. Either the parties converge on a single definition, or you split the term with qualified names (BillingAccount vs LoginAccount). There is no third option.
4. Document the decision. Update the glossary with the new phrasing, the date, the owner, and a one-line rationale ("split per finance audit, 2026-03-12").
5. Communicate the diff. Announce in the relevant team channel. Tag the engineers who use the term in code so they can rename.

The mediator framing matters in interviews. Junior candidates say I would decide which definition is correct. Wrong answer. The business owners decide; the systems analyst makes the decision visible, durable, and propagated.

Tools and where the glossary lives

The tool matters less than the discipline of having a single canonical location. That said, here is what I have seen work in practice across teams I have advised.

The ideal is the IDE hover pattern: an engineer hovers on Order in code and sees the canonical definition, owner, and last-changed date. That eliminates the gap between business definition and code identifier. Few teams achieve it; the ones that do report measurably fewer spec-related bugs.

Whichever tool you pick, the rule is one source, linked from everywhere. If a definition appears in five Confluence pages, four of them are wrong by next Tuesday. Drilling this kind of architectural decision-making is exactly the loop the NAILDD interview prep app was built for — system design and SA scenarios with feedback on the choices you make.

Common pitfalls

The first pitfall is treating the glossary as documentation rather than as a contract. Documentation gets written once and goes stale. A contract gets reviewed when behavior changes. If your Refund entry is not updated when the refund flow changes, you have a museum, not a glossary. The fix: add glossary review to definition-of-done for any spec touching the term.

A second trap is letting the glossary grow without curation. Teams add fifty terms in the first month, then nobody reviews and the list grows to four hundred entries, half from features that shipped and rolled back. The fix is a quarterly cleanup where each owner confirms the term is still in use; stale entries are archived, not deleted, so old tickets still resolve.

A third pitfall — common in interviews — is conflating glossary with data dictionary. A data dictionary describes database columns (orders.created_at is a UTC timestamp). A glossary describes business concepts (an Order is a captured payment intent). They are related but distinct, and a senior analyst knows which to point a stakeholder at. Keep them linked but separate: the glossary entry for Order links to the data dictionary entries for the underlying tables.

A fourth issue is assuming the glossary applies organization-wide when it applies to a bounded context. The Customer in billing is not the Customer in CRM. A senior candidate names the context every time. This is the failure mode that turns a six-month integration project into an eighteen-month one.

A fifth pitfall is the owner who never says no. Every team has someone who accepts every new term to be polite, and the glossary bloats. A good owner pushes back, asks is this a new concept or a synonym, and merges aggressively.

Related reading

• Domain-driven design for the SA interview
• Domain events for systems analysts
• Acceptance criteria with Given-When-Then
• Soft skills for the systems analyst interview

FAQ

How long does a glossary live?

A glossary lives as long as the product lives. It is not a one-time deliverable that you ship and forget. Expect to update entries whenever you onboard a new business partner, launch in a new market, or change a core workflow. Most healthy glossaries see five to ten edits per month on an active product. If your glossary has not changed in six months, it is almost certainly drifting from reality, and the next planning cycle will surface the gap painfully.

Is the glossary the same as a data dictionary?

No, and conflating the two is a common interview mistake. A glossary defines business concepts in plain language — what an Order is, what a Refund is, what the rules are for becoming a Customer. A data dictionary defines the technical schema — column types, nullability, foreign key relationships. They should link to each other, but they serve different audiences. Product managers and stakeholders read the glossary; engineers and analysts also read the data dictionary.

Who should own the glossary in a small team?

In a team under ten people, the systems analyst or product manager owns it directly. As the team grows past twenty, the model usually splits — a central editor owns the structure and review cadence, while domain experts own individual entries. The anti-pattern is having no named owner; that is when the glossary becomes a graveyard. Even a junior analyst can own the glossary effectively if they treat it as a primary deliverable rather than a side task.

How do I introduce a glossary to a team that does not have one?

Start small. Pick the five to ten terms that cause the most weekly arguments and define those. Publish them in your team's existing wiki. Reference them in your next three specs. Within a quarter, the team will ask for more entries on their own because they will have felt the productivity gain. Trying to ship a hundred terms on day one is the fastest way to ensure nobody reads any of them.

Should glossary terms match code identifiers exactly?

Yes, this is the goal, and it is what ubiquitous language means in practice. If the glossary says Order, the database table should be orders, the class should be Order, and the UI label should say Order. Drift between these layers is where bugs hide. Some teams enforce this with a linter flagging PRs that introduce identifiers not present in the glossary — heavy-handed but effective at scale.

Is this an official standard, or your opinion?

The structural ideas (ubiquitous language, bounded contexts) come from the BABOK Guide and Eric Evans' Domain-Driven Design, both well-established references in the systems analysis discipline. The specific templates and pitfalls above reflect patterns observed across product teams in B2B SaaS and consumer apps. Treat it as a strong default rather than a single authoritative spec; adapt to your team's scale and tooling.