Backend Engineer Technical Interview Questions & Answers (2026)

Resources: Users, Projects, Tasks, Comments. Core endpoints: POST /api/v1/projects (create project), GET /api/v1/projects (list with pagination: ?page=1&limit=20&sort=created_at), GET /api/v1/projects/:id (single project), PATCH /api/v1/projects/:id (partial update), DELETE /api/v1/projects/:id. Tasks nested under projects: GET /api/v1/projects/:id/tasks, POST /api/v1/projects/:id/tasks. Individual task: GET /api/v1/tasks/:id (flat URL for direct access), PATCH /api/v1/tasks/:id (status transitions, assignment). Filtering: GET /api/v1/tasks?status=open&assignee=user123&due_before=2025-04-30. Design decisions: PATCH over PUT for partial updates (clients send only changed fields). Consistent error format: {error: {code: 'TASK_NOT_FOUND', message: 'Task 123 not found', details: []}}. Status codes: 201 for creation with Location header, 204 for successful delete, 422 for validation errors, 409 for conflict (e.g., concurrent modification). API versioning via URL path (/v1/) for simplicity. Pagination returns: {data: [...], meta: {total: 150, page: 1, limit: 20, total_pages: 8}}. Authentication via Bearer token in Authorization header. Rate limiting via X-RateLimit headers.

An index is a data structure (typically B-tree) that allows the database to find rows without scanning the entire table. Think of it like a book's index — instead of reading every page to find 'PostgreSQL,' you check the index for the page number. When to create indexes: columns used in WHERE clauses frequently, JOIN conditions, ORDER BY clauses (covering indexes can serve the query entirely from the index), and foreign keys (PostgreSQL doesn't auto-index these). Composite indexes: for queries filtering on multiple columns, create a multi-column index following the left-prefix rule — index on (status, created_at) serves WHERE status='open' and WHERE status='open' AND created_at > X, but NOT WHERE created_at > X alone. When to avoid: columns with low cardinality (boolean 'is_active' with 95% true), tables with frequent writes and rare reads (write-heavy event logs — each INSERT must update every index), small tables (sequential scan is faster than index lookup for <1000 rows), and columns that are frequently updated (index maintenance overhead). Diagnosing missing indexes: EXPLAIN ANALYZE shows sequential scans on large tables. pg_stat_user_tables shows sequential scan counts. I'd monitor slow query logs and add indexes for the most frequent patterns.

Immediate response (minutes): enable auto-scaling if available to add more instances. If already at capacity, implement load shedding — return 503 with Retry-After header for non-critical endpoints while keeping critical paths (checkout, authentication) functional. Enable response caching at the CDN/reverse proxy level for read-heavy endpoints. Short-term (hours): identify the bottleneck. If it's the database, add read replicas and route read queries there. Enable query result caching (Redis) for expensive queries. If it's compute, horizontal scaling with a load balancer. Medium-term (days): implement rate limiting per user/API key to prevent individual users from consuming disproportionate resources. Add circuit breakers for downstream dependencies so one slow service doesn't cascade failures. Move non-critical work (sending emails, generating reports) to async queues (SQS, RabbitMQ). Long-term (architecture): implement caching at multiple layers (CDN for static assets, application cache for computed results, database query cache). Consider read/write splitting with CQRS for different access patterns. Add horizontal partitioning (sharding) for data that grows unboundedly. Implement back-pressure mechanisms so the system degrades gracefully under load rather than failing completely.

Transactions are atomic units of work that are either fully committed or fully rolled back (Atomicity). They move the database between valid states (Consistency), are isolated from concurrent transactions (Isolation), and survive crashes once committed (Durability). Isolation levels trade consistency for performance: Read Uncommitted: can see uncommitted changes from other transactions (dirty reads). Almost never used in practice — useful only for approximate analytics where precision doesn't matter. Read Committed (PostgreSQL default): only sees committed data, but the same query can return different results within a transaction if other transactions commit between reads (non-repeatable reads). Good for most OLTP workloads. Repeatable Read: same query returns the same results within a transaction, even if other transactions commit. Prevents non-repeatable reads but can have phantom reads (new rows appearing). Use for reports that must be consistent within a single execution. Serializable: strongest level. Transactions execute as if they ran one at a time. Prevents all anomalies but has the highest performance cost (more lock contention, more transaction retries). Use for financial transactions where correctness is paramount — transferring money between accounts must be serializable. In practice, I use Read Committed for 95% of operations, Repeatable Read for reporting queries, and Serializable only for critical financial operations. I also use explicit row-level locking (SELECT FOR UPDATE) when I need to prevent concurrent modification of specific rows without the overhead of Serializable.

Feed caching is challenging because feeds are personalized, time-sensitive, and involve complex ranking. I'd use a multi-layer approach: Layer 1 — User feed cache (Redis sorted set): pre-compute each user's feed as a sorted set of post IDs (score = ranking value). When a user requests their feed, read post IDs from cache and batch-fetch post content. TTL: 5 minutes. This handles the 'timeline' read path efficiently. Layer 2 — Post content cache (Redis hash): individual post data cached by ID with 1-hour TTL. Since many users see the same popular posts, this has high cache hit rates. Layer 3 — CDN for static assets (images, videos). Write strategy: fan-out on write for users with fewer followers (pre-compute their followers' feeds when they post). Fan-out on read for celebrity accounts (don't pre-compute 10M feeds — merge at read time). This hybrid approach (push for normal users, pull for celebrities) is what Twitter/X famously uses. Invalidation: when a user posts, push the post ID to their followers' feed caches. When a post is deleted, remove from all affected caches. For edits, update the post content cache and it naturally propagates. Cache warming: pre-populate active users' feeds during off-peak hours. For cold-start (no cache), fall back to database query with aggressive caching of the result. I'd monitor cache hit rate (target >95%) and cache latency separately from database latency.