Most backend interview guides give you a list of questions and a paragraph of theory. That is not what gets people hired. Interviewers rarely care whether you can recite the definition of an index. They care whether you know when an index makes a query slower, and whether you can say so out loud without panicking.
So every question below comes with two things: an answer you can actually say in a room, and a short note on what the interviewer is really testing. Read the second part first. It is the part that changes how you answer everything else.
A word on the market before we start, because it shapes how hard these interviews now are. Between the second quarter of 2022 and the second quarter of 2025, the share of US tech job postings requiring 5 or more years of experience rose from 37% to 42%, while postings open to 2 to 4 years fell from 46% to 40%. Postings open to one year or less were just 18%. That is Indeed Hiring Lab data from July 30, 2025, and Indeed notes the tightening is specific to tech. The bar moved. Interviews are the place where it moved.
How Backend Interviews Are Actually Structured
Almost every backend loop breaks into 5 stages, and each one tests something different:
1. Screening
A recruiter or hiring manager checks that your experience matches the posting. Nothing technical is really being assessed. Be concrete about what you built and what broke.
2. Language and Fundamentals
Data structures, the language you claim on your CV, concurrency, error handling. This is the stage most people over-prepare for.
3. Databases and Data Modelling
Schema design, indexing, transactions, consistency. This is the stage most people under-prepare for, and it is where senior candidates separate themselves.
4. API and System Design
Design a service. Handle scale, failure, and change. Junior loops use a scaled-down version of this. Senior loops live here.
5. Behavioural and Ownership
What you did when the system went down at 2 a.m. Interviewers are checking whether you have ever owned something in production.
The questions below follow that order.
Core Backend Concepts
1. What actually happens when someone types a URL and presses enter?
DNS resolves the hostname to an IP address. A TCP connection opens, then a TLS handshake if the scheme is HTTPS. The client sends an HTTP request. A load balancer routes it to one of several application servers. The application resolves the route, runs your handler, probably queries a database or a cache, and returns a response. The connection is reused or closed.
What they're testing: whether you know there is a system between the browser and your function. Candidates who answer "the server returns the page" are telling you they have never debugged anything past their own code.
2. What is the difference between an API and a web service?
Every web service is an API, but not every API is a web service. An API is any contract that lets one piece of software call another. A web service is an API exposed over a network protocol, usually HTTP.
What they're testing: precision. This is a warm-up question and the only wrong answer is a vague one.
3. Explain idempotency and why it matters.
An operation is idempotent when running it 5 times leaves the system in the same state as running it once. GET, PUT, and DELETE should be idempotent. POST usually is not. It matters because networks fail, clients retry, and a non-idempotent payment endpoint that gets retried charges the customer twice.
What they're testing: whether you have thought about retries. Follow it up by mentioning idempotency keys, and you have just answered the next question before they asked it.
4. What is the difference between authentication and authorisation?
Authentication answers "who are you". Authorisation answers "what are you allowed to do". You authenticate once and authorise on every request.
What they're testing: nothing hard. But mixing these two up in a security discussion is a red flag out of proportion to how simple the distinction is.
5. When would you use a message queue instead of a direct API call?
When the caller does not need the result immediately, when the work is slow or expensive, when you need to absorb traffic spikes, or when you want the work to survive the consumer being down. Sending a welcome email is a queue job. Checking whether a username is taken is not.
What they're testing: whether you reach for queues by default (bad) or for a stated reason (good).
6. What is a race condition, and how do you prevent one?
Two operations read and write shared state without coordination, and the result depends on which finishes first. You prevent it with locking, with atomic database operations, with optimistic concurrency using a version column, or by removing the shared state.
What they're testing: whether you have hit one in production. If you have, say so and describe it. That story is worth more than the definition.
7. Explain the difference between horizontal and vertical scaling.
Vertical means a bigger machine. Horizontal means more machines. Vertical is simpler and has a ceiling. Horizontal has no practical ceiling but forces you to deal with statelessness, session storage, and data partitioning.
What they're testing: whether you know that horizontal scaling is a design constraint, not a checkbox.
8. What does stateless mean, and why do we want it?
A stateless service keeps no client-specific data between requests. Any instance can serve any request. That is what makes horizontal scaling, rolling deploys, and instance replacement possible.
9. What is the N+1 query problem?
You fetch a list of 100 records with one query, then loop over them and issue one query per record to load a relation. 101 queries where 2 would do. Object-relational mappers cause this silently. The fix is eager loading, a join, or a batched second query.
What they're testing: whether you have ever profiled a slow endpoint. This is the single most common real-world performance bug in backend code.
10. How do you decide what to log?
Log what you would need to reconstruct an incident: request identifiers, user identifiers, timing, and the inputs to any decision the system made. Do not log credentials, tokens, or personal data. Log at a level that stays useful at production volume.
Database Questions
11. When should you not add an index?
On a low-cardinality column, on a table with heavy write traffic where the index cost outweighs the read benefit, or on a query the planner already resolves efficiently. Indexes are not free. Every write updates them.
What they're testing: whether you understand indexes as a trade-off. Anyone can say "add an index".
12. Explain ACID.
Atomicity, consistency, isolation, durability. A transaction either fully happens or does not happen at all, it leaves the database in a valid state, concurrent transactions do not see each other's partial work, and once committed it survives a crash.
13. What is eventual consistency, and when is it acceptable?
Replicas converge on the same value given enough time without new writes. It is acceptable when a stale read is harmless: a follower count, a feed, a search index. It is not acceptable for an account balance at the moment of a withdrawal.
What they're testing: whether you can name the boundary. Candidates who say "eventual consistency is bad" and candidates who say "it is fine, everyone uses it" are both failing.
14. SQL or NoSQL, and how would you choose?
Choose based on access pattern and consistency need, not on volume. Relational databases handle structured data with relationships and multi-row transactions. Document and key-value stores handle high write throughput, flexible schemas, and access patterns known in advance. Most systems end up with both.
Worth knowing where the profession actually sits: in Stack Overflow's 2025 Developer Survey, PostgreSQL was used by 55.6% of all respondents and 58.2% of professional developers, ahead of MySQL at 40.5%. Redis reached 28% overall and 30.7% among professionals, which is consistent with caching being a production concern rather than a learning-project one.
15. What is database normalisation, and when would you denormalise?
Normalisation removes duplicated data so each fact lives in one place. You denormalise when the joins required to reassemble that fact cost more than the duplication does, usually on read-heavy paths. Denormalising is a deliberate decision with a maintenance cost, not an accident.
16. Explain database isolation levels.
Read uncommitted, read committed, repeatable read, and serialisable, in increasing order of strictness and decreasing order of concurrency. Each level removes a class of anomaly: dirty reads, non-repeatable reads, and phantom reads. Most databases default to read committed.
17. What is a deadlock, and how do you handle it?
Two transactions each hold a lock the other needs, and neither can proceed. Databases detect this and abort one. You reduce deadlocks by acquiring locks in a consistent order, keeping transactions short, and retrying on the specific deadlock error.
18. What is connection pooling and why does it matter?
Opening a database connection is expensive. A pool keeps a fixed set of connections open and hands them out. It matters because an unbounded number of application instances multiplied by an unbounded pool size will exhaust the database's connection limit, and the failure looks like a slow application rather than a database problem.
19. How would you design a schema for a chat application?
Users, conversations, a join table for conversation membership, and messages keyed by conversation with a timestamp. Index on conversation and timestamp because the dominant read is "the last 50 messages in this conversation". Consider partitioning messages by time once the table gets large.
20. What is a transaction, and when would you span one across services?
A transaction is a unit of work that commits or rolls back as one. You almost never span one across services. Distributed transactions are slow and fragile. Use a saga: a sequence of local transactions with compensating actions when a step fails.
API and System Design
21. What makes an API RESTful?
Resources identified by URLs, standard HTTP methods with their standard semantics, stateless requests, and representations the client can act on. Most APIs called RESTful are really HTTP APIs with sensible URL naming, and interviewers generally accept that as long as you know the difference.
22. How do you version an API?
In the URL path, in a header, or through content negotiation. Path versioning is the most common because it is visible and easy to route. The real answer is that the versioning mechanism matters less than having a deprecation policy and communicating it.
23. How would you design rate limiting?
Fixed window is simplest and allows bursts at the boundary. Sliding window is fairer and costs more to compute. Token bucket allows controlled bursts and is what most production systems use. Store counters in a shared cache so the limit holds across instances, and return the limit, remaining, and reset values in response headers.
24. What do you return when a request fails?
The correct status code, a stable machine-readable error code, a human-readable message, and a request identifier the caller can quote when they contact support. Never return a stack trace.
25. Design a URL shortener.
Take a long URL, generate a short key, store the mapping, and redirect on lookup. The interesting parts are key generation without collisions, the read-heavy access pattern that makes this a caching problem, and whether the redirect is permanent or temporary. Analytics turn it into a write-heavy problem too.
What they're testing: whether you ask about scale and read-write ratio before designing. Candidates who start naming technologies have skipped the only step that matters.
26. Design a rate-limited notification service.
Producers write to a queue. Workers consume, check per-user limits, and dispatch. Failures go to a retry queue with backoff and eventually to a dead-letter queue. Deduplicate on an idempotency key so a retried message does not send the same notification twice.
27. How would you handle a slow endpoint?
Measure before you change anything. Get timing for the handler, each query, and each external call. Then work outward: N+1 queries, missing indexes, synchronous calls that could be queued, oversized payloads, connection pool exhaustion, and cold starts. Fix one thing, measure again.
28. What is caching and where would you put it?
Storing a computed result so you do not recompute it. Options are in-process, a shared cache such as Redis, a CDN at the edge, or the database's own buffer cache. The hard part is not caching, it is invalidation: deciding when the cached value is wrong and what happens to requests during the gap.
29. What is a circuit breaker?
A wrapper around a call to a dependency that stops calling after a threshold of failures, fails fast for a period, then lets a trial request through. It stops one failing service from consuming all your threads and taking your service down with it.
30. How do you handle a schema migration with zero downtime?
Expand, migrate, contract. Add the new column without removing the old one, deploy code that writes to both and reads from the old, backfill, switch reads to the new column, then remove the old one in a later deploy. Never combine a schema change and a breaking code change in the same release.
Security Questions
31. How do you store passwords?
Hash with a slow, salted, purpose-built algorithm such as bcrypt, scrypt, or Argon2. Never encrypt, because encryption is reversible. Never use a general-purpose fast hash, because speed is the attacker's advantage.
32. What is SQL injection and how do you prevent it?
An attacker supplies input that changes the structure of your query. You prevent it with parameterised queries, always. Escaping by hand and input allowlists are defence in depth, not the fix.
33. Access tokens or session tokens?
Sessions are stateful: the server holds the record and can revoke instantly. Access tokens are stateless: the server validates a signature and holds nothing, which scales better but makes revocation hard before expiry. Short-lived access tokens plus refresh token rotation is the common compromise. Revocation is the trade-off almost every candidate forgets to mention.
34. What is CORS actually protecting?
It protects users from a malicious site making authenticated requests to another origin using their browser credentials. It is a browser policy, not server-side security. A permissive CORS policy does not expose your API to a determined attacker with a script, it exposes your users' sessions to a hostile web page.
35. How do you keep secrets out of your codebase?
Environment variables injected at deploy time, or a secrets manager. Never in the repository, never in the image, never in logs. Rotate anything that has ever been committed, because Git history is permanent.
Behavioural and Ownership Questions
36. Tell me about a production incident you handled.
Give the timeline: what broke, how you found out, what you checked first, what the actual cause was, and what you changed so it could not recur. If you have never had one, say so and describe the closest thing.
What they're testing: whether you have operated software or only written it. This is the question that most separates candidates with the same years of experience.
37. Tell me about a technical decision you got wrong.
Pick a real one with a real consequence, explain what information you were missing, and say what you would ask now. Candidates who cannot name a mistake sound either inexperienced or defensive.
38. How do you approach code review?
Correctness, then failure modes, then readability, then style. Say what you would change and why. Distinguish blocking comments from suggestions, because reviewers who do not signal that burn a lot of their team's time.
39. How do you handle a disagreement about architecture?
State the constraint you are optimising for, ask them for theirs, and see whether you disagree about the goal or the path. Most architecture arguments are people optimising for different things without saying so.
40. Why this role?
Have a specific answer about the systems, the scale, or the problem. Interviewers can tell the difference between someone who read the job description and someone who read the engineering blog.
How to Prepare Without Wasting a Month
Three things, in order.
Build something that fails.
Interviewers can tell within two questions whether you have run software in production. Build a service with real constraints: authentication, a database, error handling, rate limits, and a deployment. Then break it on purpose and fix it. Our backend projects exist for exactly this, with the frontend already built so you spend your time on the backend.
Practise saying answers out loud.
Knowing an answer and being able to give it under mild pressure are different skills, and only one of them gets tested. Talk through your reasoning while you solve, not after.
Go deep on databases.
Most candidates prepare language trivia and neglect data modelling, indexing, and transactions. The database section is where interviews are won at every level above junior.
If you are targeting Java roles specifically, our guide to Java interview questions that even 10 years of experience struggle to answer covers the language-specific layer this article deliberately skips. If you are earlier in the journey, start with how to become a backend developer. When you want timed practice with feedback, our mock interviews run the full loop.
Frequently Asked Questions
How Many Rounds Are in a Backend Interview?
Usually 4 or 5: a recruiter screen, a technical screen, one or two deep technical rounds covering coding and databases, a system design round, and a behavioural round. Junior loops often drop the system design round. Senior loops often add a second one.
What Should I Study First for a Backend Interview?
Databases. Indexing, transactions, and schema design come up at every level and are the most common weak spot. Language trivia is the easiest thing to prepare and the least differentiating.
Do I Need to Know System Design as a Junior Backend Developer?
You need to be able to reason about a small system out loud: what the components are, where the data lives, and what happens when one part fails. You are not expected to design a global service. You are expected not to freeze.
How Long Should I Prepare for a Backend Interview?
Long enough to have built and broken something real, which for most people is weeks rather than days. There is no credible published figure for this, and anyone quoting one is guessing. Prepare against the gaps you can name rather than against a calendar.
Are Backend Interviews Harder Than They Were?
For junior candidates, yes, by the available evidence. Indeed Hiring Lab found that in February 2025, US tech postings for standard and junior titles were down 34% from five years earlier, against 19% for senior and manager titles. Fewer junior openings means more candidates per role and a higher bar in the room.
Summary
Backend interviews test three things: whether you understand the system beneath your code, whether you can reason about data, and whether you have ever owned something in production. The 40 questions above map onto those three, and the "what they're testing" notes matter more than the answers.
Prepare by building a system with real constraints and real failure modes, go deeper on databases than feels necessary, and practise saying your reasoning out loud. That combination handles most of what a loop can throw at you, including the questions that are not on this list.