Skip to main content
CodeSparring

Level Calibration: Junior vs Senior vs Staff

Level 0: Level 0: Interview & Communication Methodmedium25 mincalibrationrubric

Know the four rubric axes and aim your depth at the target level: complete design (junior), unaided deep dives (senior), ambiguity plus org/cost/evolution (staff).

The same prompt, graded three different ways

The same prompt, "Design a rate limiter," is a pass or a fail depending on the level you are interviewing for, and the difference is not "more" but "aimed differently." A staff-depth answer to a junior loop can fail if it never finishes, and a junior-depth answer to a staff loop fails for lack of proactive depth. Calibration is knowing which one you are in and steering to that rubric.

Most companies grade a system-design round on roughly four axes:

  • Problem navigation: scoping, requirements, handling ambiguity.
  • Technical excellence: correct components, sound data model, working design.
  • Communication: narration, structure, responsiveness.
  • Proactive depth: finding bottlenecks and going deep without being asked.

What "complete" means per level

  • Junior: a correct high-level design. Core components (LB, app tier, database, cache), a basic path from request to response, and awareness that scale exists. Completeness beats depth. Finishing a clean, correct end-to-end design is a strong junior answer. You are not expected to derive novel tradeoffs; you are expected to not have holes.
  • Senior: everything junior, plus you find the bottlenecks yourself and quantify the tradeoffs. You do one or two real deep dives (the hot partition, the cache invalidation strategy, the fan-out) unprompted. You drive the round without the interviewer pulling you along. Estimation is not decoration; it justifies a design decision.
  • Staff+: everything senior, plus you own the ambiguity. You frame an under-specified prompt into a crisp problem, and your tradeoffs extend past the technical into org, cost, and reliability ("this doubles our on-call surface," "this triples storage spend at our scale"). You reason about how the system evolves over two years, and you make the call on what not to build.

For "Design a rate limiter," concretely: a junior nails token-bucket in a single service plus Redis for shared state. A senior adds the distributed-counter race, the sliding-window-vs-token-bucket tradeoff, and what happens when Redis is down (fail-open vs fail-closed). A staff candidate additionally frames whose traffic and which tier, argues the cost of per-user vs per-IP granularity, and picks a degradation policy tied to a business risk.

Check yourself

Same prompt, 'Design a rate limiter.' Which target level does each answer move signal most strongly?

Draws client to LB to API to Redis to DB and finishes with a clean 429 plus Retry-After, no holes anywhere
Unprompted, raises the race when two instances update the shared counter and fixes it with an atomic increment
Asks whose traffic is being limited and weighs per-user vs per-IP keying by what each choice costs the business
Compares fixed window, sliding window, and token bucket, then commits to one with a quantified reason
Names what not to build in v1 and sketches how the limiter evolves over the next two years

Interview nuance: Match estimation depth and deep-dive count to the level. A junior doing three deep dives runs out of time on the basics. A senior who does zero looks shallow. Budget roughly one deep dive for senior, two for staff, in a 45-minute round.

Interview nuance: If you do not know the level, ask, or infer it from the recruiter's title and the interviewer's follow-ups. When in doubt, deliver a complete junior-plus backbone first, then go deep, so you always have a finished answer before you gamble time on depth.

Recap: Aim depth and breadth at the target rubric; junior wants a complete correct design, senior wants unaided bottleneck-finding and quantified tradeoffs, staff wants ambiguity-framing plus org/cost/reliability and evolution thinking.

Check yourself
You are about to write your own rate limiter answer and you do not know the target level. What is the safest way to structure it?

Apply

Your turn

The task this lesson builds to.

Take 'Design a rate limiter' and describe how a passing answer differs at junior, senior, and staff level on scope, depth, and trade-off sophistication.

Think about

  1. What does 'complete' look like at each level?
  2. How many deep dives and how much estimation depth fit each level?
  3. What are the graded rubric axes?

Practice

Make it stick

A second problem on the same idea, so it survives past today.

Describe what specifically lifts your answer from a strong senior answer to a staff answer in a Staff Engineer interview at Stripe where the prompt is 'Design a rate limiter for our public payments API,' given that this is real money and real merchants.

Think about

  1. What is the real business requirement behind rate limiting a payments API: abuse, fairness, or blast radius?
  2. Which degradation policy decisions are business decisions rather than technical defaults?
  3. What two-year evolution and deliberate deferrals would a staff answer name?