Demonstration proof

Example: What your review looks like

This is a representative example of the structure and tone you get after a practice session. Your real review will be based on the system you design and how you explain trade-offs.

Practice a problem See the rubric & methodology

Summary (what an interviewer would conclude)

Overall signal: clear framing + strong HLD, but gaps in capacity and failure modes.
Best moment: you called out the trade-off between consistency vs availability early.
Main risk: you didn’t name concrete bottlenecks or sizing assumptions.

Stage-wise highlights (rubric-style)

Requirements: clarified core vs nice-to-have; missed explicit latency SLO.
APIs: good request/response shapes; missing idempotency + pagination details.
Capacity: no back-of-the-envelope numbers; unclear QPS + storage growth.
High-level design: strong component boundaries; missing async flows + retries.

What to improve next (actionable)

Add a 60-second sizing pass: QPS, storage/day, bandwidth, and hot key risks.
Name 2–3 failure modes (DB overload, cache stampede, queue backlog) and mitigations.
State 1–2 concrete trade-offs you’d choose for the problem and why.

Full report (static)

In-app Final Review example

The preview below matches the live Final Review layout: problem statement, expert-aligned feedback label, and summary scores. Use Expand full report inside the card for hire reasoning, per-stage scorecards, strengths, weaknesses, and the rest—same static content as /ai-feedback-example.

Final Review

Complete analysis of your system design

Judge as:

InterviewCrafted

Problem Statement

Design a Rate Limiter

Design a rate limiter service that restricts the number of requests a client can make within a given time period. This is essential for preventing abuse and ensuring fair resource usage.

Constraints

Functional: Limit requests per client per window, multiple strategies (fixed/sliding window, token bucket), per-user limits, whitelisting, rate limit headers in response

Non-functional: Low latency (< 1ms overhead), millions of requests/second, precise limits, works across multiple servers

Scale: 10M requests/s, 100M unique clients, ~100 bytes per client (~10 GB total), 1-minute window

Design Considerations

Think about: How to track request counts efficiently (in-memory vs distributed cache); which rate limiting algorithm to use (fixed window, sliding window, token bucket); how to handle distributed rate limiting across multiple servers; how to store and retrieve rate limit data quickly; how to handle race conditions in distributed systems; how to implement different rate limits for different endpoints or users; how to handle rate limit expiration and cleanup.

Good luck!

Expert-aligned feedback (RAG)

Overall Score

52/100

Stages Completed

5/5

Hire Decision

Borderline

Confidence

62%

Expand full report

Hire reasoning, stage scorecards, readiness, strengths & weaknesses, validation Q&A, interview guide, and more.

Hire Decision & Reasoning

Borderline

Your submission shows a solid grasp of the problem and you completed all stages, which is why the score lands in the middle band (52/100). You identified core requirements and chose a reasonable direction (e.g. Redis, token bucket), but several answers stayed high-level without the depth or structure interviewers expect at senior level. The decision is Borderline because: (1) requirements and HLD had good ideas but lacked measurable NFRs and clear data flow; (2) API design mentioned endpoints but not full request/response or rate limit headers; (3) trade-offs and scaling were briefly touched on but not argued with alternatives. With more concrete details and one or two well-justified trade-offs, this would move into Hire range.

Why confidence is 62%:

•Enough content across stages to evaluate; some ambiguity in whether missing depth is scope or time.
•Requirements and HLD showed correct direction; deductions are for missing structure, not wrong ideas.
•Trade-off and extension sections were short—confidence would rise with more explicit alternatives and bottlenecks.

Stage-Wise Scorecard

Each stage is scored against senior-level expectations. The note under each score explains what drove the points.

Requirement Analysis (Stage 1)

12 / 20

overall12 / 20

You listed functional requirements (limit per client, 429 response) and mentioned scale, which earns the base score. Points withheld because: measurable NFRs (e.g. latency < 1ms, throughput) and explicit assumptions or edge cases (per-user vs per-IP, whitelisting) were not clearly stated—interviewers expect these to be called out early.

API Design (Stage 2)

11 / 20

overall11 / 20

You described endpoints and their purpose, which shows you understand the interface. Score reflects that request/response shapes (e.g. body fields, status codes) and rate limit headers (X-RateLimit-*, Retry-After) were missing; at senior level we expect a contract the interviewer could implement from.

