Interview guide
Backend Developer Interview Questions & Answers Guide (2026)
A hiring-manager’s interview kit for backend developers — with specific “what to look for” notes on every answer, red flags to watch, and a practical test.
Key facts
- Role
- Backend Developer
- Technical questions
- 15
- Behavioral
- 7
- Role-fit
- 5
- Red flags
- 8
- Practical test
- Included
How to use this guide
Pick 4-6 technical questions across difficulties, 2-3 behavioral, and 1-2 role-fit for a 45-minute interview. For senior roles, weight harder technical and role-fit higher. Always close with the practical test so you are hiring on evidence, not impressions. The “what to look for” notes are a scoring rubric: strong answers touch most points, weak answers miss them or replace them with platitudes.
Technical questions — Easy
1. Walk me through the OWASP Top 10 and which ones you have actually seen exploited or fixed in production.
EasyWhat to look for: Real stories on injection, broken access control, SSRF, or auth misconfigs. Should distinguish authentication from authorization. Red flag: recites list without examples.
2. What is the N+1 query problem? How have you detected and fixed it in a real codebase?
EasyWhat to look for: ORM lazy loading, solutions: eager load / JOIN, DataLoader batching (GraphQL), or a rewrite. Has used query log, APM, or test assertions to detect it.
3. How do you handle secrets in production? What is wrong with .env files in a repo?
EasyWhat to look for: Vault / AWS Secrets Manager / Doppler, rotation, least-privilege IAM, no plaintext in Git history, awareness of how to recover from a leaked secret (rotate, then audit access logs).
Technical questions — Medium
1. Walk me through how you would design an idempotent POST /payments endpoint that a mobile client might retry on flaky networks.
MediumWhat to look for: Client-generated idempotency key, a store (Redis or DB table) that maps key -> response with TTL, transactional handling so the write and the key land together, and a plan for partial failures. Red flag: "we just deduplicate by amount and user".
2. A query that used to return in 20ms is now taking 4 seconds in production. Walk me through diagnosis.
MediumWhat to look for: EXPLAIN ANALYZE first, check for seq scans, stale statistics (ANALYZE), index bloat, plan cache regression, parameter sniffing, row count growth, or a missing index on a new filter. Should mention pg_stat_statements.
3. How do you design an API versioning strategy that does not break mobile clients stuck on old binaries in the field?
MediumWhat to look for: URL versioning vs header versioning trade-offs, additive-only changes to v1, deprecation windows, telemetry to see who is still on old versions, and a policy for when to retire a version.
4. Compare REST, GraphQL, and gRPC. Given a new internal service-to-service call, which would you pick and why?
MediumWhat to look for: gRPC for internal, typed contracts, bidirectional streaming, low latency. REST for external/public. GraphQL for client-driven shape. No dogma. Talks about tooling cost.
5. A background worker occasionally processes the same job twice. Walk me through how you would debug and fix it.
MediumWhat to look for: At-least-once delivery is expected in most queues; the fix is idempotent handlers, not "turn off retries". Check visibility timeout, handler time, dead-letter behavior. Add an idempotency key or dedupe table.
6. How do you choose between caching in Redis, a read replica, or a materialized view for an expensive read?
MediumWhat to look for: Staleness tolerance, write amplification cost, cache invalidation complexity, consistency requirements. Good answers measure before adding cache.
7. Tell me about a production incident you led. What was the causal chain, and what guardrail did you ship afterward?
MediumWhat to look for: Specific narrative, owns the failure, describes both proximate and systemic cause, ships a concrete guardrail (alert, test, policy) not a vague "we will be more careful".
Technical questions — Hard
1. Explain PostgreSQL transaction isolation levels. When would you use Serializable, and what is the cost?
HardWhat to look for: Read Committed (default) vs Repeatable Read vs Serializable, phantom reads, SSI serialization failures, retry loops on 40001 errors. Good answer cites a real case where they needed Repeatable Read or Serializable for a correctness bug.
2. When would you choose a distributed lock (e.g. Redlock) versus a database transaction with SELECT FOR UPDATE?
HardWhat to look for: DB transaction when the contention is on a single table and you need ACID; distributed lock when coordinating work across services or over a resource that is not in the DB. Should acknowledge Redlock correctness debates and fencing tokens.
3. You need to backfill a new non-null column onto a 200M-row Postgres table without downtime. How do you do it?
HardWhat to look for: Add nullable, dual-write from app, batched backfill with throttling, verify, add NOT NULL via validated check constraint, drop temporary. Mentions pg_repack/gh-ost-style tools and rollback plan.
4. Design a rate limiter that protects a login endpoint against credential stuffing without locking out legitimate users.
HardWhat to look for: Per-IP + per-account, sliding window in Redis, progressive backoff, captcha at a threshold, account-lockout alerts, distinguish password guessing from enumeration.
5. A service is OOM-killed every few hours in production. Walk me through diagnosis.
HardWhat to look for: Heap profiling, leak detection, streaming vs buffering, connection pool sizing, container memory limits vs process limits, GC tuning. Should mention specific tools (pprof, clinic.js, VisualVM).
Behavioral questions
1. Tell me about a time you pushed back on a product decision because of a data-model or scale concern.
What to look for: Brought evidence (query plans, load test, capacity math), proposed alternatives, landed on a decision without ego. Not obstructionist.
2. Describe the worst production incident you caused or led response on. What did you learn?
What to look for: Owns the failure, describes root cause precisely, talks about follow-up guardrails. Avoids blame.
3. How do you write a PR description for a migration that touches a hot production table?
What to look for: Risk section, rollback plan, monitoring window, communicates blast radius, asks for a specific reviewer, includes the EXPLAIN.
4. Walk me through how you onboard yourself into an unfamiliar backend codebase.
What to look for: Reads README, runs it locally, traces one request end-to-end, draws a dependency graph, opens small PRs early to validate understanding.
5. When have you said no to a deadline, and how did you frame the conversation?
What to look for: Offers a scope/quality/date trade-off rather than "no". Communicates early. Shows data.
6. Tell me about a technical decision you made that turned out wrong. How did you unwind it?
What to look for: Shows self-awareness. Describes reversibility thinking, the exit plan, and what they would do differently.
7. How do you keep a junior engineer from shipping a migration that could take the site down?
What to look for: Pre-merge checklist, paired runbook review, staging rehearsal, treating their mistake as a process failure to fix, not a person to blame.
Role-fit questions
1. How do you feel about carrying a pager for services you own?
What to look for: Accepts it as part of ownership, has done it before, has opinions on paging thresholds and alert fatigue.
2. Our stack is NestJS + Postgres + Redis on AWS ECS. Any of that unfamiliar, and how would you ramp up?
What to look for: Honest gap assessment + concrete ramp plan (docs, small PR, pair session). Fakery is a red flag.
3. How do you operate with only 4 hours of timezone overlap with your US team?
What to look for: Long-form PR descriptions, batched Slack threads, Loom walkthroughs for complex reviews, protects overlap for blocking discussions.
4. What is your philosophy on tests — fast unit vs slow integration vs contract?
What to look for: Has a real opinion grounded in cost-vs-confidence, not dogma. Knows when to reach for Testcontainers, mocks, or contract tests.
5. Where do you sit on pragmatism vs purism when deadlines hit?
What to look for: Pragmatism with an explicit follow-up ticket for the debt; purism where it matters (security, data integrity).
Red flags
Any one of these alone is usually reason to pass, especially combined with weak answers elsewhere.
- • Cannot explain when to use a database transaction vs a distributed lock.
- • Treats "scale" as a vague goal without referencing RPS, latency percentiles, or data volume.
- • Recommends adding Redis cache before measuring where the bottleneck is.
- • Cannot walk through EXPLAIN ANALYZE output or does not know what a seq scan is.
- • Conflates authentication with authorization.
- • Has never written or rolled back a production migration.
- • Blames the ORM or the framework before suspecting their own query or data model.
- • Ships secrets in .env files committed to the repo and sees no problem with it.
Practical test
4-hour take-home: build a minimal URL shortener service with a REST API (POST /shorten, GET /:code, GET /:code/stats) backed by Postgres, with idempotent creation, per-IP rate limiting, and at least 60% test coverage on handlers. Ship it as a Docker Compose stack with a brief ADR explaining your choice of counter scheme, cache strategy, and how you would scale to 50K RPS. We grade on: correctness (30%), data model (25%), tests (20%), operational thinking in the ADR (25%).
Scoring rubric
Score each answer 1-4: (1) Misses most of the rubric or gives platitudes; (2) Hits some points but cannot go deep when pressed; (3) Covers the rubric and can defend the answer under follow-ups; (4) Adds unprompted nuance, trade-offs, or real examples beyond the rubric. Hire at an average of 3.0+ across technical, behavioral, and role-fit, with zero red flags, and a pass on the practical test.
Related
Written by Syed Ali
Founder, Remoteria
Syed Ali founded Remoteria after a decade building distributed teams across 4 continents. He has helped 500+ companies source, vet, onboard, and scale pre-vetted offshore talent in engineering, design, marketing, and operations.
- • 10+ years building distributed remote teams
- • 500+ successful offshore placements across US, UK, EU, and APAC
- • Specialist in offshore vetting and cross-timezone team integration
Last updated: April 12, 2026