Backend Interview Questions
A backend loop is four or five different examinations wearing one name, and they fail candidates for unrelated reasons. The machine coding round fails you for code that does not run. The design round fails you for not asking what the load is. The debugging round fails you for guessing instead of measuring. Preparing for "backend interviews" as one thing is why strong engineers get surprised.
The structure is fairly stable across Indian product companies: an implementation round, a DSA round, a design round scaled to your level, and increasingly a debugging or incident round. What varies is weighting. At entry level the implementation round decides it; by senior the design and incident rounds do, and the implementation round becomes a floor.
Written and reviewed by Sahil Srivastav
What the bar actually is
Across every round, the same underlying thing is being measured: whether your correctness is deliberate. An interviewer wants to know that you can name the invariant your code preserves, the failure mode you decided not to handle, and the evidence you would gather if it broke. Candidates who can do this are read as engineers; candidates who cannot are read as people who got it working.
The second constant is calibration. Saying what you do not know, and what you would measure to find out, is a positive signal at every level. A fluent wrong answer about delivery guarantees or isolation levels does more damage than an admission, because it tells the interviewer your confidence is not a reliable guide.
How the rounds are structured
Machine coding / implementation, 60–120 minutes
Build a small working service from a specification, then demo it. If the happy path does not run, nothing else in the round counts. This is where most Indian backend loops are actually decided.
DSA, easy to medium
A competence filter at most levels rather than a differentiator. Fluency and honest complexity analysis are enough; exotic algorithms almost never appear in backend loops.
System design, scaled to level
At junior levels, a small service and a database choice. At senior levels, an ambiguous prompt where narrowing it correctly is most of the score.
Debugging / incident, increasingly common
A symptom plus evidence. Can you form one narrow hypothesis and name the next measurement? Hard to prepare superficially, which is why it is spreading.
What this interview bar tests
Invariants in one place
The single habit that carries the implementation round: one overlap predicate, one state guard, validation at the boundary. Scattered checks are how edge cases escape.
Idempotency and retries
Asked at every level above entry, because every real system has clients that retry. "What happens if this arrives twice" should be a reflex, not a prompt.
Database behaviour over database trivia
What an index does and when it does not help, what a transaction guarantees, what a lost update is. Practical consequences rather than feature lists.
Evidence before action
Establishing whether something is slow or blocked before changing it. The habit that distinguishes the debugging round's passes from its failures.
A preparation plan that works
- 1Start with the implementation round, because it has the highest weight and the lowest average preparation. Build three small services from spec to running code under a timer, then break each one with concurrency and repetition.
- 2Then secure the database fundamentals you will actually be asked: run EXPLAIN on a real slow query once, and be able to state precisely what prevents a lost update in your database.
- 3Then practise one design prompt out loud per week, focusing on the first five minutes — what you ask, what you assume, what you exclude. The opening frames the whole round.
- 4Keep DSA on a maintenance schedule rather than making it the centre. For backend loops it is a floor to clear, not the thing being optimised.
Questions you should expect
What happens if this request arrives twice?
The most common backend interview question in existence, at every level. Answer concretely about your code: whether it double-applies, and what prevents it — an idempotency key claimed atomically under a unique constraint, or a guarded state transition whose second application matches no rows.
Why is this endpoint slow?
Separate slow from blocked first, because they have opposite fixes. Then look for work whose cost scales with total data rather than with the page requested. Reaching immediately for a cache, before establishing which of those it is, is the answer interviewers are watching for.
How would you add a cache here, and what breaks?
Name the invalidation strategy and the staleness window in the same breath as the latency win. A candidate who proposes caching without mentioning invalidation has described half a solution, and the missing half is where the production incidents come from.
What would you monitor?
Leading indicators, not aftermath. Queue depth before rejections, pool pending-count before timeouts, post-GC occupancy before an OutOfMemoryError. Naming the metric that provides warning rather than the one that records the outage is a senior signal at any level.
What gets candidates rejected
- Preparing DSA heavily and the implementation round barely, which inverts the actual weighting
- Arriving at the demo with code that compiles but was never run end to end
- Designing before asking what the load and the constraints actually are
- Guessing in the debugging round instead of establishing slow versus blocked
- Proposing a cache with no invalidation story
- Answering "what if it arrives twice" in the abstract instead of about your own code
- Giving fluent answers about delivery or isolation guarantees that are subtly wrong
What to practise, in order
Seat reservation system
Free and runnable in the browser with no signup. The canonical implementation round: overlap, cancellation, and a concurrency case that catches most first attempts.
Inventory overselling under concurrency
The check-then-write failure, with tests that hammer it in parallel and assert stock never goes negative.
Database connection pool exhaustion
The debugging round in repository form: leaked connections and sessions returned mid-transaction, where a bigger pool is the wrong fix.
Transactional outbox implementation
The design-round answer made executable: atomic enqueue, at-least-once publish, idempotent consumption.
FAQ
Which round should I prepare first?
The implementation round, at almost every level. It carries the most weight in Indian backend loops and attracts the least preparation, because candidates default to DSA. The asymmetry is the opportunity.
How much DSA is actually needed for backend roles?
Medium-difficulty fluency with honest complexity analysis. It is a filter you clear rather than a score you maximise. Time beyond that point is better spent on implementation and design.
Do I need to know Kubernetes and cloud services?
Depends on the role, but you should know the operational consequences of whatever your code runs on — what happens on a restart, how a deploy rolls out, what a readiness probe does. Certification-level depth is rarely probed for a backend engineer.
How long does backend interview preparation take?
Six to twelve weeks of consistent work, depending on level and starting point. The binding constraint is usually reps on the implementation round and fluency about your own past decisions — both of which take calendar time rather than cramming.