High-Level Design (Stage 3)

14 / 25

overall14 / 25

You correctly chose a centralized store (Redis) and mentioned token bucket, which is the right direction. Points withheld for: unclear data flow (client → gateway → Redis step-by-step), how atomicity is achieved (e.g. check-and-increment), and TTL or cleanup strategy—these details show you can go from concept to buildable design.

HLD Extensions (Stage 4)

8 / 15

overall8 / 15

You acknowledged scaling and possibly sharding. Score is limited because: no concrete shard key or partitioning strategy, no named bottleneck (e.g. hot key, gateway CPU), and no explicit fail-open vs fail-closed or multi-region decision with reasoning—senior candidates are expected to name trade-offs and choose.

Trade-offs (Stage 5)

7 / 20

overall7 / 20

You may have mentioned a trade-off in spirit (e.g. consistency vs cost). Full credit requires at least two distinct trade-offs, with alternatives considered and a justified choice (e.g. 'We choose X over Y because…'). One brief mention without alternatives keeps the score in the partial range.

Interview Readiness by Stage

Based on your answers, we estimate how each stage would be perceived in a live interview.

Requirement Analysis (Stage 1)

Needs more practice

You have the right ideas (limit per client, scale) but interviewers expect measurable NFRs and explicit assumptions. Add 2–3 clarifying bullets and one line on edge cases to reach 'Ready'.

API Design (Stage 2)

Needs more practice

Endpoints and intent are there; what's missing is a clear contract (request/response fields, 429 + Retry-After). One pass to write that down would bring this to interview-ready.

High-Level Design (Stage 3)

Needs more practice

Redis and token bucket are good choices. To be ready, spell out the data flow step-by-step and how you enforce atomicity (e.g. Lua or check-and-increment) and TTL.

HLD Extensions (Stage 4)

Not ready

Scaling was mentioned but not specified (shard key, bottleneck, fail-open vs fail-closed). Interviewers will ask follow-ups here; add one paragraph with concrete choices and why.

Trade-offs (Stage 5)

Not ready

Trade-offs need to be explicit: name two options, compare them, and state your choice with a reason. One vague mention is not enough for senior bar; practice framing 2–3 trade-offs per design.

Answer Quality by Stage

We rate each stage as Strong (implementable, senior-level), Partially correct (right direction, missing detail), Superficial (high-level only), or Non-attempted.

Requirement Analysis (Stage 1)✅ Partially correct

You identified the right themes (functional limits, scale) but did not state measurable NFRs or explicit assumptions. Strong would add numbers (e.g. latency, throughput) and 2–3 edge cases.

API Design (Stage 2)⚠️ Superficial

You described what the API does rather than defining the contract. Partially correct would include request/response shapes and rate limit headers; Strong would add error codes and Retry-After.

High-Level Design (Stage 3)✅ Partially correct

Correct choice of Redis and token bucket. Missing: step-by-step data flow, how atomicity is achieved, and TTL/cleanup. Adding those would move this to Strong.

HLD Extensions (Stage 4)⚠️ Superficial

You acknowledged scaling and possibly sharding. Senior-level would name a shard key, one bottleneck (e.g. hot key), and a fail-open vs fail-closed decision with reasoning.

Trade-offs (Stage 5)✅ Partially correct

You may have implied a trade-off but did not name alternatives and justify a choice. Strong requires at least two trade-offs stated as 'X vs Y; we choose Z because…'.

Summary

Your overall score of 52/100 places you in the average band: you completed all stages and showed a reasonable understanding of rate limiting (e.g. Redis, token bucket, per-client limits), but many answers stayed at a high level. Senior interviews reward concrete, implementable detail: measurable NFRs in requirements, a full API contract with headers and errors, a clear data flow and atomicity story in HLD, and at least two trade-offs stated with alternatives and a justified choice. The review below explains per-stage what you did well and what was missing so you can target improvements. With focused practice on structure (NFRs, request/response, data flow, trade-off framing), you can move this profile into the hire range.

Strengths

You identified the right problem elements: per-client limits, 429 response, and the need for a shared store (Redis) and an algorithm (token bucket).
You completed all five stages, which shows you can structure a full pass; many candidates run out of time or skip trade-offs.
Your high-level direction (centralized Redis, token bucket) is correct; the main gap is turning that into a concrete, step-by-step design and contract.

