Backend Developer Interview Questions (2026) and How to Answer

Behavioural questions (1–10)

How you've handled real situations. Answer each with one true story, in STAR order.

1. 1.Tell me about an API you designed that other teams depended on.

   What they're really asking: Do you design for your consumers: versioning, clear errors, and never breaking them?

   Answer outline (STAR)

   • SituationAn internal or public API with several consuming teams.
   • TaskDesign it so it could evolve without breaking clients.
   • ActionA spec agreed first, consistent errors, a versioning and deprecation policy.
   • ResultAdoption, and a later change shipped without breaking anyone.

   Full sample answer (fictional example)

   At a logistics company I designed the shipments API that five internal teams and two partners used. I wrote the spec first, as OpenAPI, and shared it for two weeks of comments before writing code. I made errors consistent, with machine-readable codes, and agreed a policy: no breaking change without a new version and a 90-day deprecation notice. Eight months later I changed the address format for a new country and shipped it as v2 beside v1. No consumer broke, and the changelog told partners exactly what changed.

2. 2.Describe a database migration you ran on a large, live table.

   What they're really asking: Can you change data safely, without downtime or lost writes?

   Answer outline (STAR)

   • SituationA schema change on a table too big to lock.
   • TaskMigrate it with no downtime and no data loss.
   • ActionExpand and contract: add, dual-write, backfill in batches, switch reads, drop the old column.
   • ResultNo downtime, and the checks that proved the data matched.

   Full sample answer (fictional example)

   Our orders table had 300 million rows and we needed to split a status column in two. A normal migration would have locked it. I used expand and contract. First I added the new columns, then deployed code that wrote both old and new, then backfilled in batches of 10,000 rows overnight with a throttle on database load. I compared counts and checksums, switched reads behind a flag, and dropped the old column two weeks later. There was no downtime and no mismatch, and the runbook has been reused three times.

3. 3.Tell me about a time you made a slow system fast.

   What they're really asking: Do you measure first and fix the real bottleneck?

   Answer outline (STAR)

   • SituationAn endpoint or job too slow for users or its service-level target.
   • TaskFind where the time actually went.
   • ActionProfile and trace; fix N+1 queries, add an index or cache, batch calls.
   • Resultp95 latency before and after, and the alert that now guards it.

   Full sample answer (fictional example)

   The invoice list endpoint took 4.5 seconds at p95 against a one-second target. I traced requests and found the time went into one query per invoice line, an N+1 pattern, plus a missing index on the customer column. I replaced the loop with a single join, added the index, and cached each customer's totals for 60 seconds. P95 fell to 350 milliseconds. I added a dashboard panel, an alert at 800 milliseconds, and a test that fails if the endpoint issues more than five queries.

4. 4.Tell me about an incident caused by a dependency you didn't own.

   What they're really asking: Do you design for other systems failing?

   Answer outline (STAR)

   • SituationA third-party API or another team's service failed or slowed down.
   • TaskKeep your service up and stop the failure from cascading.
   • ActionAdd timeouts, retries with backoff and jitter, a circuit breaker and a degraded mode.
   • ResultHow the next outage of that dependency affected you, if at all.

5. 5.Tell me about a time you had to choose between shipping fast and building it properly.

   What they're really asking: Judgement: when is a shortcut fine, and when is it a trap?

   Answer outline (STAR)

   • SituationA launch date that left no time for the full design.
   • TaskShip on time without putting data or security at risk.
   • ActionThe shortcut you took, the one you refused, and how you tracked the debt.
   • ResultThe launch, and when and how the debt was paid back.

6. 6.Tell me about a design document that changed the plan.

   What they're really asking: Do you think before building, and can you write a case others can challenge?

   Answer outline (STAR)

   • SituationA project whose first design looked risky on paper.
   • TaskTest the idea cheaply before the team committed.
   • ActionWrite the doc, list alternatives and failure modes, collect comments for a week.
   • ResultThe change it caused, and the problem it avoided.

7. 7.Tell me about retiring an old endpoint or service.

   What they're really asking: Can you remove things without breaking the people who depend on them?

   Answer outline (STAR)

   • SituationAn endpoint still used by clients you didn't control.
   • TaskSwitch it off without an outage or an angry customer.
   • ActionLog usage, announce a date, contact heavy users, run a brown-out first.
   • ResultShutdown day, and what the logs revealed.

