What Changes by Level

What junior, mid, senior and staff answers look like on the same question, shown side by side on a like counter, and how to practise for your level.

18 minLesson 3 of 5
On this page
  1. The idea
  2. One question, four answers
  3. How to practise for your level
  4. In the interview
  5. Common mistakes
  6. What to practise next

Four candidates get the same prompt: "Design the like button for a social app, with a count under every post." All four draw a working system. One is hired as a new grad, one as mid-level, one as senior, and one is turned down for staff and offered senior. The difference was never whether the design worked. It was how much of the session they led, how deep they went, and how far past the boxes they looked.

Interviewers calibrate against a level. Knowing what the bar is for yours tells you where to spend your 40 minutes.

The idea

The scorecard does not change by level: problem exploration, design, trade-offs, depth, communication, as in how the interview works. What changes is how much you are expected to do without being asked. A simplification, since companies define levels differently, but a useful one:

  • Junior (new grad, early career): a correct, simple design that works end to end, with help. You ask sensible questions, know the basic blocks, and respond well to hints.
  • Mid-level: you drive the structure. You estimate, justify each component, and handle one deep dive well when it is pointed out.
  • Senior: you drive the whole session. You find the hard part yourself, go deep on two or three areas, argue trade-offs with costs and conditions, and bring up failure before you are asked.
  • Staff: everything senior, plus judgement about the problem itself: which requirements to challenge, what not to build, what it costs, how it evolves, and who else depends on it.

One question, four answers

The scenario numbers: 50 million likes a day, and a count shown on every post view, about 100 views for every like. Over a day of about 100,000 seconds that is 50 million ÷ 100,000 = 500 likes a second on average (the exact figure is nearer 580), and 500 × 100 = 50,000 count reads a second. Step through how the design grows as the level rises.

The like counter, level by levelUse the arrows or ← → keys
  1. The like counter, level by level, step 1App to Like service; Like service to Count cache (read count); Like service to Like events, asynchronous; Like service to Likes DB (insert like); Like events to Count aggregator, asynchronous; Count aggregator to Likes DB (count += n).AppLike serviceLikes DBcount++insert like
    likes/s
    500
    count reads/s
    50,000

    1Junior: a like inserts a row and increments the post's count in one transaction. Correct, and fine at 500 likes a second on average.

  2. The like counter, level by level, step 2App to Like service; Like service to Count cache (read count); Like service to Like events, asynchronous; Like service to Likes DB (insert like); Like events to Count aggregator, asynchronous; Count aggregator to Likes DB (count += n).AppLike serviceCount cachehitLikes DBread countinsert like
    likes/s
    500
    count reads/s
    50,000

    2Mid: the estimate shows 50,000 count reads a second, 100 times the writes. Counts may be a few seconds stale, so they go in a cache.

  3. The like counter, level by level, step 3App to Like service; Like service to Count cache (read count); Like service to Like events, asynchronous; Like service to Likes DB (insert like); Like events to Count aggregator, asynchronous; Count aggregator to Likes DB (count += n).AppLike serviceCount cacheLikes DBhot rowread countinsert like
    likes/s on post
    5,000
    row updates/s
    5,000

    3Senior, unprompted: a viral post gets 5,000 likes a second, and every one updates the same count row. Updates to one row wait on its lock, so that row caps the whole post.

  4. The like counter, level by level, step 4App to Like service; Like service to Count cache (read count); Like service to Like events, asynchronous; Like service to Likes DB (insert like); Like events to Count aggregator, asynchronous; Count aggregator to Likes DB (count += n).AppLike serviceCount cacheLike eventsLikes DBlike row onlyCount aggregatorread countinsert likecount += n
    likes/s on post
    5,000
    row updates/s
    0

    4Senior fix: insert the like row keyed by (user, post), so a double tap fails as a duplicate, and publish an event only when the insert succeeds. Nothing touches the count row.

  5. The like counter, level by level, step 5App to Like service; Like service to Count cache (read count); Like service to Like events, asynchronous; Like service to Likes DB (insert like); Like events to Count aggregator, asynchronous; Count aggregator to Likes DB (count += n).AppLike serviceCount cacheLike eventsLikes DBCount aggregator5,000 → 1 writeread countinsert likecount += n
    likes/s on post
    5,000
    row updates/s
    1

    5An aggregator sums events per post and writes once a second. 5,000 likes become 1 count update. The cost: counts lag by about a second.

  6. The like counter, level by level, step 6App to Like service; Like service to Count cache (read count); Like service to Like events, asynchronous; Like service to Likes DB (insert like); Like events to Count aggregator, asynchronous; Count aggregator to Likes DB (count += n).AppLike serviceCount cacheLike eventsbacklog growsLikes DBCount aggregatordownread countinsert likecount += n
    likes/s on post
    5,000
    row updates/s
    0

    6Senior, on failure: the aggregator dies. Likes are still stored and events wait in the queue; counts freeze, then catch up when it restarts. It must save its queue position in the same write as the count, or a restart replays events and counts them twice.

  7. The like counter, level by level, step 7App to Like service; Like service to Count cache (read count); Like service to Like events, asynchronous; Like service to Likes DB (insert like); Like events to Count aggregator, asynchronous; Count aggregator to Likes DB (count += n).AppLike serviceCount cacheLike eventsshared contractLikes DBCount aggregatorread countinsert likecount += n
    likes/s on post
    5,000
    row updates/s
    1

    7Staff: asks whether counts must be exact. The app shows "12K", so the last digits are invisible. And ranking and notifications want these events too, so the event stream is now an interface other teams depend on.

