Backend Developer interview questions

How to approach thisOffset-based pagination (LIMIT/OFFSET) breaks down at scale because the DB still scans skipped rows. Use cursor-based pagination instead: return a cursor (encoded last-seen ID or timestamp) and use WHERE id > cursor LIMIT N. Discuss trade-offs: cursors prevent jumping to page N but are much faster.

How to approach thisREST is simple and cacheable but can over/under-fetch. GraphQL lets clients request exactly what they need but adds query complexity and caching challenges. gRPC uses Protocol Buffers for high-performance service-to-service communication but is not browser-friendly. Choose based on your clients and performance needs.

How to approach thisAccept an Idempotency-Key header from the client. Before processing, check if a request with that key already exists in a durable store. If yes, return the cached response. If no, process the request, store the result keyed by the idempotency key, then return. Use database transactions to prevent race conditions between concurrent duplicate requests.

How to approach thisN+1 happens when you fetch a list of N items, then run a separate query for each item to get related data (1 + N queries total). Solve with eager loading (JOIN or IN clause), batching (DataLoader pattern), or denormalization. ORMs often cause this silently, so always check your query logs.

How to approach thisShort term: auto-scaling, request queuing, graceful degradation (serve cached/stale data, disable non-critical features). Medium term: identify and optimize bottlenecks (DB connections, external API calls), add caching layers, implement circuit breakers. Long term: load test regularly and design for headroom.

How to approach thisPessimistic locking (SELECT FOR UPDATE) blocks other transactions from modifying the row. Optimistic locking uses a version column and checks it at write time (WHERE version = N), retrying on conflict. Pessimistic is safer for high-contention writes; optimistic scales better for read-heavy workloads with rare conflicts.

How to approach thisUse a queue when: the downstream service can be slow or unreliable, you need to decouple services, the work can be processed later (eventual consistency is acceptable), or you need to smooth out traffic spikes. Use synchronous calls when the caller needs an immediate response and the operation is fast.

How to approach thisLayer your caching: CDN for static assets, application cache (Redis/Memcached) for computed results, database query cache for frequent reads. Use cache-aside (read: check cache, miss hits DB, populate cache) for most cases. Invalidate on writes. Set TTLs to prevent stale data. Add cache stampede protection (locking or probabilistic early expiration).

How to approach thisPersist webhook events to a durable queue. Deliver with exponential backoff (retry on 4xx/5xx/timeout). Log every attempt. Mark as delivered only after receiving a 2xx response. Provide a UI for users to see delivery status and manually retry. Include an HMAC signature so receivers can verify authenticity.

How to approach thisCreating a new database connection is expensive (TCP handshake, auth, TLS). A connection pool maintains a set of reusable connections. The application borrows a connection from the pool, uses it, then returns it. This reduces latency and prevents exhausting the DB's max connection limit under load. Configure pool size based on expected concurrency.

How to approach thisDefine roles (admin, editor, viewer) and permissions (create:post, read:post, delete:post). Assign permissions to roles, roles to users. Check permissions in middleware before the route handler executes. Store the mapping in a database for flexibility. For complex cases, consider attribute-based access control (ABAC) or policy engines like Open Policy Agent.

How to approach thisAn index is a data structure (usually B-tree) that speeds up lookups by avoiding full table scans. Adding an index hurts performance on write-heavy tables because every INSERT/UPDATE/DELETE must also update the index. Too many indexes also consume memory and slow down vacuum/maintenance operations. Only index columns used in WHERE, JOIN, and ORDER BY clauses.