Interview Questions for a Backend Developer

How do you decide when to add a database index, and what's the cost of having too many?

What to look for: Indexes speed reads but slow writes and add storage; chooses based on query patterns and selectivity, and verifies with the query planner.

Explain the difference between optimistic and pessimistic locking and when you'd use each.

What to look for: Optimistic for low-contention with version checks; pessimistic for high-contention critical sections; understands deadlock risk.

What do the isolation levels in a relational database actually protect against?

What to look for: Can name dirty reads, non-repeatable reads, and phantom reads, and maps them to read-committed vs serializable trade-offs.

How would you design a rate limiter for a public API?

What to look for: Token bucket or sliding window, where state lives (e.g. shared cache), per-key limits, and graceful 429 responses with retry headers.

Where would you add caching in a read-heavy service, and how do you avoid stale data?

What to look for: Identifies cacheable layers, picks TTL or invalidation strategy, and understands cache stampede and the thundering-herd problem.

How do you ensure an operation that touches multiple services either fully completes or safely fails?

What to look for: Transactions where possible, sagas or outbox pattern across services, idempotency, and compensating actions; avoids distributed two-phase commit naivety.

A query that was fast is now slow as the table grew. How do you diagnose it?

What to look for: EXPLAIN the plan, check for missing indexes or full scans, look at row counts and statistics, and consider pagination or partitioning.

How do you design pagination for an endpoint over millions of rows?

What to look for: Knows offset pagination degrades; prefers keyset or cursor pagination, with stable ordering and consistent results under writes.

Tell me about a production incident you owned. How did you respond and what changed after?

What to look for: Calm triage, clear communication, a real root-cause analysis, and durable fixes like alerts or runbooks, not just a hotfix.

Describe a time you had to balance delivery speed against data integrity.

What to look for: Won't cut corners on correctness, but can scope pragmatically and make the trade-off explicit to stakeholders.

When have you designed something for scale you didn't yet have? How did that play out?

What to look for: Awareness of over-engineering, building for plausible growth, and willingness to defer complexity until justified.

Tell me about a time you had to make a risky schema migration on a large live table.

What to look for: Plans backward-compatible, online migrations in stages, backfills safely, and has a rollback plan rather than locking the table.

Your service is timing out under a traffic spike. What's your immediate and longer-term plan?

What to look for: Short-term: scale, add a queue, shed load, cache; longer-term: find the bottleneck with metrics and fix the architecture.

You discover duplicate records from a retried webhook. How do you prevent and clean it up?

What to look for: Idempotency keys, unique constraints, dedup logic, and a safe backfill to remove existing duplicates.

A downstream dependency is unreliable. How do you keep your service resilient?

What to look for: Timeouts, retries with backoff, circuit breakers, fallbacks, and not letting one dependency cascade into total failure.

Reads are fine but writes are becoming a bottleneck as you grow. What options do you weigh?

What to look for: Considers write batching, async queues, sharding, read replicas for read offload, and the consistency trade-offs of each.