35 Backend Developer Interview Questions (2026) — With What a Strong Answer Sounds Like

Short answer: Good backend developer interview questions test five things: API design, data modeling and databases, concurrency, reliability in production, and system design. Ask 5–7 per round and follow up hard. A strong backend engineer talks about failure modes, trade-offs, and what they'd measure — not just the happy path.

Backend interviews go wrong in two predictable ways. Either they turn into trivia quizzes ("what's the default isolation level in Postgres?") or they turn into a single giant system design question that rewards whoever has memorized the most YouTube diagrams. Neither tells you whether the person can own a service in production.

This guide gives you 35 backend-specific questions across five areas, with what to listen for in each. It's a companion to our broader 50 Software Engineer Interview Questions guide, which covers the general fundamentals and behavioral rounds. If you want questions generated straight from your own JD — Go vs Java, fintech vs e-commerce, junior vs staff — use the free Interview Question Generator.

How to structure a backend interview loop

A practical loop for a mid-level backend role is three rounds: one practical coding round (build or debug a small API), one data and system design round, and one behavioral round focused on production ownership. Pull 2–3 questions per area from the lists below instead of trying to cover everything.

The single most useful habit: after every answer, ask "what breaks first?" Strong backend engineers have an instinct for failure. Weak ones describe systems that only work when nothing goes wrong.

API design (questions 1–7)

1. Walk me through how you'd design a REST API for a simple booking system. Listen for: resource naming, correct use of HTTP methods and status codes, pagination, and how they handle double-booking. Bonus if they ask about the client before designing.

2. How do you version an API without breaking existing clients? Listen for: URL or header versioning, additive changes, deprecation windows, and communicating changes. Red flag: "we just update it."

3. When would you choose GraphQL, gRPC, or REST? Listen for: concrete trade-offs — gRPC for internal service-to-service, GraphQL for varied front-end data needs, REST for public simplicity. Name-dropping without trade-offs is a flag.

4. How do you make a payment endpoint safe to retry? Listen for: idempotency keys, storing request outcomes, and returning the original result on retry. This question separates people who've shipped payments from people who haven't.

5. How would you design rate limiting for a public API? Listen for: per-key limits, token bucket or sliding window, where it's enforced, and what the client sees (429 plus retry headers).

6. How do you handle authentication between internal services? Listen for: mTLS, signed tokens, short-lived credentials, and not trusting the network just because it's internal.

7. What goes into a good error response? Listen for: stable error codes, human-readable messages, request IDs for tracing, and not leaking stack traces or internal details.

Databases and data modeling (questions 8–15)

8. Design the schema for a multi-tenant SaaS app. Listen for: tenant ID on every row versus schema-per-tenant versus database-per-tenant, and how they'd prevent one tenant reading another's data (row-level security, scoped queries).

9. A query that used to take 20ms now takes 4 seconds. How do you investigate? Listen for: EXPLAIN plans, missing or unused indexes, table growth, lock contention, and checking what changed recently. A structured process beats a lucky guess.

10. When would you denormalize data? Listen for: read-heavy paths, known query patterns, and a plan for keeping copies consistent. Candidates who denormalize by default will create sync bugs.

11. Explain transaction isolation levels in practical terms. Listen for: what anomalies each level allows (dirty reads, non-repeatable reads, phantoms) and an example of a real bug caused by the wrong level.

12. How do you run a schema migration on a large table without downtime? Listen for: expand-and-contract, backfills in batches, dual writes, and avoiding long table locks.

13. SQL or NoSQL for an activity feed? Defend your choice. Listen for: access patterns first, database second. Either answer can be right if the reasoning is.

14. How do you prevent N+1 queries? Listen for: eager loading, batching, data loaders, and how they'd detect the problem in the first place (query logging, APM).

15. How would you handle soft deletes and data retention requirements? Listen for: deleted-at flags, unique constraints that still work, GDPR-style hard deletion, and backups.

Concurrency and performance (questions 16–21)

16. Two requests try to buy the last item in stock at the same time. What happens in your system? Listen for: row locks, optimistic concurrency with version columns, or atomic conditional updates. "It probably won't happen" is a fail.

17. When would you add a cache, and what can go wrong? Listen for: cache invalidation strategy, TTLs, stampedes, and serving stale data. Strong candidates mention that a cache is also a new failure point.

