These backend developer interview questions cover the work of building and running a service: API design, data integrity under concurrency, authentication, background jobs, reliability and safe database changes. They are meant for engineering managers hiring backend engineers at any level, and for candidates who want to practice explaining production trade-offs. Each question shows what a good answer covers, with red flags where answers often fall short. Pick 6 to 8 questions. For senior candidates, lean on the scenarios and the incident question.
What a strong backend developer interview checks
- API design: clear contracts, correct status codes, pagination and idempotency.
- Data integrity: transactions, isolation levels and preventing race conditions.
- Security: authentication, authorization, tokens, password storage and secrets.
- Reliability: timeouts, retries, background work and observability.
- Operations: zero-downtime migrations, connection management and incident response.
Backend developer interview questions: API design
1. Which HTTP methods are idempotent, and how do you make a POST safe to retry?
What good looks like: GET, PUT and DELETE are idempotent by definition, meaning repeating the request has the same effect as sending it once. POST is not, and PATCH isn't guaranteed to be. To make a POST retry-safe, accept an idempotency key header, store the key with the result, and return the stored result if the same key arrives again.
2. Offset pagination or cursor pagination?
What good looks like: offset (LIMIT 20 OFFSET 10000) is easy and supports jumping to a page, but the database still walks past every skipped row, and inserts during paging cause skipped or repeated items. Cursor, or keyset, pagination passes the last seen sort key (WHERE id > last_id ORDER BY id), which stays fast and stable on large, changing tables. Most public APIs use cursors.
3. When would you return 400, 401, 403, 404, 409, 422 and 429?
What good looks like: 400 for a malformed request, 401 when the caller isn't authenticated, 403 when they're authenticated but not allowed, 404 when the resource doesn't exist (or to hide that it exists), 409 for a conflict like a version mismatch, 422 for well-formed input that fails validation, and 429 for rate limiting. 5xx codes mean the server failed, and 503 tells the client to try again later.
Red flag: returning 200 with an error message in the body for everything.
Data integrity and concurrency
4. Explain transaction isolation levels and the anomalies they prevent.
What good looks like: read committed prevents dirty reads, repeatable read also prevents non-repeatable reads, and serializable makes concurrent transactions behave as if they ran one at a time. Strong candidates know PostgreSQL defaults to read committed and MySQL's InnoDB to repeatable read, and that the lost-update problem can still occur at lower levels unless you lock or check versions.
5. Two buyers try to purchase the last item at the same moment. How do you prevent overselling?
What good looks like: make the check and the change one atomic step, such as UPDATE items SET stock = stock - 1 WHERE id = ? AND stock > 0, then check how many rows changed. Alternatives are a row lock with SELECT ... FOR UPDATE inside a transaction, or optimistic locking with a version column and a retry on conflict.
Red flag: read the stock, check it in application code, then write it back.
6. What is the N+1 query problem?
What good looks like: loading a list with one query, then running one more query per item to fetch related data, often hidden by an ORM's lazy loading. Fixes are eager loading, a join, or one batched query with WHERE id IN (...). Strong candidates detect it from query logs or tracing, not by guessing.
7. After updating a user's profile in the database, do you update the cache or delete the key?
What good looks like: deleting the key is usually safer. With two concurrent writers, "update the cache" can leave the older value in the cache. Deleting lets the next read refill it from the database. A short TTL limits the damage of any missed invalidation, and versioned keys help when many entries depend on one change.
Security
8. What's the difference between OAuth 2.0 and OpenID Connect, and what are common JWT mistakes?
What good looks like: OAuth 2.0 is for authorization, granting an app access to resources. OpenID Connect adds authentication on top, with an ID token that says who the user is. JWT mistakes include not verifying the signature or allowing unexpected algorithms, skipping checks on expiry, issuer and audience, putting secrets in the payload (it's only encoded, not encrypted), and long-lived tokens that can't be revoked. Short access tokens with refresh tokens are the usual answer.
9. How should passwords be stored?
What good looks like: with a slow, salted password hashing function made for the job, such as Argon2id, bcrypt or scrypt, using the library's recommended settings. Never plain text, never reversible encryption, and never a fast general hash like SHA-256 on its own. Add rate limiting on login and support for multi-factor authentication.
10. How do you handle secrets and configuration?
What good looks like: keep secrets out of the repository and the image. Load them at runtime from a secrets manager or injected environment variables, give each service only the secrets it needs, rotate them on a schedule, and make sure they never appear in logs or error messages.
Reliability and operations
11. When should work move off the request path into a background job?
What good looks like: when it's slow, can fail and be retried, or doesn't need to finish before replying, like sending email or generating a report. Queues usually deliver at least once, so handlers must be idempotent. Add a dead-letter queue for jobs that keep failing. To save a database change and publish an event reliably, use the outbox pattern: write the event to an outbox table in the same transaction, then publish from there.
12. Your service calls another service. How do you set timeouts and retries?
What good looks like: every network call gets a timeout shorter than the caller's own deadline. Retry only operations that are safe to repeat, with exponential backoff and jitter so clients don't retry in lockstep, and cap the retries. A circuit breaker stops calling a dependency that keeps failing so it can recover.
Red flag: unlimited immediate retries, which can turn a small outage into a big one.
13. What does good observability look like for a backend service?
What good looks like: structured logs with a request ID on every line, metrics for rate, errors and duration per endpoint, and distributed traces across services, often with OpenTelemetry. Alerts tie to user-facing service level objectives, not to every CPU spike.
14. How do you rename a column on a busy table without downtime?
What good looks like: expand and contract. Add the new column, deploy code that writes to both, backfill old rows in small batches, switch reads to the new column, stop writing the old one, then drop it in a later release. Avoid statements that lock the table for a long time, and in PostgreSQL build indexes with CREATE INDEX CONCURRENTLY.
15. Why use a database connection pool, and how do you size it?
What good looks like: opening connections is slow, and databases handle a limited number at once. A pool reuses connections. Size it from measurements and the database's limit across all app instances, not "as big as possible," since too many connections slow the database down. Signs of exhaustion are requests waiting on the pool while the database itself looks idle.
Practical scenarios
16. After a deploy, an endpoint's p99 latency jumps from 200 ms to 3 seconds. Walk me through it.
What good looks like: first decide whether to roll back, since it's often the fastest fix. Then compare traces before and after for that endpoint, check for new queries or missing indexes, look at dependency latency and pool waits, and review the diff. Confirm the fix with the same metric that showed the problem.
17. Build an endpoint that receives payment webhooks from a provider.
What good looks like: verify the provider's signature on the raw request body, return a 2xx response quickly, and put the event on a queue for processing. Store event IDs to ignore duplicates, and expect events out of order, so check the current state before applying a change. Have a way to replay missed events.
Behavioral (STAR)
18. Tell me about an incident you handled while on call.
What good looks like: a clear timeline, how they detected and narrowed the problem, how they communicated during it, the mitigation, and the follow-up work that stopped it happening again. Blameless language about others is a good sign.
19. Describe retiring an API that other teams or customers depended on.
What good looks like: they measured who still used it, announced a timeline, offered a migration path and help, watched usage drop, and only switched it off when traffic reached a safe level.
A simple scoring rubric
Running this interview with AI
For backend roles, NTRVSTA's exam library covers languages and runtimes such as Java, Python and Node.js, and you can customize the questions to your own stack. The AI interviewer runs the conversation live and adapts: a candidate who handles idempotency and isolation levels well gets pushed into retries, migrations and incident scenarios, while a weaker answer leads to simpler follow-ups instead of a dead end.
Each interview produces a score breakdown and video snippets of the answers that matter, ready to share with your backend lead. Read how AI interviews are scored before setting a cut-off, and compare tools in our AI interview software guide. Related sets: system design, SQL, Node.js and DevOps interview questions.
Questions
How is a backend interview different from a system design interview?
A backend interview checks how someone builds and runs one service well: correct APIs, safe data changes, auth and debugging. System design checks how many services fit together at scale. Mid-level hires need the first; senior hires need both.
Which language should a backend interview use?
Use the team's main language for any code, but keep most questions conceptual. Transactions, idempotency and retries work the same way in Java, Python, Go or Node, and a strong engineer can explain them in any of them.
What is the best signal of production experience?
Ask about incidents. People who have been on call describe timelines, dashboards, rollback decisions and follow-up fixes in detail. People who haven't tend to describe what should happen in theory.
If you'd like your backend first round to run itself, book a 20-minute demo and we'll show you a live adaptive interview, or try a sample interview yourself.
