Monday, June 15, 2026

28 Backend Developer Interview Questions (With Strong Answers)

Aaron Dsilva
Backend engineer sketching an API and database architecture during an interview

The best backend developer interview questions test how a candidate designs APIs, models data, handles concurrency, reasons about systems at scale and debugs production problems, plus how they work with a team. Below are 28 questions grouped by area, each with a note on what a strong answer shows, followed by a mini scoring rubric you can drop into your scorecard.

Pick four to six questions per interview based on the role, ask every candidate the same core set, and spend most of your time on follow-ups. The follow-up is where you learn whether a candidate has actually done the work or only read about it.

API design interview questions

  1. How would you design a REST API for a to-do app with users, lists and items? Strong answers show clear resource naming, sensible nesting, correct HTTP verbs and status codes, and a view on pagination and filtering.
  2. What does idempotency mean, and which HTTP methods should be idempotent? Look for a correct definition, awareness that PUT and DELETE should be idempotent, and a practical technique such as idempotency keys for POST requests like payments.
  3. How would you version a public API? Strong candidates compare URL, header and content-negotiation versioning, and talk about deprecation windows and communicating with consumers.
  4. How do you handle authentication and authorisation for an API? Expect a clear distinction between the two, familiarity with token-based approaches, token expiry and refresh, and checking permissions on every request rather than only in the UI.
  5. How would you design rate limiting for an API? Good answers mention an algorithm such as token bucket or sliding window, where limits are stored, per-user versus per-IP limits, and what response the client receives.
  6. What would you include in an error response? Look for consistent structure, a machine-readable code, a human-readable message, a request ID for tracing, and care not to leak internal details.

Database interview questions

  1. When would you choose a relational database over a document store? Strong answers are driven by data shape and access patterns, such as relationships, transactions and consistency needs, not by preference.
  2. How does an index speed up a query, and what does it cost? Look for an explanation of B-tree style lookups, the write and storage overhead, and when a composite index column order matters.
  3. A query that was fast last month is now slow. How do you investigate? Expect them to read the query plan, check for missing or unused indexes, look at data growth and consider locking or contention.
  4. Explain transaction isolation levels and a bug each one prevents. Strong candidates connect levels to concrete anomalies such as dirty reads, non-repeatable reads and phantom reads.
  5. What is the N+1 query problem and how do you fix it? Look for recognition of the pattern in ORM code and fixes such as eager loading, batching or a join.
  6. How would you run a schema migration on a large, busy table without downtime? Good answers describe expand-and-contract steps, backfilling in batches, and deploying code that works with both schemas.

Concurrency and reliability questions

  1. Two requests try to book the last available seat at the same time. How do you prevent double booking? Strong answers weigh database constraints, row locking, optimistic concurrency with version checks, and their trade-offs.
  2. What is a race condition, and how have you found one? Look for a real example, how it was reproduced and how it was fixed, not just a textbook definition.
  3. When would you move work into a background job? Expect criteria such as slow or unreliable external calls, work the user does not need to wait for, and retries with backoff.
  4. How do you make a background job safe to retry? Strong candidates talk about idempotency, deduplication keys and handling partial failure.
  5. What happens when a downstream service is slow or down? Look for timeouts, retries with limits, circuit breakers, fallbacks and sensible user-facing behaviour.

System design interview questions

  1. Design a URL shortener. Strong answers cover ID generation, storage, redirect latency, caching, analytics and abuse prevention, and state assumptions about scale up front.
  2. Design a notification service that sends email, SMS and push messages. Look for queues, per-channel workers, retries, user preferences and rate limits per provider.
  3. How would you add caching to a read-heavy endpoint? Expect discussion of what to cache, where, time-to-live, invalidation and the risk of serving stale data.
  4. How would you design a system for multiple customer organisations sharing one application? Strong candidates compare shared tables with a tenant column, separate schemas and separate databases, and discuss isolation, migrations and cost.
  5. How do you decide when to split a service out of a monolith? Look for reasons grounded in team ownership, scaling or deployment needs, and awareness of the operational cost of distributed systems.

