Skip to article
THE HIRING FIELD GUIDE / 11

The diagram looks complete. Change one requirement.

Evaluate requirements, interfaces, data flow, reliability, and tradeoffs by asking candidates to adapt a design to a realistic constraint.

Explore system design
FIELD GUIDE / 11DESIGN THE ASSESSMENT
System design
01Design

Initial flow: question → retrieval → answer

02Constrain

New requirement: enforce access

03Adapt

Evidence: data flow + boundary checks

Illustrative stock portrait
Architecture interviewerA practical perspective for this guide

Editorial illustration. Stock portrait, not a customer endorsement.

A practical guide for recruiters, talent leaders & engineering managers Get the working checklist
In this guide

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.

The short answer

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

EXAMPLE WORKFLOW / 11
01Design02Constrain03Adapt
Illustrative stock portraitArchitecture interviewerIllustrative scenario01 / 03

Retrieve relevant documents

The first diagram connects a question to search results and an answer.

Initial flow: question → retrieval → answer
A happy-path diagram leaves important behavior unspecified.
Original editorial example. Select a step to pause and explore it. The full scenario is explained below.

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 areaWhat to establish
RequirementsClarifies users, constraints, and assumptions
FlowExplains where information moves
BoundariesIdentifies access and failure behavior
TradeoffsConnects complexity to a requirement
A mistake worth avoiding

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.

Bring this to your next working session.

A focused checklist, a worked scenario, and questions to resolve together.

Download worksheet

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

Explore system design with LunaPrompts or browse all 19 hiring field guides.

KEEP EXPLORINGAll 19 field guides
PUT THE GUIDE TO WORK

Bring the role.
We’ll help you find the signal.

Explore a hiring workflow built around the work your next hire will actually do.

Explore your hiring workflow
Colleagues discussing work around a table; illustrative stock photography