Backend developers keep every modern application running. They build the APIs, manage the databases and protect the data behind each app you use. That is why companies hire for this role all the time and the interviews are tough.
Are you preparing for one such interview? This guide covers the most asked backend developer interview questions and answers in one place. We grouped them by topic and by level. You will find basic questions, database and security questions, framework questions and advanced system design problems. The last section covers scenario-based questions that test how you solve real production issues.
Use these answers as a base. Then add examples from your own projects. Interviewers trust real experience more than memorized lines.
Let's begin with the basics. These backend interview questions test your core knowledge and every fresher should know them well.
Backend development is the server-side part of a website or application that users cannot see or interact directly. It manages the invisible logic, databases, servers and API that make sure everything on the screen works properly.
For example, when a user logs in to a website, the backend can verify the user's email and password, check the database and send a response to the frontend. As a backend developer, I would make sure that the application works correctly, handles data securely and responds to user requests efficiently.
Client-server architecture is a system where a client sends a request to a server and the server processes that request and sends back a response.
For example, when I open a shopping website, my browser acts as the client. It sends a request to the server to load the products. The server can fetch the product details from the database and return them to the browser.
The frontend then displays the products to the user. This process allows the client and server to communicate and share data.
When I visit a website, there are several steps that happen behind the scenes.
Here are those steps:
As a backend developer, I would focus on processing requests, retrieving data, applying business logic and returning the correct response.
HTTP is the protocol that browsers and servers use to exchange data. It sends data as plain text, so anyone on the network can read it.
HTTPS is HTTP with TLS encryption. It encrypts the data, proves the server identity with a certificate and stops others from changing the data in transit. Every login page and payment page must use HTTPS. Search engines also prefer it.
An API endpoint is a URL where a client can send a request to reach a resource or an action. Each endpoint has a path, an HTTP method and a response format, which is usually JSON.
For example, GET /api/products returns a list of products and POST /api/orders creates a new order.
Code Example: Simulating a Simple API Endpoint
| const products = [ { id: 1, name: "Laptop", price: 50000 }, { id: 2, name: "Keyboard", price: 1500 }, { id: 3, name: "Mouse", price: 800 } ]; function handleRequest(method, path) { if (method === "GET" && path === "/api/products") { return { status: 200, data: products }; } return { status: 404, data: { message: "Endpoint not found" } }; } const response = handleRequest("GET", "/api/products"); console.log("Status:", response.status); console.log("Response:", JSON.stringify(response.data, null, 2)); |
REST organizes an API around resources. Each resource has its own URL and the HTTP method defines the action. GraphQL exposes a single endpoint and the client asks for the exact fields it needs.
| Aspect | REST | GraphQL |
| Endpoints | Many endpoints | One endpoint |
| Data returned | Fixed by the server | Chosen by the client |
| Over-fetching | Common | Rare |
| Caching | Easy with HTTP caching | Harder |
| Learning curve | Low | Higher |
| Best fit | Simple CRUD and public APIs | Complex screens with related data |
I pick REST for most standard APIs. I pick GraphQL when the frontend needs flexible data from many sources.
Database questions appear in almost every backend developer interview. Interviewers want to see that you can store data safely and fetch it fast.
SQL databases store data in tables with a fixed schema. They support joins and strong consistency. MySQL and PostgreSQL are common examples.
NoSQL databases store data in flexible formats such as documents, key-value pairs, or graphs. MongoDB and Redis are common examples.
I choose SQL for structured data and transactions, such as payments. I choose NoSQL when the schema changes often or when the system must scale across many servers.
A primary key uniquely identifies each row in a table. It cannot be null and it cannot repeat.
A foreign key is a column that points to the primary key of another table. It links the two tables and keeps the data valid. For example, orders.user_id is a foreign key that refers to users.id. The database will reject an order for a user that does not exist.
An index is a data structure, usually a B-tree, that helps the database find rows without scanning the whole table. It works like the index at the back of a book.
Indexes make reads much faster. They also slow down writes and use extra storage, because the database must update them on every insert and update. So I index the columns that appear often in WHERE, JOIN and ORDER BY clauses. I do not index everything.
ACID properties keep transactions reliable.
A bank transfer is the classic example. The debit and the credit must both succeed, or both must fail.
Normalization organizes data into separate tables to remove duplicates and avoid update errors.
Normalized tables save space and keep data consistent. However, they need more joins. So teams sometimes denormalize on purpose to speed up reads.
Replication copies the same data to multiple servers. It improves availability and read performance.
Sharding splits the data into parts and stores each part on a different server. It helps the system handle more data and more writes.
In short, replication gives you copies and sharding gives you partitions. Large systems often use both.
Opening a database connection takes time and resources. A connection pool keeps a set of open connections that the application reuses. A request borrows a connection, uses it and returns it to the pool.
This reduces latency and protects the database from too many connections. I set the pool size based on the database limit and the number of application instances. HikariCP and PgBouncer are popular tools for this.
I follow a clear process.
I always measure the query time before and after each change.
Security questions show whether you can build APIs that are safe in production. Expect these in every round, from freshers to senior levels.
Authentication checks who the user is. Authorization checks what that user can do.
When a user logs in with an email and a password, that is authentication. When the system checks whether the user can delete an order, that is authorization. Authentication always comes first. A user can be authenticated and still lack permission to open an admin page.
In session-based authentication, the server stores the session data and sends a session ID in a cookie. The server looks up the session on every request. You can revoke a session easily. However, you need shared storage, such as Redis, when you run many servers.
A JWT is a signed token that carries the user claims. The server only verifies the signature, so it needs no lookup. This makes JWT stateless and easy to scale. However, you cannot revoke a JWT before it expires. So I use short expiry times and refresh tokens.
I use sessions for classic web apps. I use JWT for APIs and microservices.
API versioning lets you change an API without breaking the clients that already use it. Mobile apps and partner systems often keep running old versions for months.
The common methods are URL path versioning (/api/v1/orders), header versioning and query parameter versioning. Most teams choose URL path versioning because it is simple and clear. I create a new version only for breaking changes and I give clients notice before I retire an old version.
Rate limiting caps the number of requests that a client can send in a fixed time window. It protects the API from abuse, brute-force attacks and traffic spikes.
Common algorithms include fixed window, sliding window, token bucket and leaky bucket. When a client crosses the limit, the server returns the 429 Too Many Requests status and often a Retry-After header. Limits usually apply per user, API key, or IP address.
CORS stands for Cross-Origin Resource Sharing. By default, a browser blocks a web page from calling an API on a different origin. An origin is the combination of protocol, domain and port.
CORS lets the server tell the browser which origins it trusts. For some requests, the browser first sends a preflight OPTIONS request. The server replies with headers such as Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers. If the headers do not match, the browser blocks the response.
I never use the * wildcard for APIs that handle cookies or sensitive data.
I also enforce HTTPS, hash passwords with bcrypt or Argon2, keep dependencies updated and give each service the least access it needs.
I validate every input at the edge of the application. I check the type, length, format and allowed values with a schema library such as Joi, Zod, or Pydantic. I reject bad input early with a 400 status and a clear message.
For errors, I return one consistent JSON format with an error code, a message and a request ID. I use correct status codes, such as 401, 403, 404 and 500. I log the full details on the server, but I never send stack traces to the client.
Code Example: Validating API Input
| function createUser(name, age) { if (typeof name !== "string" || name.trim() === "") { return { status: 400, message: "Name is required" }; } if (!Number.isInteger(age) || age < 18) { return { status: 400, message: "Age must be an integer of at least 18" }; } return { status: 201, message: "User created", user: { name: name.trim(), age: age } }; } console.log(createUser("Kylie", 25)); console.log(createUser("", 25)); console.log(createUser("Saachi", 16)); |
Most companies hire for a specific stack. So expect questions on Node.js, Spring Boot, or Django, along with general design questions.
Node.js is a JavaScript runtime that uses the Chrome V8 engine. It lets developers run JavaScript on the server.
Node.js uses a single-threaded, event-driven model with non-blocking I/O. When a task such as a database call takes time, Node hands it off and moves on to the next request. When the task finishes, the event loop runs the callback. This model suits I/O-heavy apps such as APIs and chat apps. CPU-heavy tasks block the event loop, so I move them to worker threads.
Asynchronous programming lets the program start a slow task and continue other work while it waits for the result.
Node.js supports three styles. Callbacks are the oldest style and they can create deeply nested code. Promises chain results and handle errors with catch. The async/await syntax makes asynchronous code read like normal code.
I use async/await with try/catch. I also use Promise.all to run independent tasks in parallel.
Code Example: Using Async/Await in Node.js
| function fetchUser() { return new Promise((resolve) => { setTimeout(() => { resolve({ id: 1, name: "Rahul" }); }, 1000); }); } async function main() { try { console.log("Fetching user..."); const user = await fetchUser(); console.log("User:", user); } catch (error) { console.error("Error:", error.message); } } main(); |
Middleware is a function that runs between the incoming request and the final route handler. It receives the request, the response and a next function. It can change the request, end the response, or pass control to the next middleware.
Common uses include logging, authentication, body parsing, CORS and error handling. Order matters because Express runs middleware in the order you define it. Error-handling middleware takes four arguments: err, req, res and next.
Spring Boot is a Java framework built on top of the Spring framework. It removes most of the manual setup. It offers auto-configuration, starter dependencies and an embedded server such as Tomcat.
With Spring Boot, a developer can build a production-ready REST API with very little configuration. It also provides Actuator for health checks and metrics. It supports dependency injection, Spring Data JPA and Spring Security. Many enterprises use it to build microservices.
Django is a high-level Python web framework. It follows the Model-View-Template (MVT) pattern.
The URL dispatcher maps each URL to a view. Django also ships with an admin panel, authentication and protection against SQL injection, CSRF and XSS. For APIs, developers add Django REST Framework.
I use a package manager such as npm, pip, or Maven. I lock exact versions with a lock file so every environment installs the same packages. I update dependencies on a schedule and scan them with tools such as npm audit or Dependabot.
For configuration, I never hardcode secrets or commit .env files. I keep settings in environment variables, with separate values for development, staging and production. For sensitive values, I use a secrets manager such as AWS Secrets Manager or HashiCorp Vault. I also check the required variables at startup, so the app fails fast when one is missing.
This layered structure separates responsibilities.
For example, the createOrder controller calls OrderService. The service checks the stock and applies the discount. Then it calls OrderRepository to save the order. This design keeps controllers thin, makes testing easy and lets me change the database without touching the business logic.
Once you pass the basics, interviewers test how you handle real problems. These backend developer interview questions for experienced candidates focus on concurrency, reliability and performance.
A race condition happens when two requests read and update the same record at the same time. One update then overwrites the other. I use these methods to prevent it.
I choose optimistic locking when conflicts are rare. I choose pessimistic locking when conflicts are frequent.
An idempotent API gives the same result when a client repeats the same request. GET, PUT and DELETE are idempotent by design. POST is not, so I add an idempotency key.
The client sends a unique key in a header such as Idempotency-Key. The server saves the key and the result in a database or Redis, with a unique constraint on the key. If the same key arrives again, the server returns the saved response and does not process the payment a second time. I also lock on the key, so two simultaneous requests with the same key cannot both run. Keys expire after a set time.
I use a queue such as RabbitMQ, Amazon SQS, or Redis with a tool like BullMQ or Celery. The API puts the job in the queue and returns right away. A worker picks up the job and runs it.
When a job fails, the worker retries it with exponential backoff. For example, it waits 1, 2, 4 and 8 seconds between tries. I add random jitter so many failed jobs do not retry at the same moment. I also set a maximum retry count. After that limit, the worker moves the job to a dead-letter queue (DLQ) for review. I set alerts on DLQ growth. I also make every job idempotent, because a retry can run the same job twice.
I never guess. I measure first.
After each fix, I run a load test to confirm the improvement.
I group related writes in one transaction with BEGIN, COMMIT and ROLLBACK. For example, when I create an order, I insert the order, reduce the stock and save the payment record in the same transaction. If one step fails, the database rolls back all of them.
I keep transactions short to reduce lock time. I choose the right isolation level for the use case. I also avoid calling external APIs inside a transaction. When the operations span multiple services, I use the Saga pattern or the outbox pattern instead.
I cache data that applications read often and change rarely. Caching can happen at the browser, the CDN, the application layer (Redis) and the database layer.
The most common strategy is cache-aside. The app checks the cache first. On a miss, it reads from the database and stores the result in the cache. Other strategies include write-through and write-behind.
For invalidation, I use a time-to-live (TTL) on every key. I also delete or update the key when the source data changes and I use versioned keys when needed. Cache invalidation is hard, so I keep TTLs short for data that changes often.
Code Example: Implementing a Simple Cache
| const cache = new Map(); const database = new Map([ [1, { id: 1, name: "Laptop", price: 50000 }], [2, { id: 2, name: "Keyboard", price: 1500 }] ]); function getProduct(id) { if (cache.has(id)) { console.log("Cache hit"); return cache.get(id); } console.log("Cache miss: fetching from database"); const product = database.get(id); if (product !== undefined) { cache.set(id, product); } return product; } console.log(getProduct(1)); console.log(getProduct(1)); |
I follow the test pyramid. I write many unit tests, fewer integration tests and a small number of end-to-end tests. Jest, Pytest, JUnit, Supertest and Postman are common tools. I run all tests in the CI pipeline before every merge.
Code Example: Writing a Simple Unit Test
| function add(a, b) { return a + b; } function testAdd() { const result = add(2, 3); const expected = 5; if (result !== expected) { throw new Error( `Expected ${expected}, but received ${result}` ); } console.log("Test passed"); } testAdd(); |
Senior interviews focus on design and trade-offs. Interviewers want to hear how you think, so explain your reasons along with your choices.
I start with stateless application servers behind a load balancer. Stateless servers let me add or remove instances at any time. I run them across multiple availability zones, with health checks and auto scaling.
For the data layer, I use a primary database with read replicas and automatic failover. I add sharding when one database can no longer handle the load. Redis and a CDN reduce the load on the database. Message queues handle slow work in the background. I also add rate limiting, circuit breakers, monitoring and alerts.
One million requests per day is only about 12 requests per second on average. So peak traffic and sudden spikes should drive the design, not the average.
In microservices, each service owns its database. So one ACID transaction cannot cover all of them. Two-phase commit works, but it is slow and lowers availability. Most teams avoid it.
The Saga pattern splits the workflow into local transactions. Each step publishes an event or a command. If a step fails, the saga runs compensating transactions that undo the earlier steps. For example, it can refund a payment if the stock reservation fails.
Sagas come in two styles. In choreography, services react to each other's events. In orchestration, a central coordinator controls the steps. I prefer orchestration for complex flows. I also use the outbox pattern for reliable events and I make every step idempotent. The result is eventual consistency.
I start with data, not assumptions.
For read-heavy load, I add read replicas and caching.
Local counters fail because each instance counts on its own. So I keep the counters in a shared store such as Redis.
I use the token bucket or sliding window algorithm. To avoid race conditions between a read and a write, I run the logic in a Lua script, so Redis executes it atomically. I build the key from the user ID, API key, or IP address and I set a TTL on it. I place the limiter at the API gateway to keep the rules consistent.
I also decide what happens if Redis goes down. Most public APIs fail open and switch to a small local limit. When a client crosses the limit, the API returns 429 with a Retry-After header.
I assume that every network call can fail.
I also run chaos tests to prove that the system survives real failures.
For deployment, I use rolling, blue-green, or canary releases behind a load balancer. Health checks and automatic rollback protect users. Feature flags let me release code without exposing the feature right away.
For database changes, I use the expand and contract pattern.
During a deployment, old and new code run together. So both versions must work with the schema. I also avoid long table locks by using online tools such as gh-ost for MySQL or CREATE INDEX CONCURRENTLY in PostgreSQL.
Scenario-based backend interview questions test your problem-solving skills. Do not rush to a fix. First explain how you would find the cause, then explain the fix, then explain how you would prevent it.
I would use idempotency at every layer.
I would also add a unique constraint on the order ID, so the database blocks a second successful payment for the same order.
First, I would measure. I would check APM traces, p95 and p99 latency, CPU, memory and database metrics. Most of the time, the database causes this problem. I would look for slow queries, missing indexes, N+1 queries, lock waits and an exhausted connection pool. I would also check slow external calls and a saturated thread pool.
Then I would fix the biggest bottleneck first. I would add indexes, tune the pool, cache hot reads with a short TTL, paginate results and move non-critical work to a queue. I would also scale the application horizontally.
To protect consistency, I would keep all writes on the primary database. I would send only read traffic that tolerates small delays to replicas or the cache. I would read critical data, such as stock at checkout, from the primary database. After the fix, I would run a load test and keep alerts on latency.
This bug is called an insecure direct object reference (IDOR), or broken object-level authorization.
Investigate:
Fix:
Prevent:
I would use a Saga with compensation and I would track the order with a state machine: PENDING, PAID, RESERVED, or FAILED.
To reduce this risk further, I would reserve the stock first with an expiry time. Then I would charge the customer and confirm the reservation.
Stabilize now:
I would not simply add more application instances at this point. Each new instance opens more connections, so that move can make the problem worse.
Redesign for the future:
This guide covered the most asked backend developer interview questions and answers, from basic concepts to advanced system design and real production scenarios. Do not just memorize the answers. Build a small project, break it on purpose and fix it. That habit helps you explain your choices with confidence.
Keep practicing, keep learning new tools and tie every answer to a real example. That is how you stand out in your next backend interview.
Focus on APIs, databases, authentication, caching and system design. Then study one language and its main framework in depth, such as Node.js, Spring Boot, or Django. Add basic knowledge of testing, deployment and monitoring.
Freshers should master the basics, such as HTTP, REST, SQL, indexing and authentication. Experienced developers should prepare for design trade-offs, performance tuning and production incidents. They should also prepare examples from their own work.
Yes, most companies include a coding or problem-solving round. Many also add a system design round for mid-level and senior roles. A final round often covers behavioral questions and team fit.
No single language is best. Java, Python, Node.js, Go and C# are all popular. Choose the language that matches the jobs you want and learn its framework and tools well.
