Fifteen common backend interview questions
- Design a REST API for a feature you've built. What would you change now?
- How do you choose between SQL and NoSQL for a new service?
- How does a database index work, and when does it not help?
- Explain transaction isolation levels with an example bug each prevents.
- Where would you add caching, and how do you keep it consistent?
- What is the N+1 query problem?
- How do you make an operation idempotent?
- At-least-once versus exactly-once delivery in message queues?
- How do you handle a slow downstream dependency?
- Explain rate limiting algorithms.
- How do you design for horizontal scaling?
- How do you store passwords and handle authentication tokens?
- What do you log and monitor for a service?
- How do you roll out a risky database migration?
- Design a URL shortener or a notification service.
Data and caching
- SQL or NoSQL: default to a relational database for transactional data with relationships and constraints; choose a document, key-value or wide-column store when access patterns are simple and scale or schema flexibility dominate.
- N+1: fetching a list, then querying once per item. Fix with joins, batched IN queries or eager loading.
- Caching: cache-aside is the common pattern — read the cache, fall back to the database and populate. Set TTLs, invalidate on writes, and protect against stampedes when a hot key expires (locking or early refresh).
- Migrations: expand-and-contract — add new columns or tables, dual-write, backfill, switch reads, then remove the old structure — so each step is backward compatible.
Reliability patterns
| Problem | Pattern |
|---|---|
| Retries cause duplicate effects | Idempotency keys and deduplication |
| Slow dependency drags everything down | Timeouts, circuit breakers, bulkheads |
| Traffic spikes | Queues to absorb load, autoscaling, rate limiting |
| Message delivered twice | Idempotent consumers; at-least-once plus dedupe |
| Partial failure across services | Sagas with compensating actions, outbox pattern |
| Thundering herd on recovery | Exponential backoff with jitter |
Concurrency and rate limiting
Expect a concurrency scenario: two requests decrement the same inventory. Answers include a database constraint or conditional update (UPDATE … WHERE stock > 0), optimistic locking with a version column, or a distributed lock for cross-service cases — with the trade-offs of each. For rate limiting, know token bucket (allows bursts up to capacity), leaky bucket (smooths output), and fixed versus sliding windows (sliding avoids boundary bursts), and where to store counters in a distributed setup, usually Redis. See Redis interview questions.
Security basics
Hash passwords with a slow, salted algorithm such as bcrypt, scrypt or Argon2 — never plain hashes. Use short-lived access tokens with refresh tokens, validate input at boundaries, use parameterised queries, enforce authorisation on every request (not just authentication), keep secrets in a secrets manager, and log security-relevant events without logging secrets or personal data.
How the loop is weighted
Junior backend roles weight coding and fundamentals; mid-level roles add a full system design round; senior roles weight design, operational experience and influence. Across levels, the fastest way to stand out is a real story about a production incident you debugged and what you changed afterwards. See API design interviews and microservices interview questions.
Questions to ask the interviewer
Backend candidates learn a lot about a team from three questions: how often they deploy and how rollbacks work, what the last significant incident was and what changed afterwards, and how on-call is shared. Answers reveal operational maturity — whether a role means building on solid foundations or firefighting. They also show the interviewer you think about running software, not just writing it.
Practising
Answer these out loud, in two minutes or less each, and expect a follow-up on every claim. A free AI interview assistant such as CoPilot Interview can run backend questions as a mock interview built from your résumé and score each answer. Do one design question and one fundamentals discussion per day for two weeks, out loud.
Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly. Everything else on this page applies whichever tool you use, or none.
Frequently asked questions
What questions are asked in a backend engineer interview?
API design, SQL versus NoSQL, indexing and transactions, caching, idempotency, message queues, handling slow dependencies, rate limiting, scaling, authentication and security, monitoring, migrations and a system design question.
How do I prepare for a backend system design round?
Practise classic designs aloud — URL shortener, notification service, rate limiter, feed — covering requirements, estimates, data model, APIs, scaling, caching and failure handling.
What is idempotency in backend systems?
An operation is idempotent if repeating it has the same effect as doing it once. Idempotency keys let servers safely handle retried requests without duplicating side effects.
How important is coding in backend interviews?
Very — most loops include at least one coding round. But design, fundamentals and operational judgement increasingly decide mid-level and senior outcomes.
Practise on real interview questions
Run 145 real interview questions across 10 tracks, answer out loud and see a structured answer to compare with yours. Free, no signup.
Try a practice question