Backend Developer Interview Questions & Answers

1. How would you design a REST API for a resource, and what makes it well designed?

Why they ask: API design is the daily surface of backend work. They want to see you reason about contracts, HTTP semantics, and evolvability — not just memorize verbs.

"I model the API around resources, not actions — noun-based paths, with HTTP verbs carrying intent: GET to read, POST to create, PUT/PATCH to update, DELETE to remove, and I keep GET safe and idempotent so it never mutates state. I use status codes precisely: 201 with a Location header on create, 400 for malformed input, 401 vs 403 for unauthenticated vs unauthorized, 404 for missing, 409 for a conflict, 422 for validation. Beyond the basics, a well-designed API is versioned from day one, paginates lists with cursors rather than offsets at scale, returns a consistent error envelope, and is idempotent where it matters — a retried POST shouldn't create a duplicate charge. I document it with an OpenAPI spec so the contract is explicit. My test is whether a new client engineer could integrate from the docs alone without asking me what a field means."

2. When would you choose a relational database over a NoSQL store, and vice versa?

Why they ask: A check that you pick storage from access patterns and consistency needs, not hype. The wrong choice here is expensive and hard to undo.

"I start from the access patterns and the consistency requirements, not a preference. I reach for a relational database like PostgreSQL when the data is highly relational, I need ACID transactions and strong consistency, and the queries are varied — money movement, orders, anything where a half-applied write is unacceptable. I reach for NoSQL when I have a known, narrow access pattern at very high scale, a flexible schema, or a need to scale writes horizontally: a document store for denormalized aggregates, a key-value store for cache and sessions, a wide-column store for massive time-series. The honest answer in most systems is both — a relational system of record for the data that must be correct, and a NoSQL layer for high-volume or cache-like workloads. The failure mode I avoid is picking NoSQL to dodge schema design and then reinventing joins and transactions badly in app code."

3. A query is slow in production. How do you diagnose and fix it?

Why they ask: Slow queries are the most common production performance problem. They want a methodical debugger who reads the plan, not someone who blindly adds indexes.

"I don't guess — I run EXPLAIN ANALYZE and read the actual plan. First I look for a sequential scan on a large table where a filter or join should use an index; that usually means a missing or unusable index — a function wrapped around an indexed column, an implicit cast, or a leading-wildcard LIKE that defeats it. I check that the index's leading columns actually match the query's filter and sort. I compare estimated vs actual rows; a big gap means stale statistics, so I run ANALYZE. Beyond indexing I look for N+1 patterns from an ORM, an unbounded result set that should be paginated, and lock contention. The fix is usually a targeted index, a query rewrite, or batching — and I add indexes carefully because every index slows writes. I validate by re-running EXPLAIN and confirming the plan changed and latency dropped, not just that it felt faster once."

4. What is a database index, and what's the cost of adding one?

Why they ask: Indexes are the first lever for read performance, and the most misused. They want to know you understand the read/write trade-off, not just "indexes make things fast."

"An index is a separate sorted data structure — usually a B-tree — that lets the database find rows by a key in logarithmic time instead of scanning the whole table. The cost is that every index has to be updated on every insert, update, and delete, so indexes speed reads but slow writes and consume storage. That's why I don't index everything: I index the columns that actually appear in WHERE clauses, joins, and ORDER BYs on hot queries, and I use composite indexes where queries filter on multiple columns — order matters, leftmost columns first. For high-cardinality lookups a B-tree is right; for low-cardinality or full-text needs I'd consider a different index type. I confirm an index is actually used with EXPLAIN, because an unused index is pure write overhead. On a write-heavy table I think hard before adding one."

5. How do you handle a race condition when two requests update the same record at once?

Why they ask: Concurrency bugs are subtle, intermittent, and brutal in production. They want to see you reach for real concurrency control rather than hoping it won't happen.

"A race condition is the lost-update problem — two requests read the same value, both act on the stale read, one silently overwrites the other, like two users buying the last item in stock. I match the control to the contention. Low contention: optimistic locking — a version column, and the update only commits if the version still matches what I read, otherwise I retry or return a conflict. High contention or a critical section: pessimistic locking — SELECT ... FOR UPDATE inside a transaction so the second request waits. For counters I push the work into the database as an atomic UPDATE instead of read-modify-write in app code. The principle is to make the check and the change one atomic operation the database guarantees, not to trust application timing. I keep transactions short so a lock doesn't become a deadlock or a throughput bottleneck."