Debugging and operations questions

  1. Error rates spike after a deploy. Walk me through your first 15 minutes. Strong answers prioritise impact: check dashboards, consider rollback early, then narrow the cause using logs and recent changes.
  2. What do you log, and what do you never log? Look for structured logs with request IDs and useful context, and a firm rule against logging passwords, tokens or personal data.
  3. Memory usage on a service grows steadily until it restarts. How do you find the cause? Expect profiling, heap snapshots, looking for unbounded caches or collections, and reproducing the pattern in a test environment.

Behavioural questions for backend developers

  1. Tell me about a production incident you were involved in. What changed afterwards? Strong answers show ownership, calm under pressure and a blameless focus on preventing recurrence.
  2. Describe a technical decision you disagreed with. What did you do? Look for respectful challenge backed by evidence, and the ability to commit once a decision is made.
  3. How do you review someone else's code? Good answers balance correctness, readability and security with kindness and clear, actionable comments.

Scoring rubric for backend developer interview questions

Score each answer on a four-point scale so every interviewer uses the same bar. Agree what each level means for the role and seniority before interviews start. Our guide to structured interview scorecards explains how to turn this into a template.

ScoreLabelWhat it looks like
4StrongCorrect, well-structured answer; raises trade-offs and edge cases unprompted; draws on real experience.
3SolidCorrect answer with sound reasoning; handles follow-ups with some prompting.
2PartialKnows the concept but misses important trade-offs or failure modes; struggles with follow-ups.
1WeakIncorrect or vague answer; cannot explain reasoning or give an example.

Keep notes on the evidence behind each score, not just the number. That makes debriefs faster and decisions easier to defend.

Tips for running the backend interview

  • Screen practical skills first. A short coding assessment before the interview means you can spend live time on design and trade-offs. See take-home vs live coding interviews for the pros and cons.
  • Anchor questions in your stack. Swap generic scenarios for ones that reflect your real systems.
  • Ask for examples. "Tell me about a time" follow-ups separate experience from theory.
  • Calibrate by level. The same question can serve a junior and a senior candidate; the expected depth differs.

For the wider process, from sourcing to offer, read our guide on how to hire software engineers.

How NirnAI helps you interview backend developers

NirnAI helps you turn a backend job description into a consistent, evidence-based process:

  • AI question generation from the job description: paste or upload the JD and NirnAI extracts the skills and seniority, then drafts role-specific MCQ, coding, open-ended and video questions. You review and edit before publishing, and can clone the assessment for future backend roles. Learn more about AI question generation.
  • Real coding questions: an in-browser editor with syntax highlighting, autocomplete and test cases in 9 languages, including Python, Java, Go, Ruby, Rust, TypeScript and C++.
  • Open-ended questions for design reasoning, such as how a candidate would approach idempotent payments or a zero-downtime migration.
  • Structured scorecards so every interviewer rates candidates against the same rubric.
  • Standard proctoring on every assessment, with an integrity score and flags for a human reviewer.

Hiring a backend developer soon? Start a 14-day free trial and generate your first backend assessment from the job description.

Frequently asked questions

How many questions should a backend developer interview include?
For a 45 to 60 minute technical interview, plan four to six main questions and leave time for follow-ups, since the follow-ups reveal the most. Spread them across areas the role needs, such as APIs, databases and debugging, and keep system design for a dedicated round with mid-level and senior candidates. Use the same core questions for every candidate for the role.
Should backend interviews include live coding?
A practical coding exercise is valuable, but it does not have to be live. Many teams use a short asynchronous coding assessment with test cases before the interview, then spend interview time discussing the candidate’s solution, trade-offs and how they would extend it. This reduces interview anxiety and gives you a richer conversation than watching someone type under pressure.
How do I adapt these questions for junior versus senior backend developers?
Use the same topics but change the depth. Junior candidates should explain fundamentals clearly, such as how an index speeds up a query or what an idempotent endpoint is. Senior candidates should discuss trade-offs, failure modes, scale and how they would guide a team through the decision. Adjust the scorecard expectations for each level before interviews begin.

Keep reading