Backend interviews vary a lot between companies, but most processes test the same core areas: problem solving, how you design and reason about services, how well you know databases and HTTP, and how you work with other people. This plan assumes you have some backend experience — from a job, internship or serious projects — and around four weeks of evenings to prepare.
Every company describes its own process differently. Before you start, ask the recruiter what the rounds are and what each one evaluates. That single question can save you days of preparing for the wrong thing.
Understand the typical rounds
- Screening call — background, motivation, salary expectations and logistics.
- Coding round — data structures and algorithms, or a practical coding task.
- Backend / technical deep dive — APIs, databases, concurrency, your past projects.
- System design — more common for mid-level roles and above, sometimes a lighter version for juniors.
- Behavioural / team fit — collaboration, ownership, handling conflict and mistakes.
Week 1: Fundamentals and coding practice
Refresh the data structures you will actually be asked about: arrays and strings, hash maps, stacks and queues, linked lists, trees, graphs and heaps. Focus on patterns rather than memorising solutions:
- Two pointers and sliding window
- Hash map for counting and lookups
- BFS/DFS on trees and graphs
- Sorting plus binary search
- Basic dynamic programming (one-dimensional first)
Practise speaking while you code. Interviewers assess your reasoning, not only the final answer. A simple routine works well: restate the problem, clarify constraints, propose a brute-force approach, improve it, then code and test with edge cases.
Week 2: Databases and SQL
Backend roles almost always include database questions. Make sure you can explain and apply:
JOINtypes and when to use eachGROUP BYwithHAVING, and window functions such asROW_NUMBER()- Indexes: what they speed up, what they cost, and composite index column order
- Transactions and isolation levels in plain language
- Normalisation versus deliberate denormalisation
-- Top 3 authors by published articles in the last 90 days
SELECT a.name, COUNT(p.id) AS published
FROM authors a
JOIN posts p ON p.author_id = a.id
WHERE p.status = 'published'
AND p.published_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY a.name
ORDER BY published DESC
LIMIT 3;Be ready to explain how you would find and fix a slow query: read the execution plan, check indexes, reduce the rows scanned, and avoid N+1 query patterns in your ORM.
Week 3: APIs, concurrency and your own projects
Expect questions such as:
- What happens when you type a URL and press Enter?
- How do you design a paginated, versioned REST endpoint?
- How would you make a payment endpoint safe to retry?
- What is the difference between authentication and authorisation?
- How do you handle a slow third-party API? (timeouts, retries with backoff, circuit breakers, caching)
For concurrency, know the basics in your main language: threads versus async I/O, race conditions, locks, and why shared mutable state is risky.
Most importantly, prepare to discuss two projects in depth. For each, be ready to explain the architecture, a hard bug you fixed, a trade-off you made and what you would do differently now. Interviewers remember candidates who can go deep on something real.
Week 4: System design and behavioural stories
For system design, use a repeatable structure:
- Clarify requirements and scale (users, reads vs writes, latency needs).
- Define the API and data model.
- Sketch a high-level design: clients, load balancer, services, database, cache.
- Deep-dive into one or two components the interviewer cares about.
- Discuss bottlenecks, failure modes and trade-offs.
Practise with classic prompts: a URL shortener, a rate limiter, a notification service, a news feed.
For behavioural questions, prepare five or six short stories using the STAR format (Situation, Task, Action, Result). Useful themes: a production incident, a disagreement with a teammate, a deadline you nearly missed, feedback you received, and something you learned quickly.
How to practise effectively
- Mock interviews with a friend or peer are worth more than extra solo problems. Explaining out loud is a skill.
- Time-box practice problems. If you are stuck after 25 minutes, study the solution, then re-solve it from scratch two days later.
- Keep a mistakes log: note every concept you got wrong and review it weekly.
- Sleep before the interview. A tired brain solves problems badly.
On the day
Arrive (or log in) early, test your audio and screen sharing, keep water nearby and have a short list of questions for the interviewer — about the team’s on-call rotation, code review culture or how they measure success in the first six months.
| Area | Minimum you should be able to do |
|---|---|
| Coding | Solve a medium problem with clear reasoning in ~30–40 minutes |
| SQL | Write joins, aggregations and explain an index |
| APIs | Design a resource, choose status codes, handle errors |
| System design | Walk through a simple design and name trade-offs |
| Behavioural | Tell five STAR stories without rambling |
Interviews are a skill you can train. Consistent, focused practice over four weeks beats a panicked weekend every time.
Comments