Backend Developer Interview Questions and Answers

It depends on the operation. Reads are naturally idempotent, and so is a PUT that replaces a resource with an absolute value. The hard cases are POSTs that create something, like a payment. For those I require the client to send an idempotency key with each logical request. The server stores that key alongside the result in the same database transaction, so either both land or neither does. If the same key arrives again, I return the stored response instead of creating a second record. The key needs an expiry window, because the table would otherwise grow forever. I test it by firing the same request concurrently from two threads and asserting that exactly one record and one charge exist, and by killing the process mid-transaction to confirm the retry behaves correctly.

I first confirm the symptom and its start time, because a sudden change usually correlates with a deploy or a data threshold. Then I run EXPLAIN ANALYZE on the real query and compare estimated rows with actual rows; a large gap means stale statistics or a bad join order. I check whether the query still uses its index or has fallen back to a sequential scan because the planner decided the selectivity changed. Common causes are a table that crossed a size threshold, a new OR condition that broke index usage, a missing composite index for a new filter combination, or an ORM that started generating an extra join. I fix the cause, re-run the plan, and verify with production-scale data rather than a small development copy.

First I ask what happens if it runs twice. If the job sends an email, a duplicate is annoying; if it moves money, it is a bug. For anything dangerous I take a lock before starting, either a database advisory lock or a lease row with an owner and an expiry, so a crashed worker does not hold the lock forever. Inside the job I make each chunk idempotent and checkpoint its progress, so a restart resumes rather than reprocessing everything. In a multi-worker deployment I make sure the scheduler fires once, usually by having workers compete for the lease instead of relying on wall-clock cron on every instance. Finally I alert on stale locks and on runs that exceed their expected duration, because a silently stuck job is worse than one that fails loudly.

I start from the access patterns, not the technology. If the data is highly relational, if I need multi-row transactions, and if the queries are not fully known up front, a relational database is usually the better default because it lets me change my mind later with SQL. A document store makes sense when each record is read and written as a self-contained aggregate, the schema varies between records, and I need to scale writes horizontally without joins. A key-value store fits a cache or session lookup with a single access path. The trade-off I make explicit is that document stores push join logic into application code and make ad-hoc reporting harder, while relational databases make horizontal write scaling harder. I choose from the workload and name the cost.

I once deployed a change that added a NOT NULL column with a default to a large table, and the migration held a write lock for about ninety seconds during peak traffic. I raised it in the incident channel immediately, we rolled the migration back, and traffic recovered. The mechanism was that I had tested on a copy at a fraction of production size, so the lock looked negligible. I added a pre-migration check that requires a row-count estimate and a lock-duration test on production-scale data, and the team adopted the expand/contract pattern for schema changes. The lasting change for me was refusing to treat works-on-staging as evidence for anything that touches table locks.

I start by making sure authentication and authorization happen before any expensive work, because an unauthenticated endpoint that hits the database is the cheapest denial-of-service target. For rate limiting I key on the authenticated identity where possible, plus the route, because IP-based limits punish users behind a shared corporate network. I use a token bucket so normal bursts are allowed while sustained abuse is capped. I return 429 with a Retry-After header and rate-limit headers, so a well-behaved client backs off instead of retrying immediately. Expensive endpoints like password reset or data export get stricter limits and sometimes a challenge. Then I monitor 429 rates and adjust, because a limit that fires on normal traffic is a bug, not a success.

First I estimate the blast radius: row count, whether the change rewrites the table, and how long a lock would last on production hardware. I use the expand/contract pattern rather than a single big migration. Expand means adding the new nullable column or table and deploying code that writes to both; then a background job backfills in small batches with a throttle so replication lag stays acceptable; then I switch reads; then contract removes the old structure in a later release. Each step is independently deployable and reversible. I rehearse the whole sequence on a production-sized copy and watch lock wait times and replica lag. For very large tables I check whether the database supports online DDL or whether a shadow-table migration is safer.

Offset pagination is easy but it degrades and drifts: by page ten the database scans and discards thousands of rows, and if items are inserted while a user is paging they see duplicates or miss records. For large or fast-changing collections I use keyset pagination, where the cursor encodes the last sort key and the query filters with a greater-than condition on that indexed column. That keeps each page cheap regardless of depth. I make the sort deterministic by adding a tiebreaker like the primary key, because two rows with the same timestamp otherwise produce unstable ordering. I return an opaque cursor so the encoding can change later, and I document whether the client gets a stable snapshot or a live view. Deletions during paging are handled by tolerating a stale cursor and asking the client to refetch.

I cache data that is read far more often than it changes, and I choose the key from the access pattern, usually the identifier the client already uses. Then I make the staleness trade-off explicit: a short TTL is simple but occasionally serves old data, while explicit invalidation on write is fresher but adds coupling and a chance to forget a key. For most services I use a short TTL plus invalidate-on-write for records that must be correct immediately, such as a user's own profile. I also guard against a cache stampede when a hot key expires by using a lock or refreshing early in the background. Finally I watch the hit rate and the database load, because a cache with a low hit rate adds failure modes without buying much.

Include one incident where you owned the mitigation and the guardrail you added; backend interviewers trust candidates who can describe a real outage clearly.

State the schema decision, the index or the migration pattern, because data modeling is the area senior backend interviews dig into most.

Balance shipping with on-call, SLOs, runbooks and MTTR, since most backend teams screen for operational ownership before they screen for frameworks.