What interviewers look for, by level

Same design, different result

Two engineers interview for the same senior frontend role on the same day. Both get the prompt "Design an autocomplete search box." Both draw almost the same picture at the end: an input, a debounced fetch, a small cache, and a dropdown list.

The first one gets a "hire at senior". The second one gets "hire at mid level", which for a senior opening means a lower offer or no offer. Their final diagrams look the same, so what happened?

The difference is in how they got there and what they said along the way. The interviewer did not grade the final drawing. They graded a page of notes, written minute by minute, about what each person said, asked, and decided.

Two transcripts of the same minute

Here is roughly what each candidate said around minute 20, when they reached the network layer.

• Candidate A: "I'll debounce the input by about 200 ms, so a fast typist sends one request per pause instead of one per key, and suggestions still arrive within a 400 ms target. Requests can come back out of order, so I'll tag each one and drop any response that isn't for the latest query, or abort the old one with AbortController. If the request fails, the dropdown keeps the last good results and shows a quiet retry hint, because an error banner on every keystroke would be noise. I could also cache by query string; capped at 200 entries, that's well under a megabyte, so memory isn't a worry."
• Candidate B: "I'll debounce the input and fetch the results, then show them in the dropdown. I'll cache them too."

Both answers are correct. Only the first one gives the interviewer things to write down: a number with a reason, a race condition (two requests finishing in the wrong order) found without a prompt, two ways to fix it, a failure case with a product reason, and a quick size check. The second answer may hide the same knowledge, but the interviewer can't score what they never heard.

Interviewers write evidence, not impressions

At many companies with a structured process, the interviewer fills in a written report after the round. It usually has a few named areas, a rating per area, and an overall recommendation. Each rating should be backed by evidence: a quote or a short note of something you did.

That report is often read later by people who never met you, and they decide mostly from the notes. So "seemed smart" is weak. "Spotted the out-of-order response race without a hint and gave two fixes" is strong, because anyone can read it and agree. This lesson is about filling that page with clear, quotable evidence, at the level you are aiming for.

How this lesson fits with RADIO

The RADIO framework (Requirements, Architecture, Data model, Interface, Optimizations) tells you what to do in the round and roughly how long to spend on each step. This lesson tells you how it is judged. If you haven't read it yet, start with [the RADIO framework](/system-design/concepts/radio-framework); this one assumes you know the five steps and the usual time split, and won't repeat them.

The mental model: a scorecard and a moving bar

Keep one picture in your head for the whole round: the interviewer has a form with six rows and a pen. Each row is an area they need to rate. Every few minutes, something you say either adds a line of evidence to a row or doesn't.

Next to the form sits a second sheet: the bar for the level you're interviewing at. It says what "meets the bar" looks like in each row for that level. The same evidence can meet the bar for mid level and fall short for senior.

The six rows

The names change from company to company, but many frontend system design scorecards cover some version of these six areas.

1. Problem exploration. Did you find out what to build before building it? Users, devices, data size, and what is in and out of scope.
2. Architecture. Did you split the system into clear parts, each with one job, with data flowing in a direction you can explain?
3. Technical depth. When you named a technique, could you explain how it works, what it costs, and survive a follow-up question?
4. Trade-offs. Did you weigh real options and pick one for reasons tied to this problem?
5. Product sense and quality. Did you think about the people using it: loading, empty, and error states, accessibility, performance on a mid-range phone?
6. Communication. Could the interviewer follow you? Did you lead, check in, and use hints?

Some companies fold these into fewer rows ("design" and "communication") or split them further ("accessibility" as its own row). Some add a row for collaboration or culture. If you cover these six, you have covered what the common versions ask about.

How each row gets a rating

A common pattern is a four-point scale per row, something like "strong no", "leaning no", "leaning yes", "strong yes". Some forms add "not enough evidence". That last option is the one to fear, because a row with no evidence can't be argued for in the debrief (the meeting where interviewers compare notes).

