A few years ago I spent three weeks prepping for a backend role at a mid-size fintech. I did LeetCode every morning, read a system design book cover to cover, and felt pretty prepared. Then the interviewer opened with: “Walk me through how you’d handle database connection pooling in a high-throughput API.” I had a vague answer. He kept pulling the thread. I didn’t get the offer.
That question isn’t exotic. It’s just the kind of thing you know deeply if you’ve actually built production APIs and shallowly if you’ve mostly been reading about them. This guide tries to bridge that gap, focusing on APIs, databases, and the related topics that come up in most backend loops.
What backend interviewers actually look for
Most interviewers aren’t trying to trip you up. They’re running a narrow probe: can you reason about trade-offs, do you know where the failure modes are, and have you been close enough to production to have opinions?
According to the Stack Overflow Developer Survey 2024, the most commonly used backend frameworks among professional developers include Node.js/Express, Spring, Django, and FastAPI. Interviewers at shops using these stacks will usually ask language-specific questions, but the underlying concepts (connection management, request lifecycle, error propagation) are framework-agnostic.
The interviews that go well are almost always the ones where the candidate talks about something that went wrong in production and what they learned from it. If you don’t have a story like that ready, find one before your next interview. It doesn’t have to be dramatic.
REST API design questions
These come up early in most loops and set the tone. They’re not just about knowing HTTP verbs.
The questions you’re most likely to face:
- What’s the difference between PUT and PATCH? PUT replaces the entire resource. PATCH applies a partial update. Many engineers know this but can’t explain idempotency correctly: PUT is idempotent (sending the same request twice yields the same result), PATCH may or may not be depending on implementation.
- How do you version an API? Three main approaches: URL path versioning (
/v1/users), header versioning (Accept: application/vnd.myapi.v1+json), and query parameter versioning. There’s no consensus on which is “correct” and the interviewer probably knows that. What they want to hear is your reasoning about trade-offs for a specific context. - How would you design pagination for a large dataset? Offset-based pagination (
?offset=0&limit=20) is easy to implement but breaks when rows are inserted or deleted mid-traversal. Cursor-based pagination (using a stable cursor, often the last-seen ID or timestamp) handles this better and is preferred for feeds and real-time data. - What does idempotency mean in API design and why does it matter? A payment API that processes the same request twice should charge the user once. Most production payment systems use idempotency keys in the request header. If you’ve worked with Stripe or similar, you’ve seen this.
One thing I’ve never seen go wrong: being willing to say “there are a few ways to do this, and the right answer depends on X.” Interviewers who ask good API questions are usually happy to hear you acknowledge the trade-offs.
Database questions: SQL vs NoSQL and everything in between
This is where the interviews tend to get interesting, because the questions can go in a lot of directions depending on your background.
Core questions almost everyone faces:
- When would you choose a NoSQL database over a relational one? When your schema is genuinely variable, when you need horizontal write scaling that relational databases don’t handle well, or when your access patterns are simple and query flexibility isn’t needed. The wrong answer is “when you need to scale,” because PostgreSQL scales further than most teams will ever need.
- What is the N+1 query problem? You fetch a list of 100 users, then for each user you run a separate query to get their orders. That’s 101 queries instead of 1 or 2. The fix is eager loading (JOIN in SQL,
includesin Rails,select_related/prefetch_relatedin Django). This question comes up constantly because N+1 bugs are common in ORM-heavy codebases. - Explain database indexing. When would you not add an index? Indexes speed up reads but slow down writes and take up storage. A table that’s written to heavily and rarely queried by a specific column doesn’t need an index on that column. Also, small tables (a few thousand rows) often don’t benefit from indexes because a full table scan is already fast.
- What are ACID properties? Which databases don’t fully guarantee them? Atomicity, Consistency, Isolation, Durability. Most relational databases guarantee ACID. Many NoSQL databases (Cassandra, DynamoDB) offer tunable consistency, meaning you can choose between strong and eventual consistency depending on the operation. This is a trade-off, not a deficiency.
The connection pooling question that tripped me up: connection pools maintain a set of open database connections that requests can reuse, avoiding the overhead of opening a new connection per request. Key parameters are min pool size, max pool size, and connection timeout. The failure mode is exhausting the pool under load, which manifests as queue buildup or timeout errors at the API level. If you’ve seen this happen, say so.
Caching strategy questions
Caching questions are deceptively hard. The basic “what is Redis used for” question is easy. The follow-ups get complicated quickly.
- What caching patterns do you know? Cache-aside (application checks cache, falls back to DB on miss, populates cache), write-through (writes go to cache and DB simultaneously), write-behind (writes go to cache, DB updated asynchronously). Each has different consistency and failure implications.
- How do you handle cache invalidation? Phil Karlton’s line “there are only two hard things in computer science: cache invalidation and naming things” is famous for a reason. Event-driven invalidation (invalidate on write), TTL-based expiration, and versioned cache keys (cache key includes a version number you bump on change) are the main approaches. None of them are perfect.
- What’s a cache stampede and how do you prevent it? A cached item expires and hundreds of requests hit the database simultaneously to recompute it. Prevention strategies include probabilistic early expiration, locking (only one request recomputes, others wait), or serving slightly stale data while recomputation happens in the background.
I don’t know the exact failure rate for cache stampedes in typical production systems. I’ve seen it happen once, it was painful, and I’ve used TTL-jitter ever since. That kind of specific, honest experience is what interviewers remember.
Security questions for backend roles
Security questions in backend interviews are usually about the basics. Few interviewers expect you to be a security researcher. They do expect you not to make obvious mistakes.
- What’s the difference between authentication and authorization? Authentication is verifying identity (who you are). Authorization is verifying permissions (what you can do). Common in practice: a user authenticates via JWT, but the API must also check whether that user has the role required for the requested resource.
- How does SQL injection work and how do you prevent it? User input gets interpreted as SQL. Prevention is parameterized queries or prepared statements, never string concatenation to build queries. If you’re using an ORM correctly, you’re probably already protected, but you should know why.
- What is CORS and why does it exist? Cross-Origin Resource Sharing restricts which origins a browser will allow to make requests to your API. It’s a browser-enforced security boundary. You configure it on the server by setting the correct response headers. The common mistake is setting
Access-Control-Allow-Origin: *on an authenticated API.
The OWASP Top 10 is worth skimming before any backend interview. Not as a memorization exercise, but because interviewers at security-conscious companies often reference it directly.
How to prepare when you’re short on time
If you have a week, focus on the areas where your answers are weakest, not the ones you’re already comfortable with. Most people spend prep time reinforcing what they already know because it feels productive.
Building a list of 8 to 10 real production experiences you can draw on is more useful than any flashcard deck. For each experience, know: what the problem was, what you considered, what you decided, and what happened. Craqly lets you do mock backend interview sessions with an AI that pushes on your reasoning, which can surface the gaps faster than solo review. Whether or not you use a tool, the goal is the same: get comfortable explaining your thinking out loud before you’re doing it in front of a hiring manager.