6. What does idempotency mean, and why does it matter for a backend API?

Why they ask: Distributed systems retry. An engineer who doesn't design for idempotency ships double-charges and duplicate orders. It's a core distributed-systems instinct.

"An idempotent operation produces the same result whether it runs once or many times. It matters because networks are unreliable: a client sends a request, the response is lost, the client retries — and if the operation isn't idempotent, the retry double-charges a card or creates a duplicate order. GET, PUT, and DELETE are idempotent by HTTP semantics; POST is not, which is the dangerous one. For a POST that must be retry-safe, I require an idempotency key — a unique token the client generates and sends. The server stores the key with the result of the first success, and if the same key arrives again it returns the stored result instead of doing the work twice. That's exactly how payment APIs make a retried charge safe. Designing for idempotency is what lets clients, gateways, and queue consumers retry freely — which, in a distributed system, they will do whether you planned for it or not."

7. How and where would you add caching, and what can go wrong?

Why they ask: Caching is the highest-leverage and most footgun-prone performance tool. They want to hear you weigh staleness and invalidation, not just bolt Redis onto everything.

"I add caching only after I know the workload is read-heavy and the data tolerates some staleness, and I cache at the layer that gives the most leverage for the least risk — an in-memory or Redis layer for hot keys, HTTP caching with ETags at the edge for cacheable responses. My default pattern is cache-aside: read from cache, on a miss read the database and populate the cache with a sensible TTL. What goes wrong is mostly invalidation — serving stale data after a write — so I invalidate or update the cache on writes and lean on TTLs as a safety net. I also guard against a cache stampede, where a popular key expires and a flood of requests all hit the database at once, with request coalescing or jittered TTLs. The honest framing in the interview is that caching trades freshness for speed, and the engineering is in managing that trade deliberately."

8. When would you use a message queue instead of a synchronous call?

Why they ask: Async architecture separates a junior who chains synchronous calls from someone who decouples and absorbs load. They want to hear the trade-offs, not buzzwords.

"I use a message queue when the work doesn't need to finish before I respond to the user, when I want to decouple producer and consumer so one can fail or scale independently, or when I need to absorb a load spike by buffering rather than overwhelming a downstream service. Sending a welcome email or generating a thumbnail after signup is a perfect fit — the user shouldn't wait on it. The trade-off is that I give up immediate consistency and take on the complexity of retries, ordering, and at-least-once delivery, which means consumers have to be idempotent because a message can be delivered twice. I plan for failure with a dead-letter queue for poison messages and monitoring on queue depth. If the caller genuinely needs the result before responding — a payment authorization — I keep it synchronous. The decision is about whether the user must wait and whether the systems should be coupled."

9. Design a URL shortener. How would you approach it?

Why they ask: The canonical system-design warm-up. They're testing whether you clarify requirements, estimate scale, and reason about reads vs writes — not whether you memorized an answer.

"First I clarify requirements and scale: how many writes (new short links) and reads (redirects) per second, expected ratio — this is heavily read-dominant — and whether links expire or need analytics. For the core, I generate a short unique key per long URL: either a base-62 encoding of an auto-increment ID or a hash with collision handling. I store the key → long-URL mapping in a datastore keyed by the short code, which is a simple high-volume lookup that fits a key-value store well. Because reads vastly outnumber writes, I put a cache in front of the hot keys and serve the redirect with a 301/302. I scale reads with replicas and the cache, and shard by the short key if write volume demands it. I'd call out the trade-offs: 301 caches in browsers and reduces load but hurts analytics, 302 keeps every redirect visible. The point is to drive the design from the access pattern — tiny writes, massive cached reads."

10. How do you prevent SQL injection and handle authentication securely?

Why they ask: Security is non-negotiable for backend roles. They want reflexive correct habits — a candidate who hand-builds SQL strings or stores plaintext passwords is disqualifying.

"For SQL injection, the answer is reflexive: never concatenate user input into a query. I use parameterized queries / prepared statements so input is always treated as data, never executable SQL, and I validate and constrain input at the boundary as defense in depth. For authentication, I never store plaintext passwords — I hash them with a slow, salted algorithm built for it like bcrypt or Argon2, never a fast hash like MD5 or SHA-256 alone. For sessions I use signed, expiring tokens, scope them with least privilege, and keep secrets out of code and in a secrets manager. I also enforce HTTPS everywhere, rate-limit auth endpoints to blunt brute force, and treat every external input as hostile. The framing I bring is that security is a property of the defaults — if the easy path in the codebase is the safe path, the team stops shipping vulnerabilities by accident."

