Backend engineers need strong foundations in API design, database optimisation, and distributed systems. These questions are designed to assess both technical depth and the judgment to make pragmatic engineering decisions.
Use these to assess past behaviour, values, and working style. Look for specific examples, not hypothetical answers.
1.Tell me about a time you designed an API that other teams depended on. What decisions did you make and why?
What to look for: Look for contract-first thinking, versioning strategy, documentation, and consideration of consumer needs not just internal convenience.
2.Describe a production incident you were involved in. What happened, and what was your role in resolving it?
What to look for: Look for calm under pressure, systematic diagnosis, clear communication, and post-incident improvements. Avoid candidates who blame others.
3.Tell me about a time you inherited legacy code or a poorly designed system. How did you approach improving it?
What to look for: Should show pragmatism — not rewriting everything — but incremental improvements: tests first, then refactoring, with business continuity in mind.
4.How do you decide when to introduce a new dependency vs. building something in-house?
What to look for: Should consider: maturity of the library, maintenance burden, security, licensing, and whether the problem is core to the product.
5.Give an example of a database performance problem you identified and fixed.
What to look for: Should describe the diagnostic process (slow query logs, EXPLAIN plans), the fix (index, query rewrite, denormalisation), and measurable improvement.
Use these to assess job-specific knowledge and skills relevant to the Backend Engineer role.
6.What are the ACID properties? Can you give an example of when you'd need full ACID compliance versus eventual consistency?
What to look for: Should explain Atomicity, Consistency, Isolation, Durability clearly. Strong answers contrast relational transaction requirements vs. distributed system trade-offs (CAP theorem).
7.How would you design a rate limiting system for a public API?
What to look for: Should discuss token bucket or sliding window algorithms, Redis for distributed counters, where to apply limits (per-user, per-IP, per-endpoint), and handling burst vs sustained traffic.
8.Explain the N+1 query problem and how you'd detect and fix it in an ORM-based application.
What to look for: Should explain the problem clearly (separate query per record), detection method (query logs, Bullet gem for Rails), and solutions (eager loading, DataLoader for GraphQL).
9.Walk me through how you'd design a job queue system for background processing.
What to look for: Should cover: queue persistence (Redis, SQS, Kafka), at-least-once vs exactly-once delivery, idempotency, dead-letter queues, retry strategies with backoff.
10.How do you handle database migrations in a zero-downtime deployment?
What to look for: Should describe expand-contract pattern: backward-compatible migrations first, deploy, then remove old columns. Understands that locking operations must be avoided on large tables.
These are great starting questions. Upload the candidate's CV to KiteHR and our AI will generate personalised interview questions based on their actual experience.
Try AI Interview QuestionsKiteHR helps you track candidates, upload CVs for AI-generated interview questions, and collaborate with your hiring team — all for free.
Start hiring for free