1 / 7

The same question, summarised. Each row includes the one above it.

LevelStarts withGoes deep onSays about failure
JuniorFeatures, and a question or two on scale.The schema and the API, when asked.Answers "what if the database dies?" with replicas.
MidFeatures, scale, the read/write ratio, an estimate.The cache, with a reason and a staleness bound.Walks each box when asked.
SeniorAll that, plus which path is hard: the hot post.Hot keys, idempotent likes, async counting.Raises it unprompted, with what is lost and what lags.
StaffAll that, plus whether exact counts are needed at all.The event contract, storage growth, rollout.Adds how you would detect it and who gets paged.

Staff candidates also close the gaps. If the service crashes between the insert and the publish, a like is stored but never counted, so a nightly job recounts popular posts from the like rows and corrects drift. And they put a number on growth. A like row is about 50 bytes, so 50 million a day × 365 is about 18 billion rows, near 1 TB a year. Small today, but a reason to decide retention and partitioning now rather than in year three.

How to practise for your level

Practice methods, and who gets the most from each
OptionGood atBad atPick it when
Redraw case studies from memoryBuilds the vocabulary of components and common patterns fast.Trains recall, not judgement; it does not feel like a live interview.Junior, in the first weeks. Then move on.
Timed solo mocksPractises pacing and structure on your own schedule.Nobody pushes back, so you never practise hints and curveballs.Mid-level, and anyone whose problem is running out of time.
Partner mocks with a scorer Usual defaultReal interruptions and follow-ups; feedback on how you sound.Needs a partner who knows the material and will be honest.Senior and above, and everyone in the last two weeks.
Review real design docsShows how cost, migration and ownership are argued in practice.Slow, and no clock.Staff candidates, alongside partner mocks.

Whatever your level, practise one level up in one area. A mid-level candidate who raises a failure mode unprompted, once, stands out. Mock interview practice has prompts and a way to run sessions.

In the interview

Ask the level if you do not know it, and ask what they want to see: "Should I focus on the overall design or go deep in one area?" Then make the level-defining moves out loud, so they are scored:

  • Mid: "Reads are 100 times writes, so I'll cache counts and accept a few seconds of staleness."
  • Senior: "The part I'm worried about is one viral post. Let me go there."
  • Staff: "Before I optimise this, do we need exact counts? If we show 12K, approximate is fine and much cheaper."
A senior candidate answering like a midWeak answer
Interviewer

The design looks complete. Anything else?

You

I think that covers it. Is there a part you'd like me to go into?

The same moment, at senior levelStrong answer
Interviewer

The design looks complete. Anything else?

You

Two things. A viral post puts 5,000 updates a second on one count row, so I'd move counting to an aggregator that writes once a second. And if the aggregator is down, likes are kept but counts freeze; I'd alert on queue backlog so we notice in minutes.

Follow-ups by level that you should expect:

  • Mid: "Why that database?" The five-part answer from talking through trade-offs.
  • Senior: "What breaks at 10 times the traffic?" Name the first bottleneck and its number, then the fix.
  • Staff: "How would you roll this out?" Behind a flag, dual-writing old and new counts, comparing them, then switching reads; say how you would roll back.

Common mistakes

Quick check

A post gets 5,000 likes a second. An aggregator writes the summed count once a second. How many count-row updates a second does that post cause?

Which move most clearly signals senior rather than mid level?

With 50 million likes a day and a day rounded to 100,000 seconds, what is the average like rate?

What to practise next

Keep the reference figures from Numbers to Know at hand, then run a full session from Mock Interview Practice at your level.