yoklainterview sim
ProgressHistory

Backend Mid Interview Questions

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

Try the real simulation →

Sample questions

API DesignDifficulty 2
Which HTTP method is NOT idempotent?
  • aGET
  • bDELETE
  • cPOST✓
  • dPUT
Explanation:Idempotent means repeating the same request leaves the server in the same state as sending it once. POST typically creates a new resource on every call, so repeats multiply the effect. DELETE stays idempotent even when a repeat returns 404 — the resource is equally gone.
API DesignDifficulty 2
What is the difference between 401 Unauthorized and 403 Forbidden?
  • a401 means the user lacks permission for the resource; 403 means the request carries no valid credentials
  • b401 means missing or invalid credentials; 403 means the authenticated user lacks permission✓
  • cThey are interchangeable; picking one is a team style preference
  • d401 is used only for expired sessions; 403 only for banned accounts
Explanation:401 says "prove who you are" (an authentication problem), while 403 says "I know who you are, and you may not do this" (an authorization problem). Option (a) states it exactly backwards, which is the classic mix-up.
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 2
The stored user is {"name": "Ali", "email": "[email protected]"}. This request arrives:
PATCH /users/7
Content-Type: application/json

{"email": "[email protected]"}

With a correctly implemented PATCH, what happens to the name field?
  • aIt stays "Ali" — PATCH changes only the fields included in the request✓
  • bIt becomes null, because the request body did not include it
  • cThe request is rejected: PATCH requires the full resource representation
  • dIt is reset to the server-side default value defined for that field
Explanation:PATCH is a partial update: fields absent from the request are left untouched. Nulling omitted fields (b) describes what a full replacement with PUT would do — sending the incomplete object with PUT is exactly how data gets accidentally wiped.
API DesignDifficulty 2
A request body parses as valid JSON but violates a business rule (the birth date is in the future). The team wants clients to distinguish this from unparseable JSON. Which status-code split is the widely used convention?
  • a400 for both cases, because all client errors must share a single code
  • b422 for malformed or unparseable requests, 400 for well-formed but semantically invalid ones
  • c500 for validation failures, 400 for parse failures
  • d400 for malformed/unparseable requests, 422 for well-formed but semantically invalid ones✓
Explanation:The common convention: 400 when the server cannot even parse the request, 422 (Unprocessable Content) when it parses fine but fails validation rules. Option (b) is the same pair reversed, and 500 (c) would wrongly blame the server for the client's bad data.
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.

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