Then the interviewer gives an overall call, often with a level attached: "hire, at senior" or "hire, but at mid level". The overall call is not a simple average. One very weak row, such as communication so poor the interviewer couldn't follow the design, can sink a round with good rows elsewhere.

Why this model helps you

Thinking in rows changes how you spend minutes. Five minutes polishing a component tree you've already drawn adds nothing new to the architecture row. Those five minutes spent on what happens when the feed request fails would add a first line to product sense and maybe one to depth.

The six areas in detail

Here is each row in turn: what the interviewer is really asking, what strong evidence sounds like, and the mistake that most often leaves the row thin.

1. Problem exploration

The question behind this row: can this person be trusted with a vague task? At work, nobody hands you a full spec. The interviewer wants to see you turn "design a photo gallery" into something you can build.

Strong evidence is a few sharp questions whose answers change the design, followed by a written scope. "How many photos can an album have: 50 or 50,000?" changes everything about the list. "Is this mainly phones?" changes image sizes and layout.

Then you close the loop: "I'll cover browsing and the full-screen viewer, and leave out upload. OK?"

The common mistake is asking many questions that change nothing ("what color is the header?") or asking good questions and then not writing down the answers. A scope on the board is evidence the interviewer can point to later.

2. Architecture

The question: can this person break a system into parts that a team could build and change? For frontend, that means views, a client store, a data layer that talks to the server, and the server-side pieces you depend on (an API, a CDN or content delivery network, maybe a real-time channel).

Strong evidence is a small diagram where every box has one job and every arrow has a direction. You can say in one sentence what each box owns: "The feed store owns the list of post IDs and the cursor. Components never call fetch directly."

The common mistake is one giant box ("the App component fetches, stores, and renders everything") or the opposite: twenty boxes, half of them named after libraries. Boxes should be named after jobs, not tools.

3. Technical depth

The question: does this person understand the tools, or only know their names? Depth is tested by follow-ups. You say "I'll virtualize the list", and the interviewer asks "how does that work when rows have different heights?"

Strong evidence is explaining a mechanism with real details and its cost: "Only the rows in view, plus a few above and below, are in the DOM. With varying heights, I measure each row after it renders, cache the height, and estimate the ones I haven't seen. The scrollbar can jump a little when estimates are wrong, so I'd keep estimates close to the average row."

The common mistake is naming a technique you can't explain. Every buzzword is an invitation for a follow-up. If you say CRDT (a data type that merges edits from several users), expect "how does it merge two edits at the same spot?"

4. Trade-offs

The question: does this person choose, or just pick the first thing they know? Almost every design choice has a real alternative, and each has a cost.

Strong evidence follows a short pattern: the options, the deciding factor in this problem, the pick, and what you give up. "Polling every 30 seconds or a WebSocket. Scores change about once a minute and we have millions of idle viewers, so I'll start with polling behind a CDN. The cost is up to 30 seconds of delay, which is fine for a scoreboard but wouldn't be for chat."

The common mistake is treating one option as obviously right. "I'll use GraphQL" with no reason reads as habit. The opposite mistake also hurts: listing pros and cons for five minutes and never choosing.

5. Product sense and quality

The question: does this person build things that work for real users? This row collects loading, empty, and error states; accessibility (keyboard, screen readers, focus); performance on a mid-range phone on a slow network; and small product details like keeping scroll position when you come back to a list.

Strong evidence is specific: "The dropdown is a combobox: arrow keys move through options, aria-activedescendant tells the screen reader which one is active, and Escape closes it."

The common mistake is saving all of this for the last two minutes, as a list: "and also accessibility, and also error handling." That shows you've heard of these things; building them into each part as you go shows you design with them.

6. Communication

The question: would working with this person be easy? The interviewer notes whether they could follow you, whether you checked in at the right moments, and how you handled hints and pushback.

Strong evidence is structure you say out loud ("Requirements are done; I'll sketch the big parts now"), short check-ins ("Does that scope work for you?"), and graceful changes of mind ("Good point, 10,000 items breaks this. Let me switch to virtualization.").

The common mistake is the monologue: ten minutes of talking with no pause, so the interviewer can't steer you to what they wanted to see. The opposite also happens: long silence while you think, which leaves nothing to write.

Where each row gets its evidence

The rows don't line up one-to-one with the RADIO steps. Problem exploration is mostly earned in the first minutes, and architecture in the middle. Trade-offs and communication can be earned in every step, while depth and product sense mostly come from the deep dives at the end.

Junior, mid, senior, staff: how the bar rises

Here is a part people often get wrong: a higher level is not mainly about knowing more tools. A mid-level and a senior engineer often know the same APIs. What changes is how much of the problem they own without being told.

A useful way to say it: a junior engineer builds what was described. A mid-level engineer builds what was asked, and asks good questions about it. A senior engineer works out what should be built and what could break. A staff engineer also sees the problems around it: other teams, cost, migration, and how the design grows over years.

The same question, a different bar

Many companies use the same prompts at several levels. "Design an image carousel" might be asked of a mid-level and a senior candidate in the same week. The interviewer doesn't change the question; they change what counts as "meets the bar" in each row.

Also note that many companies don't run a system design round for junior roles at all. When juniors do get one, it's usually a component question (a modal, a tabs widget, a star rating), and the bar is a working, clear design with some help from the interviewer.

Try the explorer below. Pick a row and a level and read what a typical interviewer hopes to hear, then step one level up and see what's added. Notice how often the step from mid to senior is about doing something before being asked.

Junior and mid: correct and clear

At junior level, the interviewer mostly checks fundamentals: can you build a component with sensible props and state, fetch data, and handle a basic error? Being guided is expected. Clear thinking and honest "I don't know, but here's how I'd find out" answers count for a lot.

At mid level, the design should be complete and correct with light guidance. You split state sensibly, define a clean API, handle loading and error, and explain your choices when asked. What's usually missing is initiative: the interviewer had to steer you to the hard parts.

Senior: you lead

At senior level, the interviewer expects to do less steering. You set the scope, pick the hard parts yourself ("the two risky bits are request races and keyboard access"), and bring up options and failures before being asked. Depth matters too: a senior answer survives two or three follow-ups on the same topic.

A good test: if the interviewer stayed silent for the whole round apart from answering your questions, would your design still cover the important parts? For a senior bar, the answer should be mostly yes.

Staff: you widen the frame

Staff-level design rounds vary a lot between companies. A common thread is scope beyond the component: how several teams would share this (a design system, a shared data layer, an API contract with versioning), how you'd roll it out safely (feature flags, a migration path from the old version), how you'd measure success (real-user metrics, error rates), and what you'd deliberately not build yet.

Staff candidates also make calls with missing information and say what would change their mind: "I'd start with server rendering. If we learn most traffic is logged-in users on repeat visits, I'd move the shell to the client and cache it with a service worker." That sentence shows judgment under uncertainty, which is much of the staff job.

How to show seniority

Seniority shows in a handful of habits. None needs new knowledge; they are ways of saying what you know so it lands on the scorecard. This chapter covers driving scope, offering trade-offs unprompted, tying choices to numbers, and managing the clock. Failure modes get their own chapter next.

Habit 1: drive the scope

Driving scope means you turn the vague prompt into a plan and own it. You still ask questions, but you ask them to make a decision, and then you make it.

Sizing belongs to scope. After the scope, add one or two rough numbers that shape the design: "A long session might scroll 300 posts. At around 2 KB of JSON each, that's 600 KB of data, fine in memory, but 300 posts of DOM with images is too much, so the list needs virtualization." Thirty seconds of arithmetic and you've justified a major choice before the interviewer asked.

