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 / 5 completed
1 / 5
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 / 5
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 / 5
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 / 5
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 / 5
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.
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 5 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.