Backend Developer Mock Interview: 40 Questions to Practice
Backend interviews usually go deeper than
“Can you write code?” Interviewers may want to understand whether you can build and operate systems that behave correctly under real conditions.
That means practicing
- APIs
- databases
- concurrency
- distributed systems
- caching
- queues
- scalability
- observability
- reliability
- security
- debugging
40 backend interview questions APIs
1. How would you design a REST API?
2. How do you version an API?
3. How do you handle idempotency?
4. How do you design pagination?
5. How do you handle authentication and authorization?
6. How would you protect an API from abuse?
7. When would you use synchronous vs asynchronous APIs?
Databases
8. How do indexes work?
9. When would you normalize a database?
10. When would denormalization make sense?
11. How would you investigate a slow query?
12. How do you scale a relational database?
13. What is replication?
14. What are the tradeoffs of read replicas?
15. How would you approach a database migration?
Caching
16. What should you cache?
17. When can caching create problems?
18. How would you invalidate a cache?
19. What happens when the cache goes down?
20. What is cache stampede and how would you mitigate it?
Distributed systems
21. How would you design a distributed queue?
22. What is eventual consistency?
23. When is strong consistency important?
24. How do distributed systems fail?
25. How would you handle duplicate messages?
26. How would you design a retry strategy?
27. How do you avoid retry storms?
28. What is a circuit breaker?
Scalability
29. How would you scale a high-traffic service?
30. When would you introduce a load balancer?
31. How would you partition data?
32. How would you identify your system's bottleneck?
Reliability
- Tell me about a production incident.
- How do you monitor backend services?
- What metrics matter for API reliability?
- How do you approach incident response?
- Tell me about a difficult backend decision.
- Tell me about a system you would redesign.
- Tell me about a time you disagreed with an architecture decision.
- Tell me about a technical failure you learned from.
- where latency increased
- whether traffic changed
- whether a dependency changed
- whether database performance changed
- whether errors increased
- whether a recent deployment correlates with the change
Behavioral
What makes backend interviews difficult? Many candidates know individual technologies. The difficult part is connecting them.
For example
“We use Redis.” is knowledge.
But
“We use Redis for frequently accessed data because the latency requirement makes repeated database reads expensive. The tradeoff is cache invalidation and failure behavior, so I'd define what happens when the cache is unavailable.” is engineering reasoning. A backend answer framework
When asked
“How would you design X?”
Use
Requirements What does the system need to do? Scale How much traffic/data? Core components What are the major services? Data How is state stored? Failure What happens when dependencies fail? Tradeoffs What did you optimize for? That structure works across many system-design questions. Practice production thinking Backend engineers often work on systems after they are deployed.
Practice questions such as
The API suddenly becomes 5× slower. What do you investigate?
Don't jump immediately to
“Increase the servers.”
First determine
That is more realistic problem-solving. Final checklist
Before your backend interview, practice
one API design one database problem one caching problem one distributed-system problem one incident one behavioral story one project deep dive Then practice the follow-ups. The first answer is rarely the hardest part. The follow-up usually is. [Run a Backend Developer mock interview with Mockly]