The diagram has an API, a queue, a database, and a cache. The candidate knows the vocabulary. Your team still needs to know whether the system satisfies the requirement that was easy to overlook.
System design becomes revealing when the conversation moves from naming components to explaining behavior. A carefully chosen change makes those decisions visible.
LunaPrompts system design assessments help hiring teams evaluate how candidates turn requirements into an architecture. Explore components, data flow, interfaces, reliability, and the tradeoffs behind the proposed system.
Design a document assistant with access boundaries
Architecture interviewerIllustrative scenario01 / 03Retrieve relevant documents
The first diagram connects a question to search results and an answer.
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.
Start with a problem the role could encounter
Choose a scenario that gives the candidate room to ask useful questions. Establish the users, the core workflow, the important constraints, and the level of detail expected.
For an early-career role, the task might focus on a small service and its data model. For a senior role, it could explore operational failure, growth, migrations, or coordination between services. The assessment should reveal judgment at the intended level.
What to evaluate
Requirements and assumptions
Does the candidate clarify ambiguous requirements? Do they separate essential behavior from optional features? Can they explain the assumptions their design depends on?
Components and interfaces
Look for clear responsibilities and understandable boundaries. The candidate should be able to describe how information moves through the system and why each major component exists.
Data and consistency
Explore storage choices, relationships, state changes, and consistency needs. Ask what happens when requests arrive twice, data changes during an operation, or a write succeeds in one place but fails in another.
Reliability and operations
Ask how the system behaves when a dependency is slow or unavailable. Review retry behavior, observability, recovery, and how the team would discover a production problem.
Cost and complexity
Good design includes deciding what the system does not need yet. Ask the candidate to explain the cost of their choices and when a simpler approach would be adequate.
Connect design skill to AI-assisted implementation
A candidate who can define interfaces, constraints, and acceptance criteria can give a coding agent a clearer assignment. They can also identify when generated code violates the intended design.
Use that relationship in the assessment. Ask how the candidate would break the system into implementation tasks and what they would verify before accepting the generated work. This connects architectural reasoning to practical engineering ownership.
A review framework your team can use
The following is an editorial checklist for this workflow. Adapt it to the role, the candidate journey, and your configured environment.
| Review area | What to establish |
|---|---|
| Requirements | Clarifies users, constraints, and assumptions |
| Flow | Explains where information moves |
| Boundaries | Identifies access and failure behavior |
| Tradeoffs | Connects complexity to a requirement |
A familiar architecture is not a rubric. Define the behavior you need to evaluate before choosing the example solution.
Put the guide to work
Take a sample system diagram and introduce one access, failure, or growth constraint. Write how a reviewer would recognize a well-reasoned adaptation.
Download the editable worksheet to record the decisions and open questions with your team. The examples in this guide are illustrative, not customer results or validated selection rules. Product availability and setup depend on the workflow agreed for your account.
A focused checklist, a worked scenario, and questions to resolve together.
Frequently asked questions
Is system design only for senior engineers?
No. The scope should match the role. A junior candidate can explain a small service and its data flow, while a senior candidate can be assessed on broader tradeoffs and operational concerns.
Should every candidate produce the same architecture?
No. Different designs can satisfy the same requirements. Review the reasoning, constraints, and consequences rather than treating one diagram as the only acceptable answer.
How can we distinguish experience from memorized patterns?
Change a requirement and ask the candidate to adapt the design. Specific explanations about the effects of the change provide stronger evidence than a list of familiar technologies.
Keep building your hiring workflow
- AI skills: The answer looks right. Can your candidate explain why?
- AI Viva: They have the answer. Ask what would change it.
- Coding assessments: The code passes the example. What happens on the second event?
Explore system design with LunaPrompts or browse all 19 hiring field guides.