Habit 2: offer trade-offs before you're asked

Mid-level candidates explain a choice when the interviewer asks "why?". Senior candidates say why before the question comes. The difference is small in words and large on the scorecard.

You don't need a long comparison for every choice. Most choices deserve one sentence that names the road not taken: "I'll keep the open state in the component, not the global store, because nothing else reads it." Save the full side-by-side comparison for the one or two choices that really shape the design.

The one-sentence trade-off:
  "I'll use X rather than Y, because <fact about this problem>.
   The cost is Z, which is fine here because <reason>."

Examples:
  "Cursor pagination rather than page numbers, because new posts
   arrive at the top. The cost is no 'jump to page 7', which a feed
   doesn't need."

  "Server-sent events rather than WebSockets, because updates only
   flow one way. The cost is a second channel if we add typing
   indicators later."

The picture below shows the same moment in a feed interview answered two ways, with the same design underneath.

Habit 3: tie choices to numbers

Numbers turn opinions into decisions. You don't need precision, just the right order of magnitude. A handful of figures cover most frontend rounds.

• Core Web Vitals at the 75th percentile of page loads: LCP (Largest Contentful Paint, when the main content appears) at most 2.5 s, INP (Interaction to Next Paint, how fast the page reacts to input) at most 200 ms, CLS (Cumulative Layout Shift, how much things jump) at most 0.1.
• A frame at 60 Hz is about 16 ms; a long task (main-thread work over 50 ms) delays any input that arrives during it.
• Network: a round trip on a mobile network often costs 100 ms or more, so one request beats three in a row.
• Data size: a feed post as JSON is often 1 to 2 KB; a thumbnail is tens of KB; a full photo is hundreds of KB.
• DOM size: a few thousand nodes is usually fine; tens of thousands make style and layout slow, especially on mid-range phones.

Say the number, then the decision it drives: "Typing triggers a request per pause, not per key. A 200 ms debounce cuts maybe 8 keystrokes down to 2 or 3 requests." One number with a consequence is worth more than five numbers recited.

Habit 4: manage the clock and the agenda

A senior candidate decides where the time goes and says so. Name your deep dives early ("The hard parts here are long-list performance and keeping the feed fresh; I'll spend most of my time there") and move quickly through the parts that are standard ("The API is a plain cursor-paginated GET; I'll keep it brief"). Saying it out loud lets the interviewer redirect you early. For the time budget itself, start from the split in [the RADIO framework](/system-design/concepts/radio-framework).

Failure modes: the fastest senior signal

If you only change one habit, make it this one: for every part that touches the network or the user, say what happens when it goes wrong before the interviewer asks. It's the quickest way to move evidence from the mid column to the senior column.

Think in states, not screens

A simple way to find failure modes is to stop thinking of "the screen" and think of the states each piece of data can be in. A list fetched from the server isn't just "loaded". It is idle, loading, showing data, empty, failed, refreshing with old data still shown, or offline. Each state needs a design.

Naming these states out loud shows you design for the unhappy paths, and gives you a checklist. Refreshing is the one candidates often skip, so name it on purpose.

The failures worth naming

You don't need to cover everything. Pick the two or three that matter most for this product and say how the UI behaves in each. This table covers the common ones.

Pick the failures by product

Which failures matter depends on what the product does. A short mapping helps you choose fast in the room.

• Checkout or payments: a request that times out after the money may have moved. Idempotency keys and a clear "we're checking your order" state matter most.
• Chat or collaboration: dropped connections, messages arriving out of order, and two people editing the same thing.
• Feeds and galleries: slow images, a failed page in the middle of a long scroll, and layout shift when images load.
• Search and autocomplete: out-of-order responses and a request on every keystroke.
• Forms and editors: losing the user's typing on a crash or a refresh, and saving twice.

Mistakes that cost a level

