Backend Engineer Interview Questions, With What to Listen For
A practical question bank across system design, databases, API design, and production debugging — each with what actually separates a strong answer from a memorized one.
Most interview question lists stop at the question. The harder part is knowing what a strong answer actually sounds like, so you're not just checking whether someone has memorized a pattern. Each question below includes what to listen for, built from what real production engineering work actually requires.
System design
These questions separate engineers who've designed systems from engineers who've only read about them.
Design a URL shortener that handles 10,000 requests per second.
What to listen for: A strong candidate asks clarifying questions first (read vs write ratio, custom aliases, analytics needs) before designing. Look for a sensible ID-generation approach (base62 encoding, not random collision-checking), a caching layer reasoning, and an honest discussion of trade-offs rather than a single 'correct' architecture recited from memory.
How would you design a rate limiter for an API?
What to listen for: Should mention at least one concrete algorithm (token bucket, sliding window, fixed window) and its trade-offs, where state lives (in-memory vs. a shared store like Redis for distributed systems), and what happens at the boundary (reject vs. queue vs. degrade). A candidate who only names an algorithm without discussing distributed-system implications hasn't actually built one at scale.
Walk me through how you'd scale a system that's starting to see database write bottlenecks.
What to listen for: Progression of options in rough order of complexity: indexing and query optimization first, then read replicas, then caching, then sharding or partitioning as a last resort — not jumping straight to 'shard the database' without ruling out simpler fixes. This question reveals whether someone over-engineers by default.
Databases & data modeling
Most backend bugs and performance problems trace back to the data layer, so this is worth probing directly.
When would you choose a NoSQL database over a relational one?
What to listen for: A real answer references actual access patterns (write-heavy, flexible schema, horizontal scale needs) rather than 'NoSQL is faster' as a blanket claim. Red flag: someone who treats this as a one-size-fits-all decision rather than workload-dependent.
Explain the N+1 query problem and how you'd fix it.
What to listen for: Should be able to describe the problem concretely (one query to fetch a list, then one query per item) and name at least one real fix (eager loading / joins, batching, a DataLoader-style pattern). This is a very common real-world bug, so a backend engineer with production experience should have hit it before.
How do you decide when a database needs an index, and what's the cost of adding one?
What to listen for: Good answers mention read/write trade-offs (indexes speed reads, slow writes, use disk space) and reference actually checking query plans (EXPLAIN) rather than adding indexes speculatively.
API design
How someone designs an API reveals how they think about the people who'll consume it.
How would you design a REST API for a resource that supports partial updates?
What to listen for: Should know the practical difference between PUT (full replace) and PATCH (partial update), and ideally mention idempotency and how to handle concurrent updates (optimistic locking, versioning) if the role calls for it.
How do you handle API versioning when you need to make a breaking change?
What to listen for: Look for awareness of real strategies (URL versioning, header versioning) and, more importantly, judgment about minimizing breaking changes in the first place and communicating a deprecation timeline to consumers.
Debugging & production ownership
This is where you learn whether someone has actually operated a system in production, not just built one.
Tell me about a production incident you were involved in. What happened, and what did you do?
What to listen for: Specificity is the whole signal here. A real incident has a messy middle (wrong initial hypothesis, a rollback that didn't fully work, a second cause found later) — a suspiciously clean story ('found it immediately, fixed it, done') is worth probing further.
How would you debug a service that's intermittently timing out under load?
What to listen for: Should reference actual tools or techniques (logs, metrics/dashboards, distributed tracing, load testing to reproduce) rather than guessing at a cause. Strong candidates narrow the hypothesis space systematically instead of jumping to a fix.
Build the shortlist before the interview
Post your role free and let AI rank applicants against your JD, so these questions go to candidates worth asking them.
Post a Role FreeFrequently asked questions
How many interview questions should a backend engineer interview cover?
For a single 45–60 minute technical round, 2–4 questions with real depth beat 8–10 shallow ones. Pick one from system design, one from the data layer, and one debugging/production question, and spend most of the time on follow-ups rather than racing through a checklist.
Should junior and senior backend engineers be asked different questions?
The same question can work for both levels — what changes is the depth of a strong answer. For a junior candidate, a correct, reasoned approach to the URL-shortener question is a good sign. For a senior candidate, you'd expect them to proactively raise trade-offs, failure modes, and scaling considerations without being prompted for each one.
How do I tell a memorized answer from real understanding?
Ask a follow-up that isn't in the standard version of the question. If someone recites a textbook system-design answer, ask what happens if traffic is 100x higher, or if a specific component fails. Genuine understanding adapts to the new constraint; a memorized answer often breaks down or repeats the same points.
Are take-home assignments better than live coding interviews?
Each has trade-offs. Take-homes reduce interview-day anxiety and let someone work in a familiar environment, but add hours of unpaid work and can be gamed with outside help. Live coding and pairing exercises are faster to run and harder to fake, but can disadvantage people who think better without someone watching. Many teams use a short live exercise plus a focused system-design conversation rather than a multi-hour take-home.
How does AI candidate ranking relate to interview questions like these?
They solve different problems. AI ranking on Switchly scores an applicant's resume and profile against your job description to help you build a shortlist faster. The interview itself — including questions like these — is still where you verify that the person on paper is the person in the room. Neither replaces the other.