Weaknesses

These gaps are why the score stays in the average band and the decision is Borderline rather than Hire.

Requirements lacked measurable NFRs (e.g. latency < 1ms, throughput in rps) and explicit assumptions or edge cases. Interviewers use this to see if you clarify scope; adding 2–3 bullets would fix this.
API design described intent but not the contract: request/response fields, rate limit headers (X-RateLimit-*, Retry-After), and 429 handling. Without that, the answer is hard to implement from.
HLD had the right components but not the flow: step-by-step (client → gateway → Redis), how atomicity is achieved (e.g. check-and-increment or Lua), and TTL/cleanup. These show you can go from concept to buildable design.
Extensions and trade-offs were brief. Senior bar expects a named bottleneck (e.g. hot key), a shard key, fail-open vs fail-closed with reasoning, and at least two trade-offs with alternatives and a justified choice.

Missed Points

Each of these, if added, would have increased your stage score. We list them so you know exactly what to include next time.

Measurable non-functional requirements (latency, throughput, consistency) and 2–3 explicit assumptions or edge cases in Stage 1.
Full API contract in Stage 2: request/response body fields, X-RateLimit-Limit/Remaining/Reset, Retry-After on 429, and error payload shape.
In Stage 3: end-to-end data flow (client → gateway → Redis), atomicity mechanism (e.g. Lua script or check-and-increment), and TTL or cleanup strategy.
In Stage 4: concrete shard key (e.g. clientId hash), one named bottleneck (e.g. hot key) with mitigation, and fail-open vs fail-closed (or multi-region) with a one-line reason.
In Stage 5: at least two trade-offs, each with 'Option A vs Option B; we choose X because…'.

Stage-by-Stage Feedback

For each stage we summarize what you did, what was missing for full credit, and what the rubric required. Use this to see exactly where points were lost.

Requirement Analysis (Stage 1)

What you did: You listed functional requirements (e.g. limit per client, 429 response) and mentioned scale or constraints.

What you missed:

Measurable NFRs (latency, throughput)
Explicit assumptions (e.g. per-user vs per-IP)
2–3 edge cases (whitelisting, burst handling)

What was required:

Functional requirements clearly listed
Non-functional requirements with numbers
Explicit assumptions or clarifications
At least 2 concrete edge cases

API Design (Stage 2)

What you did: You described endpoints and their purpose (e.g. check limit, get status).

What you missed:

Request/response body or query params
Rate limit headers (X-RateLimit-*, Retry-After)
429 and error response shape

What was required:

Clear interface abstraction
Well-defined request and response structures
Error handling strategy

High-Level Design (Stage 3)

What you did: You chose Redis (or similar) and mentioned token bucket or rate limiting logic.

What you missed:

Step-by-step data flow (client → gateway → Redis)
How atomicity is achieved (check-and-increment, Lua)
TTL or cleanup strategy

What was required:

Core components identified
Clear request/data flow
State ownership and storage
Consistency or coordination model

HLD Extensions (Stage 4)

What you did: You mentioned scaling or sharding in passing.

What you missed:

Concrete shard key or partitioning
Named bottleneck (e.g. hot key) and mitigation
Fail-open vs fail-closed or multi-region with reason

What was required:

Horizontal scaling strategy
Partitioning or shard key
Bottleneck identification
Consistency/availability trade-off

Trade-offs (Stage 5)

What you did: You may have mentioned a trade-off in spirit (e.g. consistency vs cost).

What you missed:

At least 2 distinct trade-offs
Alternatives stated (Option A vs B)
Justified choice ('we choose X because…')

What was required:

At least 2 meaningful trade-offs
Alternatives considered
Justified final decision

Validation Questions Feedback

How your follow-up answers were evaluated. We score each as Strong, Partially correct, or Superficial based on whether you gave implementable detail and showed senior-level reasoning.

Stage 1: Question: Considering the high volume of requests you anticipate, have you thought about the implications of cost when storing data in a distributed data store? How would you keep costs in check while maintaining performance? Your Answer: "I'd use Redis with TTL so we don't store data forever. Maybe token bucket to keep memory low. We could also rate limit at the gateway to reduce load." Answer Quality: ✅ Partially correct Why: You mentioned TTL and token bucket (good direction) but didn't compare alternatives (e.g. token bucket vs sliding window memory) or mention layering (CDN/gateway) or when to use strong vs eventual consistency. Strong would add that trade-off and a one-line cost strategy. What the Interviewer Was Testing: Cost awareness and trade-offs in a distributed system.

