What interviewers evaluate (SDE-1 to Staff)
In one line
A design round is scored on a few signals: problem framing, sound building blocks, depth, trade-off reasoning and communication; the bar on each rises with the level you are interviewing for.
What it is
Interviewers do not grade the final diagram. They fill in a scorecard with a handful of signals and a level recommendation. Most companies use some version of the same five: (1) problem exploration, meaning you turned a vague prompt into clear requirements; (2) a working high-level design built from sensible components; (3) technical depth in at least one hard area; (4) trade-offs, meaning you compared options and justified choices with numbers; (5) communication, meaning you led a clear conversation and used hints well.
The same question is used at different levels. 'Design a URL shortener' can be an SDE-1 question or a Staff question. What changes is how much you drive, how deep you go, and whether you think about operations, failure, cost, team boundaries and how the system evolves.
In India, product companies such as Flipkart, Swiggy, Razorpay and PhonePe use titles SDE-1, SDE-2, SDE-3 and Staff or Principal. FAANG uses its own ladders (for example Google L3 to L6, Amazon SDE I to SDE III and Principal, Meta E3 to E6), but the expectations map roughly to the same four bands described in this lesson.
Why interviewers ask
The design round often decides the level of the offer, not just yes or no. A candidate who solves the problem but needed the interviewer to drive every step is frequently down-levelled, for example offered SDE-2 instead of SDE-3. Knowing what is being scored lets you spend your 45 minutes on the signals that count instead of on details nobody grades.
How it works
- 1SDE-1 (0 to 2 years): you are often not given a full design round; when you are, the bar is a working design. Know the basic blocks (load balancer, cache, SQL vs NoSQL, queue), make a reasonable API and schema, and respond well to hints. The interviewer can lead.
- 2SDE-2 (2 to 5 years): you should drive the structure yourself, produce a complete end-to-end design, do simple estimates, and go deep on one component, such as the cache strategy or the database schema and indexes. Trade-offs should be named, not just choices.
- 3SDE-3 or Senior (5 to 8 years): you own the conversation. You find the real bottleneck from the numbers, go deep on two hard parts (consistency, hot keys, fan-out, idempotency), discuss failure modes and what breaks at 10x, and talk about observability and rollout.
- 4Staff and above: everything above, plus breadth and judgement. You question the requirements themselves, consider cost, multi-region, data ownership between teams, migration from the current system, and how the design evolves over two to three years. You simplify where others add boxes.
- 5Across all levels interviewers look for the same red flags: no clarifying questions, buzzwords without reasons, ignoring the stated numbers, no awareness of failure, and arguing with hints instead of using them.
- 6After the round, the interviewer writes evidence for each signal (what you said, not general impressions) and a hire or no-hire with a level. A hiring committee or debrief compares rounds, so one strong, clearly documented signal matters more than many shallow ones.
Worked example · The same prompt, 'Design a notification service', at three levels
- SDE-1 answer: API to send a notification, a queue, workers that call FCM, APNs, an SMS gateway and an email provider, a table for user preferences. The candidate explains why a queue is used. That is a pass.
- SDE-2 answer: adds estimates (50M users, 5 notifications per user per day = 250M a day, about 2,900 per second average and maybe 15,000 per second at peak), separate queues per channel so slow SMS does not block push, retries with backoff, and a deduplication key so a retry does not send twice.
- SDE-3 answer: notices that a marketing blast to 50M users at once is the real peak, adds rate limiting per provider and per user (quiet hours, frequency caps), priority lanes so an OTP is never stuck behind a campaign, delivery status tracking, and what happens when the SMS vendor is down (fallback vendor, circuit breaker).
- Staff answer: all of the above, and also asks who owns templates and consent (marketing vs product teams), estimates SMS cost per month (250M SMS at even Rs 0.15 each is a large bill, so prefer push and in-app), covers DLT template registration for SMS in India, and proposes a phased rollout from the current system.
Picture it
It is like a driving test with different licences. Everyone is checked on steering, braking and signals, but a car licence needs a clean drive around town, while a bus licence also checks that you plan the route, think about passengers and handle a breakdown calmly.
Key patterns
Narrate your decision process
When: Every time you choose a component
How: Say the requirement, the options and the reason: 'We need 20k writes per second and simple key lookups, so Cassandra over Postgres; we lose joins, which we do not need.' The interviewer can only score what they hear.
Signal your level early
When: In the first five minutes
How: Ask questions that only an experienced engineer asks, such as expected peak vs average, consistency needs per feature, and who the clients are. It sets the interviewer's expectation of your level.
Use hints as a gift
When: The interviewer asks 'what about X?'
How: Treat it as a pointer to the area they want scored. Acknowledge, adapt the design and go deep there instead of defending the old answer.
Real-world use
Google hiring committee
Google interviewers write detailed feedback per round, and a separate committee reviews the packet and decides on hire and level. Clear, written-down evidence of each signal is what moves a packet.
Amazon Leadership Principles and the Bar Raiser
Amazon design rounds also score Leadership Principles such as Dive Deep and Customer Obsession, and a Bar Raiser from another team can block a hire. Explaining why a choice serves the customer is part of the signal.
Meta system design vs product architecture
Meta runs a system design round focused on distributed back-end problems and, for some roles, a product architecture round focused on APIs, data models and client-server interaction. Same signals, different emphasis.
Indian product companies
Flipkart, Swiggy, Razorpay and similar companies usually pair a high-level design round with a low-level design or machine coding round. For SDE-2 and above the HLD round is often the main levelling signal, and the hiring manager round checks ownership of past systems.
In a project
You have four years of experience and are interviewing for SDE-2 at one company and SDE-3 at another. In mock interviews you keep getting feedback that your design was 'correct but junior'.
- Record a mock and list where the interviewer had to prompt you to move on. Each prompt is a lost 'drives the conversation' signal.
- Practise opening every answer with requirements, numbers and a one-line plan of what you will cover, then follow your own plan.
- For each common problem, prepare two deep dives you can do well, for example idempotent payments and hot partitions, with numbers and failure cases.
- End each mock with three minutes on failures, monitoring and what you would change at 10x load, even if not asked.
- Ask your mock partner to score the five signals separately so you can see which one is weak.
Impact: Feedback changes from 'correct but needed guidance' to 'drove the design and went deep on idempotency', which is the evidence a debrief needs to approve the higher level.
Trade-offs
Use it when
- Planning how deep to prepare for a target level
- Deciding where to spend the remaining minutes in an interview
- Reading feedback from mocks and real loops
Avoid it when
- Trying to show Staff-level breadth in an SDE-1 interview while the basic design is still incomplete
- Memorising level rubrics instead of practising real designs
Common mistakes
- Believing the goal is the 'right' architecture; there is none, and the scorecard rewards reasoning.
- Waiting for the interviewer to drive at SDE-3 level, which reads as SDE-2.
- Going wide on ten components and deep on none, so there is no depth signal to write down.
- Not mentioning failure, monitoring or cost at senior levels.
- Treating hints as criticism and defending the first idea.
- Over-engineering a simple problem to look senior; good judgement includes knowing when one Postgres instance is enough.
Interview questions
Quick revision
- Five signals: problem framing, working design, depth, trade-offs, communication.
- Same question at every level; depth and ownership change.
- SDE-1: working design with guidance. SDE-2: drives, complete, one deep dive.
- SDE-3: finds the real bottleneck, two deep dives, failures, observability.
- Staff: challenges requirements, cost, migration, team boundaries, evolution.
- Interviewers score evidence they can write down, so say your reasons out loud.
- A hint points to what they want to score; follow it.
- Simple and correct beats complex and vague at every level.
Check yourself
1. What do interviewers mainly score in a system design round?
2. A candidate produces a correct design but the interviewer had to suggest each next step. What is the most likely outcome for an SDE-3 role?
3. Which topic most clearly signals Staff level?
4. The interviewer asks 'What happens if the cache cluster goes down?' What is the best response?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.