Backend developer interviews focus on APIs, data, security and how your service behaves under load and when things fail. Expect questions on REST, authentication, databases and caching, then system design for experienced roles. These questions apply whether you work in Node.js, Java, Python, Go or .NET.
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
REST is a style for APIs where resources are identified by URLs, requests are stateless, and standard HTTP methods express the action. GET reads data and is safe and idempotent, POST creates, PUT replaces a resource (idempotent), PATCH partially updates it, and DELETE removes it (idempotent). Responses use status codes such as 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401, 403, 404 and 500.
Authentication checks who you are, for example with a password, an OTP or a Google login. Authorisation decides what you are allowed to do, using roles, permissions or ownership rules. In HTTP terms, 401 Unauthorized means you are not authenticated, and 403 Forbidden means you are authenticated but not allowed to do this action.
A process has its own memory space, so processes are isolated from each other. Threads live inside a process and share its memory, which makes them lighter to create but means shared data must be protected with locks to avoid race conditions. Node.js runs JavaScript on a single main thread with an event loop, so CPU-heavy work should go to worker threads or a separate service.
Middleware is a function that runs in the request pipeline before or after the route handler. Typical uses are logging, authentication, parsing request bodies, CORS, rate limiting and error handling. In Express a middleware receives (req, res, next) and either calls next() to continue or ends the response. It keeps these cross-cutting concerns out of every handler.
Applied problems, trade-offs and questions about your own projects.
Offset pagination (LIMIT 20 OFFSET 400) is simple but gets slow on large offsets and can skip or repeat rows when data changes. For large or fast-changing data I use cursor (keyset) pagination: the client sends the last seen id or timestamp, and the query uses WHERE id > :cursor ORDER BY id LIMIT 20, which is stable and uses an index. The response includes the next cursor, and I cap the page size.
An operation is idempotent if repeating it has the same effect as doing it once. Networks retry requests, so a non-idempotent POST can, for example, charge a customer twice. The usual fix is an idempotency key: the client sends a unique key with the request, the server stores the result for that key, and returns the same result for any repeat. PUT and DELETE are idempotent by design.
Never store passwords in plain text or with a fast hash like MD5 or SHA-256. Use a slow, salted, adaptive algorithm such as Argon2, bcrypt or scrypt. The unique salt per user defeats precomputed rainbow tables, and the cost factor makes brute force expensive. Around that I add rate limiting on login, multi-factor authentication, HTTPS everywhere, and responses that do not reveal whether an email exists.
Caching stores results somewhere faster, such as in memory, in Redis or on a CDN, to cut latency and database load. The common pattern is cache-aside: read from the cache, and on a miss load from the database and store it with a TTL; on writes, delete or update the key. The TTL limits how stale data can get. I also guard against a cache stampede, when many requests miss at once, using locks or slightly randomised expiry times.
System design, deep internals, leadership and tough follow-ups.
A monolith is simpler to build, deploy, debug and keep transactionally consistent, so it suits small teams and early products. Microservices allow independent deployment and scaling and let teams own services, but add network failures, distributed data, versioning and heavy monitoring needs. I usually start with a well-structured modular monolith and split out a service only when there is a clear boundary and a real scaling or team reason.
Every call gets a timeout. Transient failures are retried with exponential backoff and jitter, but only when the operation is idempotent. A circuit breaker stops calling the provider when it keeps failing, and I return a fallback or cached response where possible. Non-urgent work goes onto a queue so it can be processed later. I also add idempotency keys and alerts on the provider's error rate and latency.
A producer puts messages on a queue (like RabbitMQ or SQS) or a log (like Kafka), and consumers process them asynchronously. This decouples services, absorbs traffic spikes and makes retries easy, which suits emails, image processing and event-driven workflows. Most systems deliver at least once, so consumers must be idempotent. I add dead-letter queues for messages that keep failing, and in Kafka I rely on ordering only within a partition.
The API has POST /shorten, which returns a short code, and GET /:code, which redirects. Codes can be a base62 encoding of an auto-increment ID, or random 7-character strings with a collision check. Storage is a simple key-value mapping. Reads far outnumber writes, so popular codes are cached in Redis or at the CDN. Click analytics are recorded asynchronously through a queue, and I add rate limiting, link expiry and malicious-URL checks.