8. 8.Tell me about explaining a technical limit to a non-technical stakeholder.

   What they're really asking: Can you give a clear 'not yet' in business terms?

   Answer outline (STAR)

   • SituationA request, such as real-time data, the system couldn't cheaply support.
   • TaskExplain why, and find a version that works.
   • ActionUse an analogy and a cost, then offer two options with dates.
   • ResultWhat they chose, and how the relationship changed.

   Full sample answer (fictional example)

   Sales wanted live inventory on the website, to the minute. Our warehouse system could only export every 15 minutes. I explained it in their terms: the site would be showing a photo of the shelf, not the shelf. I offered two options with dates: a five-minute refresh in three weeks at low risk, or true real time in about four months with a vendor change. They chose the first, plus a 'low stock' message. Oversells fell sharply, and sales trusted our estimates more afterwards.

9. 9.Tell me about bad data that reached production.

   What they're really asking: Do you fix the data and its cause, and tell the people it touched?

   Answer outline (STAR)

   • SituationA bug that wrote wrong or duplicated records.
   • TaskRepair the data and stop it recurring.
   • ActionStop the writes, find the rows by query, restore from backup, add constraints.
   • ResultRecords restored, who was told, and the guard you added.

10. 10.Tell me about cutting infrastructure cost or load.

    What they're really asking: Do you notice waste, and cut it without hurting reliability?

    Answer outline (STAR)

    • SituationA cloud bill or database load that had crept up.
    • TaskReduce it without risking performance.
    • ActionFind the top costs, remove idle resources, tune queries, resize in steps.
    • ResultThe monthly saving, and the alert that watches it.

Technical and role-skill questions (11–22)

Can you do the work itself? Think out loud and name the trade-offs.

1. 11.How would you design a rate limiter for a public API?

   What they're really asking: A design staple: algorithm choice and state shared across servers.

   Answer outline

   • Clarify the limits (per user, key or IP); rejected calls get a 429 with Retry-After.
   • Compare token bucket, sliding window and fixed window counters.
   • Keep counters in Redis with atomic operations, and decide what happens when Redis is down.

2. 12.What does idempotency mean for an API, and how do you implement it?

   What they're really asking: Can you make retries safe, for payments and any write over a network?

   Answer outline

   • Applying the same request twice has the same effect as applying it once.
   • Clients send an idempotency key; the server stores the result and replays it for repeats.
   • GET, PUT and DELETE should be idempotent by design; POST needs the key.

   Full sample answer (fictional example)

   Idempotency means a request can be applied twice with the same effect as once, which matters because networks retry. For a payment, the client sends a unique idempotency key in a header. The server stores the key with the result the first time, and for any repeat returns the stored result instead of charging again. I'd keep keys for 24 hours, check and write in one transaction, and reject the same key with a different body. GET, PUT and DELETE are idempotent by design; POST needs the key.

3. 13.How do database indexes work, and when can one hurt?

   What they're really asking: Do you understand the cost of the queries you write daily?

   Answer outline

   • B-tree indexes turn full table scans into fast lookups and range scans.
   • Column order in a composite index matters; check the query plan with EXPLAIN.
   • Every index slows writes and takes space, so unused ones should go.

   Full sample answer (fictional example)

   An index is a sorted structure, usually a B-tree, that lets the database jump to rows instead of scanning the whole table, and it also speeds up range queries and sorting. For a composite index the column order matters: it helps queries that filter on the leading columns. I check with EXPLAIN that a query really uses it. Indexes cost something: every write updates each one, and they use disk and memory, so I drop the unused ones. A low-selectivity column, like a boolean, is rarely worth indexing alone.

4. 14.Explain transaction isolation levels and a bug each one prevents.

   What they're really asking: Can you reason about concurrent writes and anomalies like lost updates?

   Answer outline

   • Read committed prevents dirty reads, repeatable read prevents non-repeatable reads, serializable prevents write skew.
   • Several popular databases default to read committed, where lost updates are still possible.
   • Fixes: SELECT … FOR UPDATE, optimistic locking with a version column, or a stricter level.

5. 15.When would you use a message queue instead of a direct API call?

   What they're really asking: Tests asynchronous design: decoupling, back-pressure and delivery guarantees.

   Answer outline

   • Use a queue when the caller doesn't need the result now, or to absorb traffic spikes.
   • Explain at-least-once delivery, why consumers must be idempotent, and dead-letter queues.
   • Name what you've run (Kafka, RabbitMQ, SQS) and how you monitored consumer lag.

6. 16.How do you handle authentication and authorisation in a service?

   What they're really asking: Security basics: who is calling, and may they touch this record?

   Answer outline

   • Authentication proves identity (sessions, OAuth 2.0, signed tokens); authorisation decides what the caller may do.
   • Check permissions on the server for every resource, not only at the gateway.
   • Mention short token lifetimes, key rotation and never logging secrets.

7. 17.REST, GraphQL or gRPC: how do you choose?

   What they're really asking: Do you match the protocol to the clients, not to fashion?

   Answer outline

   • REST is simple and cacheable, and the default for public APIs.
   • GraphQL suits many different front ends, but caching and query cost are harder.
   • gRPC gives fast, typed service-to-service calls, with weaker browser support.

