Architecture round evaluation is hard not because there are too many details, but because strong candidates rarely look like a checklist of perfect answers.
This chapter shows how the final decision is assembled from multiple observations: whether the candidate clarifies the task well, keeps structure, explains choices clearly, and stays independent as the interviewer changes the depth of the conversation.
That is useful for both interviewers and candidates because it makes strong evidence easier to recognize and shows why one good moment cannot substitute for an overall strong discussion.
Practical value of this chapter
Scoring Criteria
Know what is assessed stage by stage: requirements, structure, technical depth, and clarity of explanation.
Mock Debrief
After each mock, review requirements, architecture, depth, and communication separately instead of relying on one overall impression.
Level Calibration
Choose practice problems for the role you target so you train the right degree of autonomy instead of random difficulty extremes.
Growth Signals
Track where the next level already shows up: systems thinking, prioritization, broader perspective, and confident interview steering.
Preparing blind is expensive: you can sink weeks into topics the interviewer barely reads. So start from how a system design interview is actually scored. A good result rarely rests on one brilliant idea. It is a sequence of observations about how you clarify the task, keep structure, justify decisions, and hold the line when the conversation gets harder.
This chapter documents Alexander Polomodov's approach to evaluating architecture interviews, used at T-Bank. It is connected to the seven-step system design interview process: the process defines the conversation flow, while this evaluation frame explains which signals the interviewer reads at each stage.
Evaluation as observable signals
A strong score accumulates over the conversation. The interviewer looks for durable reasoning, not one lucky decision.
Structure
The candidate keeps order: requirements, boundaries, flows, data, and scaling.
conversation is managed
Depth
They go deep where it affects the design rather than in random places.
technical base is visible
Autonomy
The higher the level, the fewer guiding questions should be needed.
level becomes visible
Communication
Decisions are explained concisely, testably, and with clear consequences.
why this choice is clear
How to use it
After each mock, review separate signals: structure, depth, autonomy, and clarity, not only the final diagram.
Evaluation criteria by interview stage
Each stage gives its own kind of signal: requirement clarification, boundary setting, component reasoning, scaling judgment, and communication clarity. What follows is a map of what reads as a strong answer at each one, and what reads as a weak one.
Requirement clarification
A vague prompt has to become a concrete working problem with agreed expectations first — otherwise the whole design runs on silent assumptions that get reworked later.
Strong
- Asks clarifying questions before designing
- Separates functional and non-functional requirements
- Clarifies priorities and system boundaries
Weak
- Jumps straight to a solution
- Makes major assumptions silently
- Never defines what is inside or outside the problem
System boundaries and public API
Next comes how the system looks from the outside: what clients call, which contracts must be preserved, and where the cost of a mistake is broken backward compatibility for clients that already depend on it.
Strong
- Defines external interfaces clearly
- Thinks through request and response shapes
- Accounts for API evolution and compatibility
Weak
- Never defines the external contract
- Mixes user-facing APIs with internal service calls
- Ignores the impact of changes on existing clients
Core flows and components
The interviewer checks whether the candidate sees how the write path and the read path are built, where asynchronous steps appear, and which nodes are genuinely critical — the ones where the first failure becomes a user incident.
Strong
- Separates write, read, and background flows
- Makes synchronous vs asynchronous steps explicit
- Marks important failures, retries, and queues
Weak
- Collapses all flows into one blurry diagram
- Misses queues, async work, or retry logic
- Never points out where the design can fail
Conceptual and physical data model
Order matters more than the technology here: a strong candidate starts from entities and relationships, then picks storage and schema to fit real access patterns — not the other way around.
Strong
- Starts from entities, relationships, and keys
- Chooses storage based on access patterns
- Considers indexes, denormalization, and data lifetime
Weak
- Picks a favorite database first and reasons later
- Ignores real read and write patterns
- Treats the data model as an afterthought
System scaling
Scaling quickly exposes whether the candidate thinks in slogans or in consequences: can they explain trade-offs, know when sharding is actually justified, find real bottlenecks, and keep consistency expectations in mind.
Strong
- Distinguishes vertical and horizontal scaling
- Explains where sharding or caching actually helps
- Connects scaling to latency, cost, and data consistency
Weak
- Defaults to “just add more servers”
- Misses stateful components and real growth limits
- Never explains the cost of the chosen scaling strategy
Diagram readability and clarity
Even a strong idea loses value if the interviewer cannot quickly understand what is on the board. An unreadable diagram is a lost signal: what gets scored is not the design on its own, but how clearly the candidate shows it.
Strong
- Draws neat, readable diagrams
- Groups components and boundaries logically
- Labels important nodes and data movement clearly
Weak
- Leaves a chaotic sketch without clear boundaries
- Fails to label key components
- Never explains how the parts connect
How interviewers distinguish levels
The final score reflects more than raw knowledge. It reflects the level of autonomy an interviewer would expect on the job. The same answer may be acceptable for a Middle candidate and too narrow for a Senior one if it lacks initiative or range.
Junior
The candidate can reliably handle only the happy path and depends heavily on interviewer guidance to keep moving.
Typical signs
- Understands the basic logic of the solution
- Needs leading questions to make progress
- Rarely spots edge cases independently
- Shows limited awareness of scaling and operations
Middle
The candidate designs meaningful parts of the system alone and sustains a useful discussion without constant steering.
Typical signs
- Can drive a meaningful part of the discussion alone
- Catches the main edge cases
- Can justify component and storage choices
- Sees the main scaling constraints
Senior
The candidate leads the full conversation end to end: keeps priorities visible and justifies engineering choices without external control.
Typical signs
- Structures the whole round independently
- Anticipates risks and proposes mitigations
- Explains trade-offs with confidence
- Accounts for operations, not just design-time concerns
Senior+ / Staff
The candidate moves beyond a local solution and thinks in terms of long-term system evolution, organizational boundaries, and product-level consequences.
Typical signs
- Designs with long-term evolution in mind
- Connects technical choices to business context
- Accounts for security, compliance, and team boundaries
- Shows how the design will live after launch
How interviewers calibrate difficulty
Architecture rounds usually begin with a high bar and a lot of freedom. Follow-up questions, hints, and changes in pacing are not random help. They are part of the calibration process that helps the interviewer locate the candidate’s real level.
Start
Senior bar
Maximum autonomy
If difficulties appear
Middle bar
More guiding questions
If the candidate gets stuck
Junior bar
More explicit prompts
What raises the score
- Driving the conversation forward without waiting to be led
- Raising important risks, constraints, and edge cases proactively
- Explaining the consequences of choices without being pulled there
- Offering reasonable alternatives and comparing them clearly
What lowers the score
- Waiting for hints at every next step
- Failing to justify important design choices
- Getting stuck on one slice of the problem and losing the whole flow
- Ignoring signals about where the discussion needs to move next
Key takeaways
The round starts with a high bar — candidates are given room to show autonomy before any help appears.
Hints are part of the score — they are not rescue; they help the interviewer locate the real level of the answer.
Proactivity matters more than polish — strong candidates surface risks, priorities, and alternatives on their own.
Explaining trade-offs matters more than memorizing answers — interviewers score engineering judgment, not compliance with one template.
Related chapters
- Hiring Goals and Candidate Search in Companies of Different Sizes - explains the business logic of hiring and why companies work so hard to avoid expensive hiring mistakes.
- Big Tech Hiring Stages from the Candidate's Perspective - shows where the architecture round affects final decisions and offer approval.
- Why system design interviews matter in this process - clarifies which maturity signals design rounds provide and why companies calibrate their difficulty.
- System Design Interview Frameworks - provides the baseline answer structure interviewers later use to assess completeness, prioritization, and clarity.
- System Design Interviews: A 7-Step Approach - shows the seven-step interview process this T-Bank evaluation approach is connected to.
- System Types in System Design Interviews - shows how evaluation criteria shift across backend, frontend, mobile, data, and ML interview tracks.
- Troubleshooting Interviews - adds an alternative evaluation format for SRE and operations-heavy roles through incident scenarios.
- Short-Term Preparation for System Design Interviews - helps align final-stage preparation with real interviewer expectations instead of generic advice.