SDE1 Backend Interview Preparation
An SDE1 backend loop is looking for one thing above all others: can you take a written requirement and turn it into code that runs and is correct? Not architecture, not scale, not a clever abstraction. Working, correct, readable code within a time box.
This is the level where candidates most often prepare for the wrong interview. They study distributed systems theory and consistent hashing, then fail a machine coding round because their service double-books a seat under concurrent requests. The round is deliberately small in scope and strict about correctness, because that is the honest signal for someone who will spend their first year implementing well-specified tickets.
Written and reviewed by Sahil Srivastav
What the bar actually is
The bar is autonomy on a bounded problem. Given a clear specification, you should produce a working implementation with sensible validation, handle the edge cases the spec calls out, and be able to explain why your code is correct. You are not expected to anticipate requirements nobody stated, or to design for a scale nobody mentioned.
What interviewers probe at this level is whether your correctness is accidental or deliberate. They will ask what happens with an empty input, a duplicate request, two simultaneous calls. A candidate who says "I tested it and it works" has given a weaker answer than one who says "the overlap check is in one place and it uses a half-open interval, so same-day turnover is legal by construction".
How the rounds are structured
One machine coding round, 60–120 minutes
A small service with explicit requirements — a booking system, a cart, a rate limiter. You write it on your own machine or in a shared editor, then demo it. If the happy path does not run at the demo, the round is effectively over regardless of design quality.
A DSA round, usually easy to medium
One or two problems testing whether you can reason about complexity and write a correct loop. At SDE1 this round is a filter rather than a differentiator; competence is enough and brilliance is rarely needed.
A fundamentals conversation
Language-level questions, basic database questions, HTTP. Expect "what is an index and when does it not help", not "design a globally distributed cache".
A short extension discussion after the demo
The interviewer adds one requirement — "now coupons can stack", "now a cancelled booking frees its dates". They are checking whether your code can absorb it, which is why hard-coded logic that passes the original spec can still sink you.
What this interview bar tests
Correctness you can defend
Put each invariant in exactly one place and be able to point at it. Validation at the boundary, one overlap predicate, one state-transition guard. Scattered checks are how edge cases escape.
Edge cases from the specification
Empty collections, boundary values, invalid ranges, duplicates. The spec usually names two or three explicitly — a candidate who misses a called-out edge case looks careless rather than junior.
Readable structure under time pressure
Small functions with honest names, no dead code, no commented-out experiments left in the demo. At this level, legibility is read as a proxy for how you will behave in a codebase.
Running tests, not hoping
Even a handful of assertions you wrote yourself changes the conversation. It demonstrates you verify rather than assume, which is the single habit most correlated with passing.
A preparation plan that works
- 1Solve three small stateful services end to end, from spec to running code, with a timer. The goal is to make the first thirty minutes mechanical: read the spec, name the entities, write the invariant, then build outward.
- 2For each one, deliberately break it afterwards. Run two operations concurrently, pass an invalid range, cancel something twice. Fix what breaks and note the class of bug — that catalogue is what you draw on in the round.
- 3Practise the demo. Say out loud what you built, run the happy path, then name one thing you would do next. Candidates lose rounds by fumbling a demo of code that was actually fine.
- 4Only then spend time on DSA. At SDE1 the machine coding round is where loops are lost and won, and it is the round most candidates under-prepare for.
Questions you should expect
Two users book the same seat at the same instant. What happens in your code?
The honest answer names the mechanism, not the hope. Either the check and the write are one atomic operation — a conditional update whose affected-row count tells you whether you won — or they are not, in which case both bookings succeed and you have a bug. Saying "the database handles it" without naming what enforces the invariant is the answer that fails.
Why did you choose this data structure?
Tie it to an operation and its frequency: a map because lookups by id dominate and are O(1), a sorted structure because you need range queries. The weak answer is "it seemed appropriate"; the strong one names the access pattern the choice serves.
How would you add a new type of discount to this?
Point at the seam. If discounts are a list of rules applied in order, a new type is a new rule and nothing else changes. If the logic is a chain of if-statements on a type string, admit that and describe the refactor — recognising your own rigidity scores better than defending it.
What would you test first?
The invariant, not the happy path. For a booking system that is "no two confirmed bookings overlap for the same resource" — assert it after a sequence of operations rather than checking one call returns the right thing.
What gets candidates rejected
- Designing for scale nobody asked about while the happy path still does not run
- Missing an edge case the specification explicitly named — reads as carelessness, not inexperience
- Spreading one invariant across three functions, so a concurrent or repeated call slips past
- Arriving at the demo with code that compiles but was never executed end to end
- Writing no tests at all, then being unable to answer "how do you know it works"
- Treating the mid-round requirement change as unfair rather than as the actual test
- Over-preparing DSA and under-preparing the machine coding round, which is where the loop is usually decided
What to practise, in order
Seat reservation system
The canonical SDE1 machine coding problem: overlapping reservations, cancellation that releases capacity, and a concurrency case that catches most first attempts. Free, and runnable in the browser with no signup.
Hotel room booking system
Date-range overlap done properly, including the half-open interval that makes same-day turnover legal. The bug most candidates ship here is an off-by-one at an interval boundary.
E-commerce coupon application engine
Stacking rules, eligibility, and caps. Good practice for the extensibility question, because the interviewer will add a coupon type and watch what your code does.
Inventory stock reservation
Where "check then write" fails. Build it the naive way first, watch it oversell, then fix it with a conditional update — that sequence teaches the lesson better than reading about it.
FAQ
How much system design do I need for SDE1?
Very little, and almost none of the "design Twitter" variety. You should be able to explain what a database index does, why you would add a cache and what breaks when you do, and roughly what happens when a request times out. Depth beyond that is rarely probed and never the reason an SDE1 offer is made.
Should I prioritise DSA or machine coding?
Machine coding, by a clear margin, because it is the round most candidates are least prepared for. DSA at this level tends to be a competence filter you pass with steady practice, while the machine coding round separates candidates outright.
Is it acceptable to look things up during the round?
Standard library signatures and syntax, almost always yes — ask first. What is not acceptable is looking up the structure of the solution, and most interviewers can tell the difference immediately from how your typing pattern changes.
How long should SDE1 preparation take?
Six to ten weeks of consistent work for someone already comfortable in one backend language. The bottleneck is usually not knowledge but reps: being able to go from specification to running, defensible code without stalling.