11. Tell me about a time you debugged a difficult production issue.

Why they ask: Production incidents are where backend engineers earn trust. They want someone who works from evidence and telemetry, stays calm, and prevents the recurrence.

S/T: "Our API's p99 latency started climbing and a fraction of requests began timing out, but only under load, and I needed to fix it before it triggered a wider outage. A: Rather than guess, I went to the telemetry — traces showed the time was spent waiting to check out a database connection, not running queries, which pointed at connection-pool exhaustion. I traced it to a code path that opened a transaction and then made a slow external API call while holding the connection, so under load every connection was tied up waiting on a third party. I moved the external call outside the transaction so the connection returned to the pool immediately, added a timeout on that call, and set an alert on pool saturation. R: Latency returned to baseline, the timeouts stopped, and the new alert later caught a similar regression before it ever reached customers."

12. Describe a hard technical trade-off you had to make.

Why they ask: Senior backend work is trade-offs, not right answers. They want to see you weigh options explicitly and own the decision, including its cost.

S/T: "We needed to ship a reporting feature fast, and the clean solution — a real event pipeline — was weeks of work we didn't have before a committed launch. A: I laid out the options to the team: build the pipeline now, or ship a nightly batch job that aggregated the data on a schedule. I argued for the batch job, because the reports only needed daily freshness and the pipeline's complexity wasn't justified yet. I made the trade-off explicit — we'd accept up-to-24-hour staleness now in exchange for shipping on time — and wrote a short doc so the decision and its known limits were on record, with a clear trigger for when we'd graduate to streaming. R: We launched on schedule, the batch job served fine for months, and when real-time demand finally appeared we replaced it deliberately instead of in a panic — because the limitation was a known, documented choice, not a surprise."

13. Tell me about a time you disagreed with a teammate on a technical decision.

Why they ask: Backend systems are built by teams. They want to see you push for the right answer with evidence and still keep the relationship and the team intact.

S/T: "A teammate wanted to introduce a new datastore for a feature, and I thought it added operational burden we didn't need. A: Instead of arguing in the abstract, I asked what specific problem the new store solved, and we found it was a query pattern our existing PostgreSQL could handle with a proper index and a small schema change. I prototyped that path and shared the numbers — comparable performance, no new system to operate, monitor, or back up. I made clear I'd back the new datastore if the data showed it was needed, so it was about the evidence, not winning. R: We kept the existing database, avoided adding a system to the on-call surface, and shipped faster — and because I'd engaged with his actual concern rather than dismissing it, the working relationship got stronger, not worse."

14. Tell me about a time you broke production — or shipped a bug that reached users.

Why they ask: The accountability question. They want someone who owns the mistake, fixes it cleanly, and turns it into a systemic safeguard — not someone who deflects blame.

S/T: "I deployed a migration that added a NOT NULL column without a default to a large table, and it took a lock that stalled writes — the app started erroring for users. A: I rolled back immediately to stop the bleeding rather than trying to fix forward under pressure, confirmed the service recovered, then communicated clearly to the team what happened. I reworked the change into a safe, backward-compatible migration — add the column nullable, backfill in batches, then add the constraint — and shipped it without downtime. R: The fix went out clean, and I turned the lesson into a guardrail: I wrote up our safe-migration pattern and added a CI check that flags risky schema changes, so the next person couldn't repeat my mistake. Owning it openly mattered more than the bug itself — that's how a team keeps trusting each other to deploy."

15. Why backend engineering — and why this role specifically?

Why they ask: Fit and genuine interest. A specific, researched answer beats "I like building things," and signals you understand the role and will stay.

"I'm drawn to backend because I like the part of the system where correctness and scale actually get decided — the data model, the consistency guarantees, the behavior under load. There's real satisfaction in a service that stays fast and correct while traffic grows and dependencies fail. I'm interested in this role specifically because you're handling genuinely high throughput and investing in reliability rather than treating it as overhead, which is exactly the kind of hard backend problem I want to own end to end. I also noticed you run PostgreSQL with an event-driven layer — that's a stack I've worked in and enjoy, and it tells me the team cares about picking the right tool rather than chasing the newest one. That's the environment where I do my best work."