senior loop
Code Review · Bug Hunt · Design It · Build It · Deep Dives

Senior Loop trainscode review._

Review code, diagnose production bugs, build low-level designs, and study the tradeoffs that senior backend interviews test.

Try a free review →From $19/mo. See pricing →

3 code reviews · 16 Deep Dives · first Build It free — no card

Practice topics common in senior backend loops at
The platform

Four rounds. One loop.

The complete practice system for the real hiring loop — not just the phone screen.

00—Code Review

Review realistic production PRs

Realistic PRs with planted bugs across payments, distributed systems, API design, security, and performance. Hand-authored, AI-graded against a senior-engineer rubric.

Start reviewing free →
PR · idempotency-middleware
idempotency.go2 missed· 3 caught
23func (m *Middleware) Handle(...) {
24 key := r.Header.Get("Idempotency-Key")
25 if cached, ok := m.store[key]; ok {
26 writeCached(w, cached)
27 return
28 }
29 result := psp.Charge(...)
30 m.store[key] = result
31 writeCached(w, result)
32}
···
45func (m *Middleware) lock() {
46 m.mu.Lock()
47 defer m.mu.Unlock()
0
StrongSenior rubricscore / 100
S5correctness

Race window: cache check isn't atomic with PSP call.

S4correctness

In-memory store loses idempotency state on restart.

S4correctness

Float for money — precision drift on refunds.

S3observability

Missing trace ID on retry path.

ChatGPT reviews code you provide. Senior Loop gives you realistic problems with known issues, then grades what you found against a consistent rubric.

bug workspace · payment-service/tests
payment_test.go2 failures· 1 passing
=== RUN TestChargeIdempotency
    --- FAIL: duplicate charge on retry (2.31s)
    want: 1 charge created
    got:  2 charges (txn-4821, txn-4822)
=== RUN TestConcurrentRequests
    --- FAIL: race condition detected (1.84s)
    concurrent writes to m.store[key]
    DATA RACE: write at 0x00c000118040
=== RUN TestBasicCharge
    --- PASS: charge succeeds (0.12s)
FAIL   payment-service/tests  4.27s
ROOT CAUSE
S5correctness

Store mutation is not atomic — no check-before-insert. Concurrent requests bypass the idempotency guard.

HYPOTHESES RULED OUT
✗PSP deduplicated on its end
✗Network retry stripped the key
✓Race in m.store write (confirmed)
CANONICAL FIX
m.mu.Lock()
defer m.mu.Unlock()
// check store inside lock
00—Bug Hunt

Debug failures using code, tests, and logs

Broken codebases, failing tests, real log excerpts. Identify the root cause, fix it, compare against the canonical solution. Available in Go, Kotlin, Python, Java and C#.

Try 3 free →
00—Design It · High-level design

Design systems, graded against a rubric

Design It is HLD scaffolded into 7 parts — requirements, APIs & data model, architecture, core mechanism, extended features, security, and scalability tradeoffs. Sketch the diagram, write the tradeoffs, get graded on coverage — not a vibe check.

2 problems, both free →
hld workspace · rate-limiter
Design a Rate LimiterPart 4 / 7

Part 4 · Core mechanism. Diagram the request path: client, rate limiter, backend fleet, and where counters live.

Feedback — part 3
→Load balancer fronts the API tier
→Data store choice justified
→Missed: cache invalidation strategy
Part progress
1 · Requirements✓ graded
2 · APIs & data model✓ graded
3 · Architecture✓ graded
4 · Core mechanismin progress
5 · Extended featureslocked
6 · Securitylocked
7 · Scalability tradeoffslocked
00—Build It · Low-level design

Design systems under escalating constraints

Build It is low-level design with escalating constraints. Prove correctness with a conservation invariant — not just a passing eye-test.

First problem free →
lld workspace · rate-limiter · Go
Rate Limiter
Stage 3 / 4Senior filter

Design a distributed sliding window rate limiter. Enforce 100 requests per minute per user ID across a horizontally-scaled backend.

Constraints
→Redis backend, Lua for atomicity
→At-least-once delivery guarantee
→Sub-5ms overhead per request
→Prove conservation: allowed + rejected = total requests
Stage progress
Stage 1 · Fixed window✓ passed
Stage 2 · Sliding window✓ passed
Stage 3 · Distributedin progress
Stage 4 · Multi-regionlocked
Conservation invariant
allowed: 9,845
rejected: 153
total:  9,998 ≠ 10,000
✗ invariant violated — 2 lost
00—Deep Dives16 free

Learn the trade-offs behind distributed systems

Topics commonly tested in senior backend and system-design interviews, including Kafka, idempotency, Raft, distributed locks, rate limiting, and consistent hashing. 16 free, 26 total.

Read 16 free · 26 total →
deep dives · idempotency
13 Topics
Idempotencyreading
Saga · Outbox · CDC✓
Kafka internals—
Distributed cache—
Rate limiting—
Consistent hashing—
Distributed locks—
Two-phase commit—
Raft & leader election—
Chat at scale—
Push notifications—
Matching engine—
URL shortener—
Deep Dive 01

Idempotency

The most common correctness failure in distributed payment systems is the duplicate charge. It happens when a client retries a failed request that actually succeeded — the PSP charged, but the response was lost in transit.

The fix is an idempotency key: a client-generated UUID attached to each request.

// In prod: use Redis Lua for atomicity.
ifcached, ok := store.Get(key); ok {
return cached // idempotent response
}
result := psp.Charge(amount)
store.Set(key, result)

Engineers who made it

What engineers say.

Real feedback from engineers who used Senior Loop to land senior roles.

"Caught 4/5 severity issues on my first review. The rubric pushed me to reason like a staff engineer, not just spot bugs."

SG
Sajal Gupta
Staff Software Engineer
→ ServiceNow

"The Bug Hunt exercises are unlike anything else out there. Real test failures, real logs. I stopped pattern-matching and started actually debugging."

DG
Divyansh Goel
Scientist
→ Amazon

"The loop prep here mirrored the real senior bar — the rubric flagged exactly the gaps I needed to close. Cleared it on the next loop."

AM
Aayush Mittal
Senior Software Engineer
→ Agoda

"The Deep Dives go deeper than any blog post I've read. Idempotency, exactly-once delivery — explained at the depth a senior interview actually probes."

PG
Pulkit Gupta
Senior Software Engineer
→ Microsoft

"Caught 4/5 severity issues on my first review. The rubric pushed me to reason like a staff engineer, not just spot bugs."

SG
Sajal Gupta
Staff Software Engineer
→ ServiceNow

"The Bug Hunt exercises are unlike anything else out there. Real test failures, real logs. I stopped pattern-matching and started actually debugging."

DG
Divyansh Goel
Scientist
→ Amazon

"The loop prep here mirrored the real senior bar — the rubric flagged exactly the gaps I needed to close. Cleared it on the next loop."

AM
Aayush Mittal
Senior Software Engineer
→ Agoda

"The Deep Dives go deeper than any blog post I've read. Idempotency, exactly-once delivery — explained at the depth a senior interview actually probes."

PG
Pulkit Gupta
Senior Software Engineer
→ Microsoft
Pricing

Start free—no card required. Upgrade to Pro for the complete catalog.

Pro is a one-time 30- or 90-day purchase. It never auto-renews.

Free
$0
Forever
  • ✓3 code reviews — AI-graded against rubric
  • ✓16 Deep Dives
  • ✓Both Design It problems
  • ✓First Build It problem
  • ✓3 bug hunt exercises
Start free →
Recommended
Pro
$19/mo
Billed monthly
  • ✓All 15 code reviews
  • ✓All 26 Deep Dives
  • ✓All Bug Hunt exercises
  • ✓Full Design It access
  • ✓Full Build It access
  • ✓Unlimited grading attempts
Subscribe →

Stop memorizing patterns.
Train the real loop.

3 code reviews, 3 bug exercises, 16 Deep Dives, first Build It — no card required.

Try a free review →

Questions worth answering honestly

What does the free tier include?+

3 code reviews, 3 bug hunt exercises, 16Deep Dives, both Design It problems, and the first Build It problem — no card required. That's enough to run a real session in every module before you decide.

What is Design It?+

Design It is HLD (high-level system design) broken into 7 scaffolded parts — requirements, APIs & data model, architecture, core mechanism, extended features, security, and scalability tradeoffs. Each part is graded against a rubric, not a vibe check. Try it free →

What is Build It?+

Build It is LLD (low-level design) with real correctness requirements. You're given a problem and escalating constraints; Stage 3 is the senior filter. You prove correctness with a conservation invariant — not a passing eye-test. Try it free →

Is the backend-heavy content still useful if my loop isn't payments?+

The loops use payments and distributed systems as the domain, but the bugs and design problems are patterns — race conditions, idempotency failures, precision drift — that appear in any backend system. The domain is a wrapper; the skill is transferable.

How do I know the AI grading is accurate?+

Every exercise has a hand-authored rubric — specific issues, their severity, and exactly why they matter in production. The AI scores your submission against that ground truth, not against general code quality heuristics. The same rubric grades every attempt, so your score is comparable across attempts and across users.

Is $19/month worth it?+

Pro costs $19 per month and unlocks every exercise, deep dive, and grading attempt. Most candidates use it during their active interview-preparation period.

Still scrolling? Try 16 Deep Dives free — no card needed →
Or read the senior backend engineer interview prep guide →