How to assess · For hiring teams
How to Assess System Design Skills When Hiring
The test formats that actually work for System Design, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.
The short answer
Assess System Design with a task, not a conversation: bounded design problem with constraints, design review of an existing system, ai-scored assessment (e.g. cohesyve) or written design document. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.
- Establishes requirements and constraints before drawing anything: scale, latency, consistency, budget, team
- Starts with the simplest design that meets them and adds components only when a requirement demands it
- Reasons about data first — shape, access patterns, growth — and chooses storage from that
- Names the failure modes of their own design and what mitigates each
Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.
System design is the skill that decides whether a senior hire makes the codebase better or bigger. It is not knowing the names of components; it is knowing which ones the problem actually needs, what breaks first, and what the team can operate. Most system design interviews reward people who have practised system design interviews. A good assessment instead gives a candidate a real, bounded problem with constraints, and listens for the trade-offs. This page covers how to assess system design for senior engineers and architects: requirements, data, scale, failure, and the discipline to keep things simple.
Why System Design is worth testing
Poor design judgement compounds. An over-engineered system — five services where one would do, a queue nobody needed, a database chosen for a talk someone saw — costs the team every day it exists. An under-designed one falls over at the first real load. Testing reveals whether a candidate sizes the solution to the problem, names failure modes before they happen, and can explain choices to people who will maintain them.
What strong System Design looks like
- Establishes requirements and constraints before drawing anything: scale, latency, consistency, budget, team
- Starts with the simplest design that meets them and adds components only when a requirement demands it
- Reasons about data first — shape, access patterns, growth — and chooses storage from that
- Names the failure modes of their own design and what mitigates each
- Distinguishes what must be consistent from what can be eventual, and designs accordingly
- Estimates: rough numbers for throughput, storage and cost, with the assumptions stated
- Considers the team that will run it: observability, deployment, on-call burden
Ways to assess System Design
Bounded design problem with constraints
Pose a problem from your own domain — a notification system, an ingestion pipeline, a booking flow — with explicit numbers and constraints. Forty-five to sixty minutes, whiteboard or document. Ask for the simplest design that works, then push on scale and failure.
Pros
Cons
Best for Senior engineers, tech leads and architects.
Design review of an existing system
Provide a diagram and short description of a real system with problems — a single point of failure, a hot partition, a synchronous call to a slow dependency. Ask what they would change first and why.
Pros
Cons
Best for Roles that inherit and evolve systems.
AI-scored assessment (e.g. Cohesyve)
Generate a design problem from the job description with constraints and a rubric. Each candidate receives a different problem; the written design and trade-off reasoning are scored.
Pros
Cons
Best for Screening senior applicants before panel interviews.
Written design document
Ask for a two-page design doc for a described feature, in the format your team uses, as a capped take-home.
Pros
Cons
Best for Staff and principal roles where written design is central.
Cohesyve
Run a System Design assessment on your next opening
Cohesyve generates a unique System Design task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.
What to test
Requirements and scoping
Whether they build the right thing at the right size.
Data and storage
Whether storage follows from access patterns.
Scale and performance
Whether they know where the bottleneck is and what to do about it.
Failure and operations
Whether the system degrades rather than collapses.
Sample System Design questions
Design a service that sends order confirmation emails. Start simple.
MidLook for Asks about volume and reliability; a queue only if the numbers need it; idempotency so a retry does not send twice.
Where would you put a cache in this design, and what goes wrong?
MidLook for Names what is read-heavy, chooses a location, and addresses invalidation and stale reads honestly.
This design has a single database. What is your plan when it becomes the bottleneck?
SeniorLook for Read replicas, then caching, then partitioning by a sensible key — in that order, with the costs of each.
Two services need to agree on an update. How do you handle it?
SeniorLook for Whether it truly needs atomicity; sagas or outbox patterns over distributed transactions; what the user sees during inconsistency.
What would you cut from this design if the team were three people?
SeniorLook for Collapses services, removes infrastructure, prefers managed services, and can say what capability is lost.
Red flags
- Draws microservices, queues and caches before asking about scale
- Cannot estimate any number about the system
- Has no answer for what fails first
- Chooses technology by familiarity rather than by requirement
- Ignores the people who will operate the system
Scoring rubric
| Criterion | Weight | What strong looks like |
|---|---|---|
| Requirements and simplicity | 30% | The design is as small as the constraints allow, and every component has a reason. |
| Data and storage judgement | 20% | Storage follows from access patterns and growth. |
| Scale reasoning | 20% | Bottlenecks are identified in order, with numbers. |
| Failure handling | 20% | Failure modes are named and mitigated; degradation is designed. |
| Communication | 10% | The design could be reviewed and built by someone else. |
Mistakes hiring teams make
- Using a generic "design Twitter" prompt that rewards rehearsal
- Rewarding component count over fit to the problem
- Not pushing on failure modes because the happy-path design looked good
- Letting the interviewer's preferred architecture become the rubric
- Skipping estimation — it is the fastest test of whether they understand scale
Roles that need System Design
Common questions
Should mid-level engineers do a system design assessment?
A lighter one, yes. Designing a small service with a database and a queue, and naming what fails first, is a fair expectation at mid level. Full-scale distributed design is a senior test.
How do I stop candidates reciting a memorised architecture?
Use a problem from your own domain with specific numbers and constraints, and start with "what is the simplest thing that meets these". Rehearsed answers fall apart when the constraints do not match the template.
How long should a system design assessment take?
Forty-five to sixty minutes live is standard. A written design document as a take-home should be capped at two to three hours and kept to two pages.
What is the most telling system design question?
"What would you remove?" Strong candidates can simplify their own design and say what is lost. Weak ones only know how to add.
Cohesyve · Skill assessments for hiring
Test System Design before the first interview
Generate a role-specific System Design assessment from your job description and see who can do the work before you spend interview time on them.
1,500+
assessments completed
50%
faster time-to-hire
90%
completion rate
5 min
from JD to assessment
No credit card · 10 free candidates · Plans sized to your hiring volume
From the blog