5 exercises — choose the best-structured answer to common Backend API Developer interview questions. Focus on precise vocabulary, correct use of technical terms, and demonstrating real experience.
Structure for Backend API Developer interview answers
Name the trade-off explicitly: every mechanism choice (versioning, protocol, token type) has a cost
Explain the mechanism, not just the term: what idempotency, scopes, or DataLoader actually do
Name a real attack or failure mode: alg:none, double-charging, N+1 regression
Give a context-dependent rule, not a single blanket answer
0 / 18 completed
1 / 18
The interviewer asks: "How do you handle API versioning, and what are the trade-offs between URL versioning and header versioning?" Which answer best demonstrates API design judgment?
Option B is strongest: it gives specific trade-offs for both mechanisms including caching implications most candidates miss (proxies needing Vary configuration for header versioning), states a clear context-dependent default (URL for public APIs, header/content-negotiation for internal service-to-service) with the actual reasoning, and elevates the more important underlying discipline — additive-only changes and rare, signal-carrying version bumps with a deprecation window — above the mechanism choice itself. Key structure: URL versioning trade-offs (explicit, cacheable, but violates canonical URI) → header versioning trade-offs (clean, correct, harder to test/cache) → context-dependent default with reasoning → the real discipline: additive-only changes, rare bumps, deprecation window. Option C states a reasonable default but misses the caching nuance and the deeper additive-changes discipline. Option D sidesteps the actual technical question entirely, which is a weak answer for a role-specific technical interview.
2 / 18
The interviewer asks: "What is the difference between PUT and PATCH, and how does idempotency factor into your API design?" Which answer best demonstrates REST semantics knowledge?
Option B is strongest: it explains the omitted-field semantics of PUT precisely (cleared, not left unchanged — a common source of bugs), gives a concrete example of why PATCH can be non-idempotent (relative operations like increment), states a specific design practice to preserve idempotency (absolute values over relative operations) with the retry-safety reasoning, and introduces the idempotency key pattern for genuinely non-idempotent operations like payments — a concrete, production-relevant mechanism. Key structure: PUT semantics (full replace, omitted = cleared) → PATCH semantics (partial) → idempotency definition → concrete non-idempotent PATCH example → design practice to preserve idempotency → idempotency key pattern for non-idempotent operations. Option C correctly identifies the increment example but doesn't explain the omitted-field semantics of PUT or the idempotency key mechanism. Option D is accurate but surface-level and doesn't explain the "why" behind idempotency or give the payment/idempotency-key example.
3 / 18
The interviewer asks: "How do you secure an API using OAuth 2.0 and JWTs, and what are the common mistakes?" Which answer best demonstrates API security depth?
Option B is strongest: it correctly separates OAuth (the authorisation flow) from JWT (the token format) as distinct concerns, lists all four core validation checks with the specific real-world risk of skipping audience validation, explicitly distinguishes authentication (valid token) from authorisation (correct scope for this endpoint), and names three concrete, named attack patterns/mistakes (alg:none, localStorage XSS exposure, long-lived tokens) with the specific mitigation for each. Key structure: OAuth vs. JWT distinction → four validation checks with the audience-check risk called out → scope check separate from signature validity → three named real-world mistakes with mitigations. Option C covers the same practices accurately and concisely but doesn't explain the OAuth/JWT conceptual distinction or name the specific attack patterns. Option D under-specifies validation to signature-only, missing expiry, issuer, audience, and scope checks entirely — a real security gap.
4 / 18
The interviewer asks: "How do you diagnose and fix the N+1 query problem in a backend API?" Which answer best demonstrates database access pattern expertise?
Option B is strongest: it starts with a diagnostic discipline (confirm the pattern with query counting before assuming), correctly distinguishes when JOIN-based eager loading is appropriate versus when a batched IN-clause fetch is better (avoiding row duplication on one-to-many), explains why GraphQL is structurally prone to N+1 (independent per-field resolvers) and names the specific DataLoader mechanism (batch, deduplicate, defer to end of tick), and closes with a proactive regression-prevention practice (per-request query counter as a dev-time guard) rather than only reactive fixing. Key structure: diagnostic confirmation before fixing → JOIN vs. IN-clause distinction with reasoning → GraphQL-specific structural cause → DataLoader mechanism → proactive regression guard in development. Option C covers the same techniques accurately but without the diagnostic-first discipline or the proactive regression guard. Option D is a workaround, not a structural fix — caching doesn't address the root query-count problem and can mask it while introducing staleness risk.
5 / 18
The interviewer asks: "When would you choose gRPC over REST, and what are the trade-offs?" Which answer best demonstrates protocol-selection judgment?
Option B is strongest: it breaks gRPC's advantages into three distinct, precisely-explained mechanisms (binary encoding + type safety, HTTP/2 streaming modes, generated multi-language clients) rather than a single blended claim, names specific real-world trade-offs (browser accessibility requiring grpc-web, wire-level debuggability, schema coupling reducing independent evolution), and closes with a clear context-dependent decision rule (internal service-to-service vs. public/browser-facing) tied directly back to the trade-offs just described. Key structure: three distinct mechanisms explained separately → concrete trade-offs (browser access, debuggability, schema coupling) → context-dependent decision rule tied to the trade-offs. Option C covers the same ground accurately and concisely but with less depth on the four streaming modes and the schema-coupling trade-off specifically. Option D reduces the decision to raw performance alone, missing the real trade-offs (debuggability, browser access, schema coupling) that actually drive the decision in practice.
6 / 18
Code Review Comment: 'This endpoint returns a 400 error when the request body is empty. Consider adding input validation to ensure required fields are present before processing.' Which of the following best explains the developer's intention and the *most* appropriate response?
This comment highlights a potential issue with data integrity. Logging alone isn't sufficient; it doesn't address the root cause. The ideal response involves defining and enforcing validation rules to prevent invalid requests from reaching the API, demonstrating understanding of API contract enforcement and robust error handling. Option 1 introduces unintended behavior, while option 4 ignores the feedback.
7 / 18
Slack Message: '@johndoe - We're seeing a spike in latency on the user profile retrieval endpoint. Initial investigation suggests it's querying the `user_preferences` table for every request, even when users don't have any custom preferences. Can you look into optimizing this?' Which of the following actions would be MOST effective in addressing this issue?
The core issue is the N+1 problem. Simply caching the entire profile isn't a solution if the underlying data changes frequently. Optimizing the database query by utilizing an index and filtering directly in the SQL statement addresses the root cause of the performance bottleneck. Prometheus monitoring helps identify trends but doesn't solve the immediate problem.
8 / 18
PR Description: 'Implemented a new API endpoint for creating order items. The endpoint accepts JSON data in the request body, including fields like `product_id`, `quantity`, and `customer_id`. The response includes a 201 Created status code and the ID of the newly created item.' Which of the following statements best describes the key design considerations reflected in this description?
This description demonstrates adherence to RESTful design by clearly identifying the resource (`order items`), using appropriate HTTP methods (implicitly POST), and employing standard response codes. The JSON request body represents the payload for creating a new resource. The other options represent potentially flawed assumptions or deviations from best practices.
9 / 18
API Response (Example): `HTTP/1.1 200 OK Content-Type: application/json {
"status": "success",
"message": "User created successfully",
"user_id": 12345}
` Given this response, what is the MOST important consideration for ensuring its security and preventing unauthorized access?
While HTTPS is fundamental for overall security, verifying the `user_id` within the response is critical. This ensures that the application is processing data intended for the correct user, preventing potential identity theft or manipulation. Rate limiting addresses denial-of-service attacks, and obfuscating data does not add security.
10 / 18
Code Review Comment: 'This endpoint returns a 400 error when the request body is empty. Consider adding input validation to ensure required fields are present before processing.' Which of the following best explains the developer's intention and the *most* appropriate response?
This comment highlights a potential issue with data integrity. Logging alone isn't sufficient; it doesn't address the root cause. The ideal response involves defining and enforcing validation rules to prevent invalid requests from reaching the API, demonstrating understanding of API contract enforcement and robust error handling. Option 1 introduces unintended behavior, while option 4 ignores the feedback.
11 / 18
Slack Message: '@johndoe - We're seeing a spike in latency on the user profile retrieval endpoint. Initial investigation suggests it's querying the `user_preferences` table for every request, even when users don't have any custom preferences. Can you look into optimizing this?' Which of the following actions would be MOST effective in addressing this issue?
The core issue is the N+1 problem. Simply caching the entire profile isn't a solution if the underlying data changes frequently. Optimizing the database query by utilizing an index and filtering directly in the SQL statement addresses the root cause of the performance bottleneck. Prometheus monitoring helps identify trends but doesn't solve the immediate problem.
12 / 18
PR Description: 'Implemented a new API endpoint for creating order items. The endpoint accepts JSON data in the request body, including fields like `product_id`, `quantity`, and `customer_id`. The response includes a 201 Created status code and the ID of the newly created item.' Which of the following statements best describes the key design considerations reflected in this description?
This description demonstrates adherence to RESTful design by clearly identifying the resource (`order items`), using appropriate HTTP methods (implicitly POST), and employing standard response codes. The JSON request body represents the payload for creating a new resource. The other options represent potentially flawed assumptions or deviations from best practices.
13 / 18
API Response (Example): `HTTP/1.1 200 OK Content-Type: application/json {
"status": "success",
"message": "User created successfully",
"user_id": 12345}
` Given this response, what is the MOST important consideration for ensuring its security and preventing unauthorized access?
While HTTPS is fundamental for overall security, verifying the `user_id` within the response is critical. This ensures that the application is processing data intended for the correct user, preventing potential identity theft or manipulation. Rate limiting addresses denial-of-service attacks, and obfuscating data does not add security.
14 / 18
Sarah, a senior backend developer, leaves this comment on a code review for a new API endpoint:
'The response body doesn't include an error code when the input data is invalid. This makes it difficult to programmatically handle validation errors.' Which of the following best explains Sarah's concern regarding this code review comment?
Sarah's comment highlights the importance of API design principles. A well-designed API should always provide clear feedback to the client about the success or failure of a request, and including specific error codes (like HTTP status codes) alongside a descriptive response body allows clients to handle errors programmatically. Simply returning a 400 is insufficient without details on *why* it failed.
15 / 18
You receive the following Slack message from your team lead:
'@davidlee - We've observed increased latency when processing payments through our new API. The logs show a significant number of calls to the external payment gateway service are timing out, often during peak hours. What is the *most* important initial step you should take to investigate this issue?
While all options might eventually be relevant, immediately investigating resource utilization is the most critical first step. High latency in external services often points to a bottleneck – insufficient server capacity or network issues. Analyzing logs and circuit breakers are important later steps, but scaling resources addresses the immediate symptom.
16 / 18
Consider this example API response:
`HTTP/1.1 201 Created Content-Type: application/json {
"resource_id": 789012,
"status": "success",
"message": "Item created successfully.",
"created_at": "2024-10-27T10:30:00Z"}
`
What is the *primary* purpose of the `resource_id` field in this response?
The `resource_id` is a standard practice in RESTful APIs to return a unique identifier for the newly created resource. This allows clients to easily reference and manage the resource throughout subsequent interactions. The status code and date/time are separate pieces of information; the ID's purpose is uniquely its own.
17 / 18
You've drafted a PR description for a new API endpoint that allows users to update their profile information. The description reads:
'This PR adds an endpoint to allow users to modify their details. It uses the standard JSON format for request data and returns a success or failure message.' What additional information should be included in this PR description to improve its clarity and usefulness?
While security, performance, and architectural context are important, a clear PR description *must* include examples of request/response formats. This allows reviewers to quickly understand how to test the endpoint and identify potential issues related to data validation or response parsing – this is crucial for effective code review.
18 / 18
You're designing an API for a mobile application. The app needs to fetch user preferences (e.g., language settings, notification preferences) from the backend. Which of the following approaches would *generally* be most appropriate for this scenario?
For mobile apps frequently fetching small amounts of data (like individual preference settings), GraphQL is often a good choice. It allows the client to request only the data it needs, minimizing network overhead and reducing payload sizes – crucial for battery-constrained devices. REST might be overly verbose; gRPC is better suited for microservices communication.
What does "Backend API Developer Interview Questions — Best-Answer Practice" cover?
Practice answering Backend API Developer interview questions in professional English. 5 exercises covering API versioning, PUT vs PATCH idempotency, OAuth/JWT security, N+1 queries, and gRPC vs REST.
How many questions are in this interview set?
This set has 18 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.