# System design: working checklist

Companion to https://lunaprompts.com/blog/system-design-assessment-guide

LunaPrompts Editorial. Original illustrative exercise.

## Define the workflow

- Role or campaign:
- Owner:
- Decision this workflow should support:
- Candidate instructions and support route:

## Worked example: Design a document assistant with access boundaries

Ask the candidate to design an internal document assistant. Supply the basic workflow: an employee asks a question, relevant documents are retrieved, and the answer cites supporting material. Let the candidate clarify the users, freshness needs, and expected scale.

Then introduce a constraint: some documents are restricted to one department. Ask the candidate to trace an unauthorized request through the design. At what point does identity become a permission decision? Can restricted content enter a model prompt, a shared cache, or an answer log? These questions examine the proposed boundaries without requiring one specific architecture.

A useful answer describes where access is enforced and how the team would test it. Request a concrete negative example: a user outside the department asks a question whose answer appears only in a restricted document. The system’s expected behavior should be explicit.

Evaluate the reasoning against the role. A candidate might propose a simpler architecture with clear boundaries, or a more involved design justified by the requirements. Ask what would make them change that choice. Do not award points just for adding services, or deduct them because the diagram differs from the interviewer’s preferred stack.

## Review checklist

- [ ] Requirements: Clarifies users, constraints, and assumptions
  Evidence or open question:
- [ ] Flow: Explains where information moves
  Evidence or open question:
- [ ] Boundaries: Identifies access and failure behavior
  Evidence or open question:
- [ ] Tradeoffs: Connects complexity to a requirement
  Evidence or open question:

## Working session

Take a sample system diagram and introduce one access, failure, or growth constraint. Write how a reviewer would recognize a well-reasoned adaptation.

## Avoid this mistake

A familiar architecture is not a rubric. Define the behavior you need to evaluate before choosing the example solution.

## Record the next step

- Observed evidence:
- What remains uncertain:
- Person responsible:
- Next action and date:

Keep candidate examples anonymous when sharing this worksheet.
