Backend
Engineer.

F1 · Beginner · 45 min

Backend work starts with a language and the runtime under it. Pick one (Go, Java, Python, Node, Rust), and understand how it handles concurrency, memory, and packages — because the runtime shapes every performance and scaling decision you make later.

• Choosing a language
• Concurrency model
• Memory & GC basics
• Package management

Build itWrite a tiny HTTP server in your language that returns JSON. Note how it handles concurrent requests — threads, an event loop, or goroutines?

✓ CheckpointExplain what your language's concurrency model actually gives you — threads, an event loop, or something else — and which workloads it is wrong for.

F2 · Beginner · 60 min

The web speaks HTTP, and most backends expose REST APIs. Master the request/response cycle, methods and status codes, statelessness, idempotency, and clean resource design — the vocabulary every service and every interview is built on.

• Request / response
• HTTP methods & status codes
• REST resource design
• Statelessness & idempotency

Build itDesign the REST API for a pastebin: list the endpoints, methods, status codes, and request/response shapes. Which calls are idempotent?

✓ CheckpointJustify the status code you return when a request is well-formed but the action is not allowed, and say why 200-with-an-error-body is a lie.

F3 · Beginner · 75 min

The relational database is the heart of most backends. Learn the relational model, joins, indexes and B-trees, transactions and ACID, and how the query planner turns your SQL into a fast (or slow) plan. This is where correctness and performance meet.

• Relational model & joins
• Indexes & B-trees
• Transactions & ACID
• EXPLAIN & query plans

Build itModel a simple e-commerce schema (users, orders, products). Add the indexes a checkout query needs, and check the plan with EXPLAIN.

✓ CheckpointRead an EXPLAIN plan and say which index the planner used and why. If you cannot, you are tuning by guesswork.

F4 · Intermediate · 60 min

A cache is the highest-leverage tool for read-heavy backends: keep hot data in memory and spare the database. But caches bring their own problems — TTLs, eviction, invalidation, and the thundering herd when they go cold. Redis is the workhorse.

• Cache-aside
• TTL & eviction (LRU/LFU)
• Invalidation
• Redis data structures

Build itDesign the caching layer for a read-heavy profile service: what do you cache, for how long, and how do you survive a cache-miss storm?

✓ CheckpointExplain why cache invalidation is harder than caching, and what your TTL is really saying about how stale you are willing to be.

F5 · Intermediate · 60 min

Not everything fits a relational schema. Key-value, document, and wide-column stores trade joins and strict schemas for scale and flexible access patterns. The skill is modeling your data for how it will be read, and knowing when NoSQL beats SQL.

• Key-value / document / wide-column
• Access-pattern modeling
• Denormalization
• When NoSQL fits

Build itFor a chat app, decide where messages, user profiles, and presence each live — and justify SQL vs NoSQL for each by its access pattern.

✓ CheckpointTake an access pattern and design the key for it — then say what query becomes impossible as a result.

F6 · Intermediate · 60 min

Every backend must answer "who are you, and what may you do?" Learn authentication vs authorization, sessions vs JWTs, OAuth, password hashing, and the OWASP risks (injection, XSS, CSRF) — plus TLS. Security is not a feature you bolt on later.

• Authn vs authz
• Sessions & JWT
• OAuth basics
• Password hashing & OWASP

Build itDesign auth for an API: how do you issue and verify tokens, store passwords, and stop a stolen token being replayed forever?

✓ CheckpointState the difference between authentication and authorisation in one sentence, and name where your system checks each.

T1 · Intermediate · 60 min

Good APIs outlive their implementations. Beyond basic REST: pagination, consistent error handling, versioning without breaking clients, rate limiting, and when GraphQL or an API gateway earns its place. Design the contract as carefully as the code.

• Pagination & filtering
• Error handling & idempotency keys
• Versioning
• REST vs GraphQL / gateway

Build itEvolve a v1 API to v2 without breaking existing clients. Where do you version, and how do you deprecate gracefully?

✓ CheckpointExplain why an idempotency key is a correctness feature and not a convenience, using a retried payment as the example.

T2 · Intermediate · 60 min

One server has a ceiling. Scale out with stateless services behind a load balancer, and understand connection pooling, horizontal vs vertical scaling, and where shared state must live. Statelessness is the enabler for everything horizontal.

• Horizontal vs vertical
• Stateless services
• Load balancing (L4/L7)
• Connection pooling

Build itTake a single-server app to five servers. What must become stateless, where does session/state move, and how does traffic get distributed?

✓ CheckpointExplain what makes a service stateless, and where the state you removed actually went.

T3 · Intermediate · 50 min

Untested backends rot. Learn the test pyramid — many fast unit tests, fewer integration tests, a handful of end-to-end — plus mocking, test data, and contract tests between services. Tests are what let you change code without fear.

• Test pyramid
• Unit / integration / e2e
• Mocking & fixtures
• Contract testing

Build itFor a payment endpoint, decide what to unit-test, what needs an integration test with a real database, and what an e2e test should cover.