Stage 2: Question: How does your rate limit check integrate with the gateway, and what does the client see when they're throttled? Your Answer: "The gateway calls the rate limit service; if over limit we reject. Client gets an error." Answer Quality: ⚠️ Superficial Why: You described the flow at a high level but didn't specify the contract: 429 status, Retry-After header, or X-RateLimit-* headers so the client can back off. Partially correct would name status and at least one header; Strong would give the full set (Limit, Remaining, Reset, Retry-After). What the Interviewer Was Testing: End-to-end flow and client-visible contract.

Stage 3: Question: How would you synchronize rate limit state across multiple gateway nodes? Your Answer: "We use Redis so all nodes see the same data. Each request updates the count in Redis." Answer Quality: ✅ Partially correct Why: Correct idea (centralized Redis, shared state). Points withheld because you didn't say how updates are atomic (e.g. check-and-increment or Lua) or how you'd handle multi-region (regional vs global limits). Adding one sentence on atomicity and one on multi-region would make this Strong. What the Interviewer Was Testing: Distributed synchronization and consistency.

Time Management Analysis

Session completed in 38 minutes (ideal 45–60 min). You had time to touch all stages, but the later stages (extensions, trade-offs) were brief. For an average candidate this often means either (1) front-loaded time on requirements and HLD, or (2) trade-offs and scaling are still under-practiced. Recommendation: reserve 8–10 minutes for trade-offs and 5–7 for extensions so you can give at least two trade-offs with alternatives and one concrete bottleneck + mitigation. That would better showcase senior-level judgment without rushing.

Interview-Ready Guide

45-Minute Time Breakdown

0-5 min:Requirements clarification - Ask 2-3 clarifying questions, identify functional vs non-functional requirements, define scope boundaries

5-15 min:High-level architecture - Draw core components (client, API servers, databases, cache), explain data flow, identify key services

15-25 min:API design and data models - Design 3-5 core APIs with request/response, define key data models, explain relationships

25-35 min:Scaling and bottlenecks - Identify bottlenecks, discuss scaling strategies (horizontal scaling, caching, sharding), explain trade-offs

35-45 min:Trade-offs and Q&A - Discuss 2-3 key trade-offs, handle 'what if' questions, demonstrate senior thinking

What to Prioritize

✓Core functional requirements first - don't get stuck on edge cases
✓Simple architecture that works - add complexity only if asked
✓Clear data flow and component interactions
✓Identify and address bottlenecks early
✓Explicitly call out assumptions and trade-offs

What to Skip

✗Over-detailed implementation specifics (e.g., exact code, specific libraries)
✗Exhaustive edge cases (mention but don't deep-dive)
✗Perfect optimization (good enough is fine for interview)
✗Unnecessary components (don't add features not asked for)
✗Deep dive into technologies unless specifically asked

What to Say Explicitly

"I'm making an assumption here: [assumption] - state this explicitly"
"The trade-off I'm considering is: [trade-off] - show you're thinking about alternatives"
"I'm prioritizing [X] over [Y] because: [reason] - demonstrate decision-making"
"If we had more time, I'd explore: [future consideration] - show awareness of limitations"
"The bottleneck I'm most concerned about is: [bottleneck] - show system thinking"

Communication Tips

💡Structure explanations: Start with high-level, then drill down into details
💡Ask clarifying questions early: 'Should I assume X?' or 'Are we optimizing for Y?'
💡Handle 'what if' questions: Acknowledge the scenario, explain impact, propose solution
💡Demonstrate senior thinking: Show you understand trade-offs, not just memorized solutions
💡Use whiteboard effectively: Draw as you explain, label components clearly
💡Think out loud: Explain your reasoning process, not just the answer

Ideal solution (expert reference) is available after you complete a practice session.

What happens after you click “Practice a problem”?

You’ll pick a real interview prompt, then work through a guided stage-by-stage flow. When you finish, you’ll get a structured review with strengths, gaps, and next actions you can apply on your next attempt.

Back to homepage