8. 18.How would you design a background job scheduler?

   What they're really asking: A design question on timing, retries and keeping a job from running twice.

   Answer outline

   • Clarify job types, delay precision and volume, then store jobs with a due time.
   • Workers claim jobs with a lease, so two never run one; expired leases are retried.
   • Add retry limits with backoff, a dead-letter list and lateness metrics.

9. 19.Why use cursor pagination instead of offset pagination?

   What they're really asking: Do you know why simple paging breaks on big, changing tables?

   Answer outline

   • Offset makes the database skip rows, so deep pages get slower.
   • Rows added or deleted between requests cause duplicates or gaps.
   • A cursor holds the last-seen key: stable, fast pages with an index.

   Full sample answer (fictional example)

   I'd avoid offset pagination on big tables. The database has to count and skip every earlier row, so page 5,000 is far slower than page 1. It's also unstable: if rows are inserted while someone pages, they see duplicates or miss items. Cursor pagination fixes both. I'd return a cursor encoding the last row's sort key, and the next request asks for rows after it. With an index on those columns every page costs the same. The trade-off is that users can't jump to page 40.

10. 20.What is connection pooling, and what goes wrong without it?

    What they're really asking: Practical database knowledge behind many production outages.

    Answer outline

    • Opening connections is costly, and the server allows only so many.
    • A pool reuses a fixed set and queues requests when all are busy.
    • Size it from the database limit and instance count, and set timeouts.

11. 21.What does the CAP theorem mean in practice?

    What they're really asking: Can you turn a famous idea into a real design choice?

    Answer outline

    • In a network partition you choose between consistency and availability.
    • A ledger favours consistency; a product catalogue can serve slightly stale data.
    • Name the choice you made in a real system and how it behaved in an outage.

12. 22.What would you log, measure and trace in a new service?

    What they're really asking: Do you build in the ability to see what the service is doing?

    Answer outline

    • Structured logs with request IDs, never secrets or personal data.
    • Metrics for rate, errors and duration, plus queue depth and pool use.
    • Traces across calls, and alerts on user-facing symptoms, not every CPU spike.

Take-home or live exercise: tips

Backend take-homes usually mean a small API with a database, tests and a README; live rounds add a design discussion.

• Model the data and the error cases before the endpoints, and keep the scope small.
• Test failure paths such as bad input and duplicate requests, not only the happy path.
• Note any shortcuts, such as no authentication, and what production would need.

Skills employers test for

Technical rounds follow the job ad. These skills are named most often in the 453 newest backend developer job ads we analysed (out of 2,945 live postings), shown as the share of ads that mention each. Expect questions on the top few.

1. 1AWS46%
2. 2Kubernetes44%
3. 3CI/CD43%
4. 4Java42%
5. 5Python35%
6. 6Code review32%
7. 7Docker32%
8. 8REST APIs32%

Full list: Backend Developer resume keywords.

From live job ads · computed November 2, 2026 · refreshed daily

Situational questions (23–30)

Scenarios that test judgement: say what you'd do first, and why.

1. 23.p99 latency doubles right after a deploy, but nothing in the diff looks related. What do you do?

   What they're really asking: Methodical diagnosis under pressure, and the willingness to roll back first.

   Answer outline

   • Roll back if users are affected; investigate afterwards.
   • Compare traces before and after: new queries, cache misses, a bumped library version.
   • Check config and infrastructure changes that went out at the same time.

   Full sample answer (fictional example)

   First question: are users affected? If p99 doubled for real customers, I roll back first and investigate afterwards. Then I compare traces before and after the deploy to see where the extra time sits: a new query, cache misses, a downstream call or a bumped library. I also check what else went out at the same time, such as config or a flag. If the diff still shows nothing, I look at traffic shape, because a deploy can coincide with a new customer or batch job.

2. 24.Product wants a report that joins data from two services' databases. How do you build it?

   What they're really asking: Do you respect service boundaries and data ownership?

   Answer outline

   • Don't read another service's database directly; it ties you to its schema.
   • Call its API, build a read model from its events, or use a warehouse.
   • Choose by how fresh the data must be; a nightly export may be enough.

3. 25.A partner sends duplicate webhooks, and some arrive out of order. How do you handle it?

   What they're really asking: Real-world integration robustness: deduplication and ordering.

   Answer outline

   • Deduplicate on the event ID and record the IDs you've processed.
   • Use timestamps or sequence numbers to ignore stale updates, or refetch the current state.
   • Acknowledge fast and process asynchronously, so the partner doesn't retry in a storm.

   Full sample answer (fictional example)

   I'd treat every webhook as 'at least once, in any order'. On receipt I'd verify the signature, write the event ID to a table with a unique constraint, and acknowledge at once with a 200, so the partner doesn't retry in a storm. A worker skips any ID it has already seen. For ordering, I compare the event's timestamp or sequence number with what we stored and ignore stale ones, or refetch the resource from the partner's API to get its current state.