Some mistakes fail a round outright, such as designing the wrong thing or a design that doesn't work. This chapter is about the quieter ones: you pass, but the notes describe a lower level than you applied for. They are frustrating because the knowledge was there.

Mistakes in the first ten minutes

• Waiting to be given the scope. At senior level, "What should I build?" followed by silence reads as needing direction. Propose instead.
• Twenty questions. Asking every question you can think of eats time and shows you can't tell which facts matter.
• Skipping the numbers. No sense of size means later choices (virtualization, pagination, caching) look like habits, not decisions.

Mistakes in the middle

• The right answer with no reason. "I'd use SSR (server-side rendering)" earns little. Add "because the feed is the landing page and a fast first paint matters more here than server cost" and it earns the point.
• Listing instead of choosing. Ten performance tips in a row show memory, not judgment. Pick the two that matter here and go deep.
• Over-building. Micro-frontends for a star rating, or a custom state library for a modal. Matching the design to the problem's size is itself a senior signal.
• Going deep on the backend. Twenty minutes on database sharding uses time that a frontend scorecard has no row for. Say what you need from the server and move on.

Mistakes under pressure

• Defending a choice after a good hint. When the interviewer asks "what about 10,000 items?", they are usually telling you something. Adjust and say why; that's positive evidence.
• Hiding a gap you noticed. If you realise at minute 30 that the feed never refreshes, say so and fix it. Spotting your own gap reads well.
• Bluffing a follow-up. "I'm not sure how that works in detail. My guess is X, and I'd check Y" is honest and still shows reasoning. A confident wrong answer can damage the depth row for the rest of the round.
• No summary. Running until the interviewer calls time, with no wrap-up of what you built and what you'd do next.

When you're stuck

Being stuck isn't scored. Silence while stuck is, because it leaves nothing to write. The flowchart is a routine for the moment your mind goes blank.

The key move is to say what you're weighing, even before you've decided. "I'm torn between keeping drafts in memory and in IndexedDB. Memory is simpler, but a refresh would lose the user's text, and that's the failure that matters most in an editor" is already trade-off and product evidence, and it often gets you unstuck.

Train your ear

A good way to fix these habits is to hear the difference. Below are lines a candidate might say. For each one, guess which row it feeds and whether it's thin or strong evidence, then check.

A worked 45-minute round, signal by signal

Here is one senior-level round, told minute by minute, with what the interviewer might write after each part. The prompt: "Design the comments section for a video page." It's a good test case because it has a long list, live updates, writes that can fail, and real accessibility work.

The time blocks follow the default split from [the RADIO framework](/system-design/concepts/radio-framework), with the last two minutes of deep-dive time kept for a wrap-up. Watch how every few minutes something new lands on the scorecard, and how each habit from the earlier chapters shows up.

Minutes 3 to 8: scope and size

The candidate asks three questions: "Are we on desktop and mobile web? Do popular videos have thousands of comments? Do new comments need to appear live, or is a refresh fine?" The answers: both, yes (some have 50,000), and live is nice to have.

Then they propose: "I'll cover reading comments, posting a top-level comment, replies one level deep, and likes. I'll leave out moderation tools and editing. For live updates, I'll show a 'new comments' pill rather than inserting them, so the list doesn't jump while someone reads." Then a quick size: "Most people read the first 20 to 40 comments, so I'll load 20 at a time."

Notes: drove the scope; sized it; product reason for the live-update choice (layout stability). Problem exploration and product sense both get a first line.

Minutes 8 to 16: the parts

They draw: a CommentsSection that only renders; a comments store holding comments by ID and the order; a data layer that owns fetching, the cursor, and the live channel; the comments API; and an avatar CDN. They say: "Comments are below the video, so this whole section can load after the player. I'll start fetching when it's near the viewport, so it never competes with the video for bandwidth."

Notes: clear parts with one job each; a loading-priority trade-off offered unprompted. Architecture and trade-offs.

Minutes 16 to 25: data and API

