yoklainterview sim
ProgressHistory

Backend Senior Interview Questions

2166 verified Backend Senior interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

API DesignDifficulty 3
The same DELETE request is sent twice:
DELETE /orders/42   ->  204 No Content
DELETE /orders/42   ->  404 Not Found

The two calls return different status codes. Is DELETE's idempotency violated?
  • aNo — idempotency is about server state, and the order is equally deleted after both calls✓
  • bYes — an idempotent method must return the same status code on every repeat, not merely reach the same end state
  • cYes — the server should keep returning 204 until the client stops retrying
  • dNo — because DELETE was never an idempotent method in the first place
Explanation:Idempotency promises that repeating the request leaves the server in the same state, not that the response is byte-identical. After both calls the order is gone; the 404 merely reports that it no longer exists. Expecting identical status codes (b) is the most common misreading of the definition.
API DesignDifficulty 3
Two clients edit the same document. The server currently stores version: 5. This update arrives:
PUT /documents/12
Content-Type: application/json

{"title": "Final", "version": 4}

The request is based on a stale version. In this optimistic-locking design, which response fits best?
  • a200 OK — last write wins is the only workable policy for concurrent edits
  • b409 Conflict — the update is based on outdated state✓
  • c404 Not Found — version 4 of the document no longer exists on the server
  • d401 Unauthorized — the client's editing session has expired
Explanation:409 Conflict signals that the request clashes with the resource's current state — the standard answer for version mismatches; the client's remedy is to refetch the latest state and retry. Silently accepting it (a) would overwrite the other client's changes, which is precisely what optimistic locking exists to prevent. (c) misreads the version as a separate sub-resource.
API DesignDifficulty 3
While a client walks through pages using offset-based pagination, new rows keep getting inserted at the top of the list. Why does cursor-based pagination handle this better?
  • aThe cursor continues from a stable reference point (e.g., the last seen id)✓
  • bCursors make the database lock the table so no inserts can happen during pagination
  • cCursor pagination downloads the whole result once and pages through it in client memory
  • dOffset pagination cannot be combined with ORDER BY, so its results come back unsorted
Explanation:Offset counts rows from the start of the result, so each insert shifts everything and the client sees duplicated or skipped items between pages. A cursor anchors to the last returned item's stable key and asks for "what comes after it", so inserts at the top can't shift the next page. No locking is involved (b) — that would be unusable at scale.
API DesignDifficulty 3
A mobile app in production consumes your JSON API, and you cannot force users to update the app. Which change can you ship without releasing a new API version?
  • aRenaming the created field to createdAt for naming consistency
  • bAdding a new optional field avatarUrl to the response object✓
  • cChanging id from a JSON number to a string to support UUIDs
  • dMaking the previously optional phone field required in the create request
Explanation:Adding an optional response field is additive: well-behaved clients ignore unknown fields, so nothing breaks. A rename (a) makes the old field disappear, a type change (c) breaks parsers, and a newly required input (d) rejects requests that used to succeed — all three are breaking changes.
API DesignDifficulty 3
Before a cross-origin PUT request with a JSON body, the browser sends an OPTIONS request to the same URL on its own. What is this preflight request for?
  • aIt warms up the TCP connection so the real request completes faster
  • bIt downloads the endpoint's schema so the client can validate the payload
  • cIt asks the server whether the cross-origin method and headers are permitted before sending the real request✓
  • dIt authenticates the user in advance and stores a session cookie, so the upcoming PUT arrives already authorized
Explanation:Non-simple cross-origin requests — methods like PUT/DELETE, JSON content types, custom headers — trigger a preflight. The server answers with Access-Control-Allow-* headers, and only if they permit the request does the browser send the real one. It has nothing to do with performance (a) or authentication (d).
API DesignDifficulty 3
A payment API receives POST /payments. Network timeouts make clients retry, and some users end up charged twice. Which API design fixes double charging at the contract level?
  • aDocument that clients must never retry POST requests
  • bAccept a client-generated Idempotency-Key to deduplicate retries✓
  • cRate-limit each client to one request per minute so retries get rejected
  • dSwitch the endpoint to PUT, since PUT is idempotent by definition
Explanation:An idempotency key lets the server recognize a retry of the same logical operation and replay the stored response instead of charging again. "Just use PUT" (d) misunderstands the concept: PUT's idempotency comes from full-replacement semantics, which don't describe "create a new payment" — renaming the method deduplicates nothing. And (a) fights reality: timeouts make retries unavoidable.

Topics

API Design 75Caching 75Concurrency 75Csharp Concurrency Async 75Csharp Exceptions 75Csharp Generics Interfaces 75Csharp Memory Performance 75Csharp Stdlib Http 75Csharp Testing Tooling 75Databases / SQL 75Go Concurrency 75Go Errors 75Go Interfaces Generics 75Go Memory Performance 75Go Stdlib Http 75Go Testing Tooling 75Java Concurrency 75Java Exceptions 75Java Generics Interfaces 75Java Memory Jvm 75Java Stdlib Http 75Java Testing Tooling 75Messaging / Queues 75Networking / HTTP 75Nodejs Error Handling 75Nodejs Event Loop Async 75Nodejs Memory Performance 75Nodejs Modules Streams 75Nodejs Stdlib Http 75Nodejs Testing Tooling 75Php Concurrency Async 75Php Exceptions 75Php Generics Interfaces 75Php Memory Performance 75Php Stdlib Http 75Php Testing Tooling 75Python Concurrency Async 75Python Errors Context 75Python Memory Performance 75Python Stdlib Http 75Python Testing Tooling 75Python Typing Oop 75Security 75Testing 75

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview