Backend Interview Preparation With 2 Years of Experience
Two years is the band where the questions change character. You are no longer asked whether you can implement a specification — that is assumed. You are asked whether you understood the system your code lived in: why it was built that way, what broke, what you would change.
This is also the band with the widest spread between candidates on identical résumés. Two engineers with the same two years can be a full level apart, and the difference is almost always whether they were curious beyond their tickets. The interview is designed to detect precisely that, and it does so with a single repeated question: why.
Written and reviewed by Sahil Srivastav
What the bar actually is
The bar is reliable delivery on a well-scoped feature with minimal supervision, plus understanding of the immediate surroundings of your code. You should know which database your service talks to and roughly how, what happens when a dependency is slow, and what your service does on a duplicate request. Not the whole architecture — the blast radius of your own work.
Interviewers at this band probe one layer below whatever you volunteer. Say you used a cache and you will be asked how it is invalidated. Say you added a retry and you will be asked what makes the operation safe to repeat. The preparation that pays is anticipating that second question for everything on your résumé.
How the rounds are structured
Machine coding, with a concurrency or failure twist
Still the deciding round, but the problem now includes something that breaks under repetition or simultaneity. Working code is necessary; correct-under-adversity is what differentiates.
DSA, medium
Still mostly a filter, now expecting fluency rather than recall. You should be able to state complexity without prompting and recognise a pattern quickly.
Practical database and API round
Indexes and query plans, transactions and isolation at a working level, idempotent endpoints, pagination. Grounded in what you have actually done rather than theory.
Project deep-dive with repeated "why"
The round that decides whether you are SDE1 or SDE2. Expect three or four levels of why on one decision you described.
What this interview bar tests
Knowing your blast radius
What calls your service, what it calls, what happens when each of those fails. Candidates who can draw this immediately read a level above those who cannot.
Idempotency as a reflex
At this band you should reach for "what if this arrives twice" without being asked. Retries and redeliveries are the first adversity added to your problems.
Transactions at a working level
What a transaction actually guarantees, why a network call inside one is a bug, what a lost update is. Not isolation-level theory — the practical consequences.
Having read an index plan
Having actually run EXPLAIN on a slow query, once, in anger, is disproportionately persuasive. It separates people who use a database from people who have only called one.
A preparation plan that works
- 1Go through your own résumé line by line and ask "why" three times of each claim. Every place you run out of answer is a question you will be asked. Fill those gaps first — this is the single highest-return activity at this band.
- 2Take one slow query from a system you know, run EXPLAIN on it, and understand the plan. One real instance of this beats reading about indexing.
- 3Build two problems that break under concurrency or repetition. Not "handle an error" — genuinely oversell inventory, genuinely double-charge, then fix it atomically.
- 4Learn to draw your service's dependency graph in sixty seconds, including failure behaviour at each edge. It gets used in almost every round.
Questions you should expect
Your API gets the same request twice because the client retried. What happens?
Answer concretely about your code. If it charges twice, say so. The strong answer names the mechanism that prevents it: a client-supplied idempotency key stored under a unique constraint and claimed atomically, or a guarded state transition where the second application matches no rows.
Why is this query slow?
Separate slow from blocked first — a statement waiting on a lock looks nothing like one doing too much work, and only one of them is fixed by indexing. Then look at the plan for rows produced versus rows returned; a large gap means the work is being thrown away.
Why should you not call an external API inside a database transaction?
Because the transaction stays open for the whole network round trip, holding a snapshot and possibly locks, consuming a connection, and blocking vacuum. If the remote call hangs without a timeout, it stays open indefinitely. If the write and the call must be atomic, that is what an outbox is for.
What did you disagree with in your last project, and what happened?
A real instance with a real outcome, including one where you were wrong. At two years, interviewers are checking whether you engage with design decisions or simply implement them, and a candidate who has never disagreed with anything reads as passive.
What gets candidates rejected
- Résumé claims that collapse at the second "why"
- Not knowing what happens when the dependency your service calls is slow or down
- Treating duplicate requests as an exotic case rather than the normal one
- Having never looked at a query plan despite claiming database experience
- Describing only your tickets, with no awareness of the system around them
- Still preparing exclusively DSA, as though this were a fresher loop
- Claiming ownership of team decisions you only observed
What to practise, in order
Inventory overselling under concurrency
Read-modify-write failing under parallel buyers. The tests assert stock never goes negative, so a retry loop around the same logic does not pass.
Message queue consumer idempotency and retry
At-least-once delivery made concrete. Duplicates and out-of-order arrivals, with tests on final state rather than on the happy path.
Database connection pool exhaustion
Connections leaked on an exception path and sessions returned still idle in transaction. The lifecycle bug that a bigger pool cannot fix.
Large table pagination failure
Why deep OFFSET degrades and drops rows under concurrent inserts. Tests assert bounded work per page and no duplicated or skipped row.
FAQ
Should I target SDE1 or SDE2 roles at two years?
Apply for SDE2 and let the loop calibrate you. Many companies down-level rather than reject, so aiming high costs little. The thing that actually decides it is the depth round, not the years on your résumé.
How much system design is expected?
Practical rather than theoretical. Be able to design a small service, choose a database with a reason, explain caching and its invalidation cost, and say what you would monitor. You will not be asked to design a global-scale system, and if you are, framing and assumptions matter more than components.
My work has been mostly CRUD. Is that a problem?
Only if you treat it as one. Most backend work is CRUD, and CRUD contains everything interesting: transactions, concurrent writes, validation, pagination, idempotency. Find the hardest correctness problem you did hit and go deep on it.
How long should preparation take at this band?
Four to eight weeks, with most of it spent on the depth round rather than on DSA. The gap that actually blocks candidates here is being unable to answer "why" about their own work, and that is fixed by reflection rather than volume.