The Comment entity has an ID, author ID, body, time, like count, likedByMe, reply count, and a status that can be sent, pending, or failed for the user's own comments. Authors are stored once by ID. The body is user text, so it's rendered as text, never as HTML, which blocks XSS (cross-site scripting, where a comment injects its own script).

The API is GET /videos/:id/comments?cursor= and POST with a client-generated ID. "The client ID does two jobs: it's the idempotency key if the post is retried, and it lets me match the server's copy to my pending one, so the comment doesn't show up twice."

Notes: a pending state in the data model (product sense), XSS mentioned in one line (depth), one ID solving both duplicates and retries (depth and trade-offs).

Minutes 25 to 38: three deep dives

1. Posting when the network is bad. The comment appears at once with a "posting" label. On failure it stays in place with "not posted, retry", and the text is never lost. Retries reuse the same client ID, so the server ignores duplicates.
2. The long list. Load 20 at a time on scroll with an IntersectionObserver sentinel. For a reader who scrolls hundreds of comments, virtualize, measuring heights after render because comment lengths vary. The cost: browser find-in-page can't see comments that aren't rendered, which they mention as a known limit.
3. Accessibility. Comments are a list of article elements with the author and time as a heading. The "new comments" pill is announced through a polite live region, but only as a count, not every comment, so screen reader users aren't flooded. After posting, focus stays in the box so the user can keep typing.

Midway through the list deep dive, the interviewer asks: "What if a comment is deleted by a moderator while I'm reading?" The candidate takes the hint: "The live channel can send a delete event; I'd replace the comment with 'This comment was removed' rather than removing the row, so the list doesn't shift under the reader."

Notes: depth in three areas, each with a cost; failure handled before being asked; accessibility built in, not listed; a hint taken quickly with a product reason.

Minutes 38 to 40: the wrap-up

"To sum up: a lazy-loaded section with a normalized store, cursor paging, optimistic posts with idempotent retries, and a live pill instead of live inserts. With more time, I'd look at ranking (top versus newest), which changes caching, and I'd watch INP on the comment box on low-end phones."

Notes: led the session to a clean finish; knows where the design is still thin. Communication. The last five minutes are the candidate's questions about the team, which usually don't feed the design rows.

Step through the same round below and watch the six rows fill. Notice that most rows are built from several moments spread across the round, not from one big moment.

After the round, and how to practise

It helps to know what happens to your page of notes after you leave, because it explains why clear, quotable evidence matters so much. The details differ between companies, but the shape is common.

Write-up, debrief, decision

1. Write-up. Soon after the round, the interviewer turns notes into a report: evidence per area, a rating per area, and an overall call, often with a level.
2. Debrief. At many companies, the interviewers from your loop (coding, system design, behavioral) compare reports. Where they disagree, the written evidence is meant to decide, not who argues hardest.
3. Decision and level. A hiring manager or a committee makes the call and sets the level. If the system design report reads "solid design, but needed steering to the hard parts", that often points to the level below the one you applied for.

This is why quotable moments win: "proposed idempotent retries for posts without a prompt" is easy to defend in a debrief. It's also why, at many companies, the design round often weighs heavily in the level decision at senior and above: it's where scope and judgment are most visible.

A practice plan that targets the rows

Many people practise by reading solutions. That builds knowledge (the depth row) but not the habits that fill the other five. Practise out loud, with a timer, and review against the rows.

• Scope drill (5 minutes each). Take any prompt and practise only the first five minutes: three questions, a proposed scope, one or two numbers. Do five prompts in a row.
• Trade-off drill. For each choice in a solution you've read, say the one-sentence trade-off out loud: X rather than Y, because, the cost is.
• Failure drill. For each arrow in your diagram, name what happens when it's slow, fails, or races. Aim for one sentence each.
• Full mocks. 45 minutes with a friend or a recorded session. Afterwards, tick the six rows and note the thinnest one. Practise that row next time.