Backend Developer Interview Questions
Backend interviews reward candidates who talk in trade-offs: consistency vs availability, latency vs throughput, simple vs scalable. Every question below has a naive answer and a strong one — the difference is almost always whether you name the trade-off you are making.
Q1Design a REST API for a resource with pagination. Offset or cursor — and why?
What they're checking: Whether you know why offset pagination breaks at scale.
A strong answer: Cursor-based for stability under writes and constant-time deep pages; offset skips or duplicates rows when data changes mid-scroll. Mention stable sort keys as the prerequisite.
Q2A query is slow. Walk me through your diagnosis before you touch an index.
What they're checking: Method over guesswork — do you EXPLAIN first or add indexes blindly?
A strong answer: Read the query plan, check row estimates vs actuals, look for full scans and bad join orders. Then reason about index selectivity — and say out loud that every index taxes writes.
Q3Explain database transaction isolation levels. What anomaly does Repeatable Read not prevent?
What they're checking: Real understanding of concurrency, not memorised level names.
A strong answer: Walk dirty read → non-repeatable read → phantom read, tie each to the level that stops it, and note that Postgres Repeatable Read still allows write skew — with an example like double-booking.
Q4When does adding a cache make a system worse?
What they're checking: Whether you treat caching as a trade-off or a reflex.
A strong answer: Invalidation complexity, stale reads breaking correctness, thundering herds on expiry, and caches hiding load until they fail. A strong answer includes one war story or concrete mitigation like request coalescing.
Q5How would you make an API endpoint idempotent, and why does it matter for payments?
What they're checking: Distributed-systems maturity — retries are the default failure mode.
A strong answer: Client-generated idempotency keys stored with the result; replays return the stored outcome. Tie it to at-least-once delivery: networks retry, so money moves twice unless you design for it.
Q6Compare message queues and event streams. When is Kafka the wrong choice?
What they're checking: Tool judgement — candidates who can argue against the fashionable option stand out.
A strong answer: Queues for work distribution with acks, streams for replayable ordered logs. Kafka is wrong for simple task queues, low-volume systems, or teams without ops capacity — a managed queue wins there.
Q7How do you handle schema migrations on a table with 500 million rows and zero downtime?
What they're checking: Production scars. Anyone can ALTER TABLE on localhost.
A strong answer: Expand-migrate-contract: add nullable column, backfill in batches, dual-write, switch reads, drop old. Mention lock behaviour of your specific database and why naive ALTER locks the table.
Q8A service you depend on starts timing out. What do you do in code, and what do you do at 3am?
What they're checking: Resilience patterns plus operational instincts.
A strong answer: Code: timeouts, retries with jittered backoff, circuit breaker, fallback behaviour. At 3am: check blast radius, shed load or flag off the feature, communicate — then root-cause when stable.
Now try answering these under interview pressure
InterviewGPT runs a mock Backend interview — asks questions like these tailored to your situation, listens to your spoken answers, and scores every one with written feedback. First session free, no credit card.
Start a free Backend interview