Backend developer interviews - APIs, data, and reliability

By role - Guide

Server-side engineers interviewing for roles emphasizing services, data integrity, and production operations. Samples below are illustrative. Your kit is traced to the posting you paste.

Overview

  1. Backend Developer interviews are won by candidates who prepare from the posting they applied to - not from a generic list labeled "Backend Developer".

    This guide unpacks what hiring teams usually evaluate for this path, which JD phrases change your prep altitude, and how to revise when time is short.

  2. Typical evaluation themes include

    • API design, versioning, and authentication models
    • Database modeling, indexing, and transaction boundaries
    • Async processing, idempotency, and failure handling
    • Observability and on-call judgment

    Treat those as lenses: your answers should prove the requirements named in the job description, with short outlines instead of memorized speeches.

  3. Match depth to the stack in the posting.

    REST vs gRPC, SQL vs document stores, queues vs cron, Kubernetes vs managed PaaS - only the tools and constraints in the JD deserve night-before priority. If the role owns payments or identity, rehearse correctness and auditability language - if it owns high-throughput APIs, rehearse scaling and backpressure.

  4. Use the round map below to allocate prep time, then generate a kit from your exact JD for 20 traced questions, follow-ups, and outlines.

    The samples here are illustrative only.

What interviewers usually test

  1. API design, versioning, and authentication models

  2. Database modeling, indexing, and transaction boundaries

  3. Async processing, idempotency, and failure handling

  4. Observability and on-call judgment

Signals to read in your job description

  1. SQL/NoSQL stacks and ORM preferences

  2. Message queues, event streams, or batch pipelines

  3. Security: OAuth, secrets, PII handling

  4. Container orchestration and deployment cadence

How rounds differ

  1. Phone / recruiter screen

    Fit and must-haves for Backend Developer. Mirror the top JD requirements in one clean narrative.

  2. Role-core / technical

    API design, versioning, and authentication models

  3. Design / case / practical (if listed)

    Async processing, idempotency, and failure handling

  4. Hiring manager / final

    Observability and on-call judgment

Common prep mistakes

  1. Treating "Backend Developer" as one universal interview instead of reading seniority and domain in the JD

  2. Preparing adjacent skills while under-preparing: API design, versioning, and authentication models

  3. Skipping JD signal: SQL/NoSQL stacks and ORM preferences

  4. Answering with long theory and no decision, metric, or trade-off

  5. Memorizing sample questions from this page as if they were your real loop

  6. Skipping a crisp why-this-role story tied to the posting's outcomes

Last-hour prep playbook

  1. JD triage for Backend Developer

    Paste the full posting. Highlight must-haves, tools, domain words, and seniority verbs. Drop anything the JD never mentions.

  2. Round allocation

    Assign themes to phone vs deep vs final using the round map. Do not prep every topic at equal depth.

  3. Outline bank

    Write 5-point outlines for the highest-probability themes

    • API design, versioning, and authentication models
    • Database modeling, indexing, and transaction boundaries

  4. Follow-up pressure

    For each outline, answer why / what else / what would you change once out loud.

  5. Last-hour pass

    Skim outlines + JD highlights only. Generate or reopen your kit if you have one - avoid new rabbit holes.

20 interview questions with answer outlines