✓ CheckpointExplain what a contract test catches that unit tests on both sides structurally cannot.

T4 · Advanced · 60 min

Not everything should happen in the request. Queues and logs decouple producers from consumers, absorb bursts, and enable async work and event-driven architecture. Learn at-least-once delivery, idempotent consumers, and queues vs a Kafka-style log.

• Async decoupling
• Queue vs log (Kafka)
• At-least-once + idempotency
• Event-driven design

Build itMove email-sending out of the checkout request. Which queue guarantees do you need, and how do consumers avoid sending duplicates?

✓ CheckpointExplain why at-least-once delivery forces idempotent consumers, and what breaks the day you assume exactly-once.

T5 · Advanced · 55 min

You cannot fix what you cannot see. Instrument the three pillars — metrics (is something wrong?), logs (what happened?), traces (where?) — with structured logs and the golden signals, so 3am debugging is a guided walk, not a guessing game.

• Metrics / logs / traces
• Structured logging + trace ids
• Golden signals
• SLIs / SLOs

Build itAdd observability to a slow endpoint: which metric alerts you, which trace localizes it, and which log lines explain it?

✓ CheckpointExplain what you would look at first when latency rises but error rate does not, and which of the golden signals that is.

T6 · Advanced · 75 min

Now assemble the pieces. Back-of-the-envelope estimation, the CAP tradeoff, consistency models, and combining APIs, databases, caches, queues, and load balancers into a coherent system that scales — the skill senior interviews probe hardest.

• Capacity estimation
• CAP & consistency
• Component composition
• Tradeoff reasoning

Build itDesign a URL shortener end to end: estimate the numbers, pick the datastore, add the cache, and justify every component.

✓ CheckpointDo a capacity estimate out loud — requests, storage, bandwidth — and say which number you are least confident about.

P1 · Advanced · 70 min

Modern backends ship as containers. Learn Docker images, then orchestration: how Kubernetes runs hundreds of containers across machines by chasing a declared desired state, self-healing, load-balancing, and rolling out new versions.

• Docker images
• Pods & deployments
• Desired-state control loop
• Services & self-healing

Build itContainerize a service and declare 3 replicas. What happens when one pod crashes, and how does a rolling update stay available?

✓ CheckpointExplain what the desired-state control loop does when you delete a pod by hand, and why that is the whole idea.

P2 · Advanced · 55 min

Shipping should be boring. Automate build, test, and deploy in a pipeline, and release safely with blue-green or canary deploys, quick rollbacks, and feature flags that decouple deploy from release. Deploy small, deploy often, deploy reversibly.

• CI/CD pipelines
• Blue-green & canary
• Rollbacks
• Feature flags

Build itDesign a safe rollout for a risky change: how do you release to 1% first, watch metrics, and roll back in seconds if it breaks?

✓ CheckpointExplain what a canary tells you that a staging environment cannot.

P3 · Advanced · 60 min

Everything fails eventually. Build services that degrade gracefully: timeouts so a slow dependency cannot hang you, retries with backoff, circuit breakers that stop cascading failure, and bulkheads that isolate blast radius. Assume dependencies will break.

• Timeouts
• Retries & backoff
• Circuit breakers
• Graceful degradation

Build itA downstream service gets slow. Show how timeouts, a circuit breaker, and a fallback keep your API responsive instead of hung.

✓ CheckpointExplain why a retry without backoff and jitter makes an overloaded service worse, not better.

P4 · Advanced · 70 min

When one database is not enough: replicate for read scale and availability, and shard (partition) to spread writes and storage across machines. Learn read replicas, partitioning strategies, and the consistency tradeoffs each choice forces.

• Read replicas
• Sharding / partitioning
• Partition keys & hotspots
• Replication consistency

Build itYour users table is too big for one node. Choose a shard key, avoid hotspots, and explain what a cross-shard query costs.

✓ CheckpointPick a partition key for a real table and name the hotspot it creates. Every choice creates one somewhere.

P5 · Advanced · 60 min

Distributed backends bite in subtle ways: coordinating with distributed locks (and why they are hard), making operations idempotent so retries are safe, exactly-once myths, and clock/ordering issues. These are the traps senior engineers must see coming.

• Distributed locks & fencing
• Idempotency
• Exactly-once vs at-least-once
• Ordering & clocks

Build itTwo workers might process the same job. Make the handler idempotent so a duplicate is harmless — without a fragile lock.

✓ CheckpointExplain why a distributed lock without fencing is unsafe even when the lock service is working correctly.

P6 · Advanced · 50 min

Operating a backend is a discipline. Define SLIs/SLOs and an error budget to balance features against reliability, plan capacity and control cost, and run humane on-call with good alerts (symptoms, not noise) and blameless incident response.

• SLIs / SLOs / error budgets
• Capacity & cost planning
• Alerting on symptoms
• Incident response

Build itSet an SLO for a checkout API and derive its error budget. When the budget is spent, what should the team stop doing?

✓ CheckpointExplain what an error budget lets you do that an uptime target alone does not.