Backend Interview Questions (with real STAR answers)

POST creates a resource or triggers an action and is not idempotent. PUT replaces the whole resource at a known URL and is idempotent - sending it twice has the same effect as once. PATCH changes only some fields of a resource.

200 OK for success, 201 Created after creating a resource, 204 No Content for success with no body, 400 for bad input, 401 when the caller is not authenticated, 403 when they are authenticated but not allowed, 404 when the resource does not exist, 409 for a conflict, 429 for rate limiting, and 5xx only for server errors.

An index (usually a B-tree) lets the database find rows without scanning the whole table, which speeds up WHERE, JOIN, and ORDER BY on the indexed columns. Indexes cost disk space and slow down every INSERT, UPDATE, and DELETE, so add them for real query patterns and confirm with EXPLAIN ANALYZE.

The code runs one query to load a list, then one more query for each item in the list. With 100 items that is 101 queries. Avoid it with a JOIN, a single WHERE id IN (...) query, or the ORM's eager loading.

ACID is Atomicity (all or nothing), Consistency (constraints always hold), Isolation (concurrent transactions do not see each other's partial work), and Durability (committed data survives a crash). Isolation levels - Read Committed, Repeatable Read, Serializable - trade performance for protection against anomalies like non-repeatable reads and lost updates.

Offset pagination (LIMIT 20 OFFSET 1000) is simple but gets slower on deep pages and can skip or repeat rows when data changes. Cursor pagination uses the last seen value (WHERE id > last_id ORDER BY id LIMIT 20), so it stays fast and stable, but you cannot jump to a page number.

The server signs a token that contains claims such as the user id and expiry. Each request sends the token, and the server checks the signature and expiry without a database lookup. The downside is that a token cannot easily be revoked before it expires, so keep access tokens short-lived, use refresh tokens, and always pin the expected algorithm.

Authentication checks who you are (login, token, API key). Authorization checks what you are allowed to do (roles, ownership of a record). A failed authentication returns 401; a failed authorization returns 403.

A common choice is the token bucket: each client has a bucket that refills at a fixed rate, and each request takes one token; when the bucket is empty, return 429 with a Retry-After header. Keep the counters in Redis with atomic operations so all app instances share the same limits.

With cache-aside, the app reads from the cache first and, on a miss, reads the database and writes the result to the cache. Keep it correct with a TTL and by deleting the cache key when the data changes. Watch for a cache stampede, where many requests miss at once and all hit the database.

A unique key the client sends with a request, often in an Idempotency-Key header. The server stores the key with the result, and if the same key arrives again (for example a retry after a timeout) it returns the stored result instead of doing the action twice. This is standard for payments.

Most queues, such as SQS and Kafka, deliver at least once, so the same message can arrive twice after a retry or crash. The consumer must handle duplicates safely, for example by recording processed message ids or using upserts. Messages that keep failing should go to a dead-letter queue.

Choose a relational database such as Postgres when data has relations, you need transactions and flexible queries, which covers most apps. Choose a NoSQL store such as DynamoDB when access patterns are simple and known in advance and you need very high scale with predictable latency.

Confirm it with latency metrics and find which endpoint and when it started. Compare the release diff, then look at traces (for example OpenTelemetry) to see where the time goes - database, external call, or code. For the database, check slow query logs and EXPLAIN ANALYZE for missing indexes or N+1 patterns. Roll back if users are badly affected.

API: POST a long URL, get a short code; GET the code to redirect with 301 or 302. Generate codes with base62 encoding of a unique id or a random string with a collision check. Store code to URL in a database with a unique index, and put a cache such as Redis in front because reads far outnumber writes. Add rate limiting and expiry if needed.

Expect behavioral questions (tell me about a time you...), technical questions on APIs, databases, caching, authentication, and concurrency, and system design for mid and senior roles. Many companies also give a coding or take-home task. The questions on this page cover all of these.

Use STAR: Situation, Task, Action, Result. Keep it concrete - a specific incident, what you owned, what you did, and the result. The answers above are all structured this way.