4. 26.Your queue backlog is growing faster than consumers can process it. What do you do?

   What they're really asking: Capacity thinking: immediate relief, then the lasting fix.

   Answer outline

   • Find the cause: a traffic spike, a slow downstream service, or a poison message being retried.
   • Short term: scale consumers, pause non-urgent producers, dead-letter bad messages.
   • Long term, alert on consumer lag and add back-pressure or rate limits.

5. 27.Your database will run out of disk in two days. What do you do?

   What they're really asking: Calm triage: buy time first, then fix the cause.

   Answer outline

   • Buy time: add storage or delete data that is safe to remove, such as old logs.
   • Find what is growing: a table, log files or a runaway job.
   • Add early disk alerts and a retention rule, and plan partitioning or archiving.

   Full sample answer (fictional example)

   First I'd buy time: expand the volume if the platform allows it, or delete data that is safe to remove, like old logs. Then I'd find what is growing: usually a runaway job, a table with no retention, or replication lag holding logs. I'd fix that cause, then add disk alerts that fire with days of margin and a retention rule for the biggest tables. For the lasting fix I'd propose partitioning or archiving old rows, and tell the team what I found.

6. 28.Another team changes an API without warning and breaks your service. How do you respond?

   What they're really asking: Can you fix the incident first and the relationship after?

   Answer outline

   • Restore service first: pin the old version, add a shim or roll back your side.
   • Then talk with request logs, not blame, and agree how changes get announced.
   • Add a contract test so a breaking change fails their build, not your production.

7. 29.You find customers' personal data in application logs. What do you do?

   What they're really asking: Privacy instincts, and acting fast without making things worse.

   Answer outline

   • Tell your lead and the privacy contact now; don't just delete the evidence.
   • Mask the field, ship the fix, then purge or restrict the old logs.
   • Find how long it happened and who could read the logs, and add a scrubbing test.

8. 30.A manager wants a quick integration with a vendor whose API is unreliable. How do you approach it?

   What they're really asking: Do you protect the product from a dependency you can't control?

   Answer outline

   • Check the vendor's uptime history and rate limits before promising a date.
   • Wrap calls in timeouts, retries and a queue so a vendor outage stays contained.
   • Agree what users see when the vendor is down, and monitor the vendor separately.

Red flags to avoid in your answers

Each one is quick to fix before the day.

1. Describing a design with no failure modes.

   After each design, say what happens when the database, a queue or a dependency is down.

2. Saying 'it scales' with no numbers.

   Give rough figures: requests per second, data size, and where the first bottleneck would appear.

3. Treating incidents and on-call as someone else's job.

   Share a real incident: your part in it, the timeline and the change that followed.

4. Reaching for microservices or a new database by default.

   Justify each moving part by the problem it solves, and start from the simplest design that works.

How to prepare for a backend developer interview in 7 days

An hour or two a day is enough; the order matters more than the length.

1. 1

   Day 1: Read the job ad

   Note the database, broker and cloud named in the ad, and list the questions each could produce.

2. 2

   Day 2: SQL and indexes

   Write five queries on a sample database, check them with EXPLAIN, and explain one index.

3. 3

   Day 3: API design

   Design a small API on paper with errors, pagination, idempotency and versioning, then critique it.

4. 4

   Day 4: Failure and scale

   Design a job queue or rate limiter end to end, naming each failure mode and the retry rule.

5. 5

   Day 5: Incident stories

   Write two incidents in STAR form: timeline, your actions, and the fix that stopped a repeat.

6. 6

   Day 6: Mock and code

   Do a timed coding problem, then a 30-minute design with a friend; note skipped questions.

7. 7

   Day 7: Light review

   Reread your isolation-level and retry notes, prepare three on-call questions, then rest.

Questions to ask the interviewer

Pick two or three; the answers tell you whether you want the job.

1. Which databases and message brokers do you run, and who operates them?
2. How are API changes coordinated with the teams that consume them?
3. What does on-call look like, and how often does it page at night?
4. What's the hardest scaling problem you expect in the next year?
5. How do you test changes against production-like data?

Preparation tips

• Revise SQL properly: joins, indexes, EXPLAIN plans and transactions come up in most backend loops.
• Practise one design problem end to end, such as a job queue, with its failure modes.
• Prepare the story of a production incident you helped fix; backend interviewers almost always ask.
• Know your main language's concurrency model in detail: threads, async/await or goroutines.

Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.