18. How do you move slow work out of the request path? Listen for: queues, background workers, retries with backoff, dead-letter queues, and telling the user the job is pending.

19. What's the difference between horizontal and vertical scaling, and when does each stop working? Listen for: stateless services scale out easily; databases and anything with shared state don't.

20. How do you find a memory leak in a long-running service? Listen for: heap profiling, comparing snapshots over time, and common culprits like unbounded caches or listeners that never get removed.

21. A downstream service is slow. How do you stop it from taking your service down? Listen for: timeouts, circuit breakers, bulkheads, and graceful degradation.

Reliability and production ownership (questions 22–28)

22. What do you log, and what do you deliberately not log? Listen for: structured logs, request IDs, and never logging secrets or personal data.

23. What metrics would you put on a dashboard for a new service? Listen for: latency percentiles (not just averages), error rate, throughput, and saturation. Bonus: alerting on symptoms users feel.

24. Walk me through the last production incident you were involved in. Listen for: timeline, how they found the cause, what they changed afterward, and a blameless tone.

25. How do you deploy safely? Listen for: CI checks, feature flags, canary or staged rollouts, and a fast rollback path.

26. How do you test code that talks to a database or external API? Listen for: a mix of unit tests with fakes, integration tests against real dependencies in containers, and contract tests for APIs.

27. How do you handle secrets and configuration? Listen for: a secrets manager or environment injection, rotation, and never committing secrets to git.

28. What would you check first if error rates spiked right after a deploy? Listen for: roll back first, investigate second. Candidates who want to debug live while users suffer are a risk.

System design (questions 29–35)

29. Design a URL shortener that handles 10,000 writes per second. Listen for: ID generation, storage choice, caching the hot reads, and analytics without slowing redirects.

30. Design a job queue that guarantees each job runs at least once. Listen for: acknowledgements, visibility timeouts, retries, and making jobs idempotent because "at least once" means duplicates.

31. Design a notification service for email, SMS, and push. Listen for: a queue per channel, provider failover, user preferences, and rate limits per user.

32. How would you design a file upload service for large files? Listen for: direct-to-storage uploads with signed URLs, chunking, resumable uploads, and virus scanning.

33. Design an audit log that nobody can quietly edit. Listen for: append-only storage, write-once permissions, and possibly hash chaining.

34. How would you split a monolith into services? Listen for: splitting along business boundaries, starting with one well-understood piece, and scepticism about splitting too early.

35. What's a design decision you made that you'd reverse today? Listen for: honest reflection and what they learned. Everyone senior has one.

How to score backend candidates

Rate each candidate 1–4 on five dimensions: API and data design, debugging and performance reasoning, production ownership, system design judgment, and communication. A candidate who writes clean code but never mentions failure modes will struggle on call. A candidate who talks only about architecture but can't debug a slow query will struggle in week one.

Write notes within 24 hours and calibrate with the other interviewers before deciding. For the general fundamentals and behavioral questions that complete the loop, see 50 Software Engineer Interview Questions and 30 Behavioral Interview Questions for Software Engineers.

Get to the interview faster

Most of the time in backend hiring isn't the interview — it's reading 150 CVs to find the eight worth talking to. HireBest scores every CV against your JD in seconds, with written reasoning and the missing skills called out, so your engineers spend their time in interviews instead of inboxes. See how to screen software engineer resumes for the manual version of the same process.

Frequently asked questions

How many questions should a backend developer interview include?

Five to seven per round, across a two- or three-round loop. Depth on a few questions — with follow-ups like "what breaks first?" — tells you far more than rushing through fifteen.

Should backend interviews include live coding?

Yes, but make it realistic. Building or fixing a small API endpoint, or debugging a failing test, predicts real work better than algorithm puzzles for most backend roles.

What's the most important trait in a backend developer?

Production ownership: caring what happens after the code ships. Listen for how candidates talk about monitoring, incidents, and rollbacks.

How do backend interview questions differ for junior and senior roles?

Juniors should handle API basics, SQL, and debugging with guidance. Seniors should lead system design, reason about failure modes unprompted, and explain trade-offs to non-engineers.

Can I generate backend interview questions from my job description?

Yes. HireBest's free Interview Question Generator turns any backend JD into tailored technical and behavioral questions in under a minute.