How You Are Levelled and Evaluated
What actually gets written on the feedback form. The behaviours that map to each level, the rubric dimensions, and how to signal the level you are targeting.
Covers: Junior vs senior vs staff expectations, the rubric interviewers use, common failure patterns, the last five minutes
Two candidates can give the same architecture and be levelled differently. The difference is not the diagram - it is the depth of justification, the failure analysis, and whether they drove the conversation. This lesson describes what interviewers are actually scoring, so you can aim deliberately.
30-second answer
Mid-level produces a working design using standard components with reasonable reasoning, and needs prompting for scale and failure. Senior gets there faster, justifies every component against a requirement, proactively identifies bottlenecks and failure modes, and quantifies with back-of-envelope arithmetic. Staff does all that and adds: explicit consideration of what not to build, operational and cost reality, migration paths from the current state, and organisational implications such as which team owns which service. The differentiator is not knowing more components - it is depth of justification and breadth of concern.
| Dimension | Mid-level | Senior | Staff+ |
|---|---|---|---|
| Requirements | Asks a few questions when prompted | Drives scoping; converts vagueness into numbers | Challenges the premise; surfaces requirements nobody stated |
| Design | Works, uses standard components | Works, and every component is justified | Works, and the simplest version that works is chosen deliberately |
| Estimation | Can do it when asked | Does it unprompted and uses the result | Uses it to rule out designs before drawing them |
| Depth | One layer on request | Two layers unprompted | Knows the failure modes of the specific technology named |
| Failure | Mentions redundancy | Analyses each component's failure and recovery | Considers correlated failure, blast radius and recovery-induced failure |
| Trade-offs | Picks reasonable options | Names alternatives and the deciding condition | Quantifies the trade in latency, cost or engineering time |
| Operations | Rarely mentioned | Monitoring and alerting discussed | Cost, on-call burden, migration path, team ownership |
| Communication | Answers questions well | Drives the conversation; manages time | Collaborates as a peer; adjusts to the interviewer's interests |
The rubric dimensions
- Problem solving - did they scope well and reach a working design?
- Technical depth - do they understand the components, or only their names?
- Trade-off reasoning - did they recognise choices and defend them?
- Scalability thinking - does the design survive 10×, and do they know what breaks first?
- Reliability thinking - did they consider failure without being asked?
- Communication - could a colleague follow and build this?
The last five minutes
Summarise the design in three sentences
“Requests hit the CDN, then a stateless API tier, reads served from Redis with Postgres behind it, writes going to the primary with async fan-out through Kafka.” Shows you can compress, which is a leadership skill.Name the central trade-off you chose
“The core decision was accepting a few hundred milliseconds of staleness on the feed in exchange for the read path never touching the primary.”State what you would do next with more time
“With more time I'd work through multi-region failover and the cost model.” This turns an incomplete area into evidence of awareness rather than a gap.Ask one good question
“How does your team handle schema migrations on the largest tables?” - a real engineering question shows genuine interest and gives you information you actually want.
Say these points
- Depth of justification and breadth of concern separate the levels, not component knowledge.
- Senior: unprompted estimation, failure analysis and named alternatives.
- Staff: what not to build, cost, migration path, team ownership.
- Most negative feedback is about process, not knowledge.
- Close with a three-sentence summary, the central trade-off, and one good question.
Avoid these mistakes
- Waiting to be asked about scale and failure.
- Repeating the same altitude when pushed for depth.
- Never mentioning cost or operations.
- Letting the interviewer drive the whole session.
Expect these follow-ups
- How do you show staff-level thinking on a deliberately small problem?
- What do you do if the interviewer disagrees with a decision you are confident about?
- How do you recover an interview that went badly in the first fifteen minutes?
Showing 1 of 1 questions for system-design-interview-levels-and-evaluation.
Check your understanding
3 questions · no sign-up, nothing stored
Hands-on challenge
Build it - this is what you talk about in a deep-dive round.
Self-assess a recorded mock
Run a 45-minute mock on any prompt, record it, and grade yourself against the rubric in this lesson.
Requirements
- Record audio and photograph the final diagram.
- Score yourself 1–4 on each of the six rubric dimensions with a written justification.
- Timestamp the moment your complete high-level design existed, and compare against the 20-minute target.
- Count how many decisions you justified with a named alternative and a deciding condition.
- List every failure mode you raised unprompted, and every one you missed.
Stretch goals
- Redo the same prompt a week later and compare scores dimension by dimension.
- Have someone else grade the recording and reconcile the differences.