Practice set for this path: question, round, short answer outline, and a follow-up. Your kit is generated from the posting you paste - not copied from this list.

  1. How would you design a scalable REST API for a multi-tenant SaaS product?

    • Round: Technical / role-core. Answer outline: Tenant_id on every resource
    • JWT plus row-level checks so cross-tenant reads cannot leak.
    • Cursor pagination, ETags, and idempotency keys
    • URI versioning on all mutating public endpoints.
    • Shard by tenant_id - noisy-neighbor rate quotas and per-tenant traces catch hot write partitions. Follow-up: If that approach hit a hard limit, what would you change first?

  2. A database query suddenly starts timing out in production. How do you investigate?

    • Round: Technical / role-core. Answer outline: Confirm p99 latency, error rate, and recent deploys versus a single noisy tenant.
    • Compare EXPLAIN ANALYZE plans, missing indexes, sequential scans, and lock waits on pg_stat_activity.
    • Kill blockers, add a covering index or timeout - autovacuum bloat can mimic a code bug. Follow-up: If that approach hit a hard limit, what would you change first?

  3. Tell me about a time you improved an API that clients were struggling to use.

    • Round: Phone / early round. Answer outline: SDK clients retried POST /orders because 409 conflicts lacked a documented Idempotency-Key contract.
    • Added cursor pagination, RFC 7807 problem+json errors, and a six-week dual-run compatibility window.
    • Duplicate-order rate fell - one client still broke on undocumented null vs omitted fields. Follow-up: What would you do differently if you faced the same situation again?

  4. You need to roll out a breaking schema change with zero downtime. What is your plan?

    • Round: Phone / early round. Answer outline: Expand/contract: add nullable columns, dual-write both shapes, backfill historical rows, then flip readers.
    • Deploy writers that emit old and new fields before any consumer requires the new schema.
    • Drop old columns only after lag and checksums match - mixed-version replicas otherwise fail. Follow-up: What would you do differently if you faced the same situation again?

  5. Explain idempotency and why it matters for payment or webhook endpoints.

    • Round: Hiring manager / final. Answer outline: Same Idempotency-Key plus body hash yields one captured side effect even under retries.
    • Store key, request fingerprint, and result - replay returns the original status and payload.
    • Without it, timeout retries double-charge - mismatched bodies on a reused key must 409. Follow-up: How would you prove it worked in the first 30 days?

  6. How do you choose a partition key for a write-heavy events table?

    • Round: Technical / role-core. Answer outline: I choose partitions from append and query patterns, usually tenant plus time bucket.
    • Hash sub-shards distribute high-volume tenants and avoid status-only hot partitions.
    • I design split, merge, and idempotent replay before a tenant becomes dominant. Follow-up: If that approach hit a hard limit, what would you change first?

  7. Write a function to merge k sorted lists and discuss the complexity.

    • Round: Hiring manager / final. Answer outline: I seed a min-heap with each nonempty list's current head.
    • Pop the smallest node, append it, and push that list's next node.
    • The algorithm is O(n log k) with O(k) heap space - duplicates remain valid. Follow-up: How would you prove it worked in the first 30 days?

  8. Design an idempotent payment capture endpoint.

    • Round: Technical / role-core. Answer outline: I persist the key, request hash, and result atomically before processor submission.
    • Retries with the same key replay or await the original result - changed bodies return 409.
    • I log processor references, never card secrets, and reconcile ambiguous outcomes. Follow-up: If that approach hit a hard limit, what would you change first?

  9. What is the difference between PUT and PATCH on a REST resource?

    • Round: Technical / role-core. Answer outline: PUT replaces the addressed resource representation
    • PATCH applies a partial change.
    • I document omitted-field and null behavior because Merge Patch and JSON Patch differ.
    • PUT is usually idempotent - increment-style PATCH operations require explicit retry semantics. Follow-up: If that approach hit a hard limit, what would you change first?

  10. What does HTTP 429 mean, and how should a client retry?

    • Round: Technical / role-core. Answer outline: 429 means the server is limiting the client because a quota or capacity threshold was exceeded.
    • I honor Retry-After, then use jittered exponential backoff when retries remain appropriate.
    • Retried non-idempotent requests need keys - otherwise backoff can still duplicate writes. Follow-up: If that approach hit a hard limit, what would you change first?

  11. Why do backend services use database connection pools instead of opening a connection per query?

    • Round: Technical / role-core. Answer outline: Pools reuse database sessions, avoiding repeated TCP, TLS, authentication, and setup costs.
    • I cap total connections across instances below database capacity with administrative headroom.
    • Exhaustion appears as queueing or failure - leaked sessions can make healthy queries hang. Follow-up: If that approach hit a hard limit, what would you change first?

  12. What is the N+1 query problem, and how do you fix it?

    • Round: Technical / role-core. Answer outline: N+1 occurs when one parent query triggers an additional related query for every row.
    • I replace it with a join, eager load, or batched IN query.
    • APM query counts and traces prove the fix - an index alone leaves round trips intact. Follow-up: If that approach hit a hard limit, what would you change first?

  13. When should you add a B-tree index, and when does it hurt writes?

    • Round: Technical / role-core. Answer outline: I index selective WHERE, JOIN, and ORDER BY columns based on actual query plans.
    • Composite indexes serve their leftmost prefix, such as tenant then timestamp.
    • Each index adds write amplification, storage, vacuum, and backup cost. Follow-up: If that approach hit a hard limit, what would you change first?

  14. What is the difference between authentication and authorization in an API?

    • Round: Technical / role-core. Answer outline: Authentication establishes identity - authorization evaluates permitted actions on a resource.
    • The server checks token identity, scopes, tenant ownership, and object policy.
    • A valid token does not prevent IDOR - authorization must not trust client-selected identifiers. Follow-up: If that approach hit a hard limit, what would you change first?

  15. Why is SELECT * a problem in production queries?

    • Round: Technical / role-core. Answer outline: SELECT * fetches unnecessary columns, couples code to schema changes, and harms covering plans.
    • I select fields required by the handler and serializer explicitly.
    • Wide values cause extra heap or TOAST reads even when the caller needs only identifiers. Follow-up: If that approach hit a hard limit, what would you change first?

  16. When would you use Redis versus an in-process cache in front of Postgres?

    • Round: Technical / role-core. Answer outline: An in-process cache is fastest but isolated per instance and lost during deployment.
    • Redis shares entries and invalidation across replicas while adding network and operational cost.
    • I prevent stampedes with coalescing, locking, or staggered expiry and measure hit rate. Follow-up: If that approach hit a hard limit, what would you change first?

  17. When should foreign keys live in the database versus only in application code?

    • Round: Technical / role-core. Answer outline: Database foreign keys enforce referential integrity at the write boundary.
    • Application validation remains necessary across databases, asynchronous events, or external systems.
    • Deferrable constraints help transactions insert related rows in either order without weakening integrity. Follow-up: If that approach hit a hard limit, what would you change first?

  18. When do you use optimistic locking versus SELECT FOR UPDATE?

    • Round: Technical / role-core. Answer outline: Optimistic locking compares a version and rejects stale updates after low-contention edits.
    • SELECT FOR UPDATE serializes writers while holding row locks inside a transaction.
    • I use optimism for carts and pessimism for scarce inventory where overselling is unacceptable. Follow-up: If that approach hit a hard limit, what would you change first?

  19. How do you handle read-your-write consistency when the app reads from a replica?

    • Round: Technical / role-core. Answer outline: A replica can lag WAL after primary commit, so immediate reads may miss the write.
    • I route critical follow-up reads to primary or wait until a required LSN is replayed.
    • I monitor replay lag - stale uniqueness checks can create duplicate accounts. Follow-up: If that approach hit a hard limit, what would you change first?

  20. How does a token-bucket rate limiter work at the API gateway?

    • Round: Technical / role-core. Answer outline: A token bucket refills at a rate and permits bursts only while tokens remain.
    • I key limits by tenant, route, and identity, returning 429 plus Retry-After.
    • A global bucket alone lets one noisy tenant consume capacity meant for others. Follow-up: If that approach hit a hard limit, what would you change first?

FAQ

  1. What makes a strong Backend Developer interview answer?

    A clear structure, evidence tied to the posting, and honest trade-offs. Interviewers usually prefer concise outlines over polished essays that collapse under follow-ups.

  2. Should I memorize popular Backend Developer question lists?

    Use lists as pattern recognition only. Your probability mass lives in the JD - tools, domain, seniority, and outcomes. A JD-traced kit turns that into your specific practice set.

  3. How do I prep for Backend Developer with one day left?

    Triage the JD, pick the top themes, rehearse short outlines, and run one follow-up pass. Skip unrelated topics. Pair with last-minute interview prep guidance on our site.

  4. How is this guide different from the $2 kit?

    This guide explains the Backend Developer path. The kit is generated from your pasted job description: 20 questions, follow-ups, outlines, and 20 Foundational Questions unique to that posting.

  5. What should I do next?

    Paste your job description on the homepage for a free 3-question preview. If it matches, unlock the full kit and revise from that structure.

Related guides

  1. Software Engineer Interview Questions

  2. DevOps / SRE Interview Questions

  3. System Design Interview Questions

When you have a posting

  1. Get the right interview questions for the job you applied for by pasting the complete job description from the company's careers page - free preview, $2 for the full kit. No account needed. Paste the job description.