Backend Interview Preparation With 0–1 Years of Experience
With under a year of experience, interviewers know you have not seen much. They are not testing breadth — they are testing whether the small amount you have seen, you actually understood. One feature you can explain in genuine depth outperforms five you can only describe.
The most common self-inflicted wound at this stage is apologising for inexperience and then speaking only in generalities. "I worked on the payments module" tells an interviewer nothing. "I added the retry on the webhook handler, and we had a bug where retries created duplicate rows until we added a unique constraint on the event id" tells them you were paying attention — and that single sentence can carry an entire round.
Written and reviewed by Sahil Srivastav
What the bar actually is
The bar is solid fundamentals plus demonstrated learning velocity. You should write correct code for a bounded problem, explain what your own code does and why, and be honest about the edges of your knowledge. Interviewers at this band explicitly discount breadth and weight depth-on-something and curiosity.
What is disqualifying is not gaps, which are expected, but pretending not to have them. Confidently wrong answers about things you have not encountered read far worse than "I have not worked with that — my guess is it behaves like X, is that close?" The second answer frequently earns a hint and a productive conversation; the first ends the line of questioning badly.
How the rounds are structured
A machine coding or implementation round
Build a small service from a clear spec. This is the round that decides most early-career loops, and the one most candidates spend the least time preparing.
DSA, easy to medium
Arrays, strings, hash maps, basic recursion. A competence filter. Steady practice clears it; nothing exotic is required at this band.
Fundamentals rapid-fire
HTTP methods and status codes, what an index does, SQL versus NoSQL at a basic level, language-specific memory and collection questions. Breadth of shallow questions rather than depth.
A short conversation about what you have built
Your internship, your project, your one shipped feature. Expect to be pushed one or two levels deeper than you volunteer, which is why depth on one thing matters more than coverage of many.
What this interview bar tests
Depth on one real thing
Pick the most technically interesting work you have done and be able to go three questions deep: what it did, why that approach, what broke. This is the highest-leverage preparation at this band.
Honest boundaries
Saying "I do not know, here is how I would find out" is a positive signal early in a career. Bluffing is the fastest way to lose a round you were otherwise passing.
Correct code over clever code
Validate inputs, handle the empty case, put the invariant in one place. Nobody expects architecture; they expect care.
Reading an error message properly
A surprisingly strong early-career signal. Candidates who read the stack trace and reason from it stand out sharply against those who change things at random.
A preparation plan that works
- 1Write the deep story of your one best piece of work, then have someone ask you "why" four times in a row about it. If you run out of answers by the second why, you have found your preparation gap.
- 2Build three small services from specification to running code, timed. The reps matter more than the variety — the aim is that starting is mechanical rather than daunting.
- 3Deliberately break each one afterwards: empty input, duplicate submit, two concurrent calls. Fix what breaks. This builds the edge-case instinct that otherwise takes a year on the job.
- 4Practise saying "I have not used that" out loud without flinching, followed by a reasoned guess. It is a skill, and it converts dead ends into conversations.
Questions you should expect
Walk me through something you built.
Pick the piece with a real technical decision in it, state the problem, the choice, and one thing that went wrong. Resist the urge to cover everything you have touched — interviewers probe depth, so a narrow answer you can defend beats a broad one you cannot.
What happens if this function is called twice with the same input?
Answer literally about your code, not in the abstract. If it creates two rows, say so and name what would prevent it — a unique constraint, or an upsert keyed on the input. Recognising that repeated calls are a real scenario puts you ahead of most candidates at this band.
You get a NullPointerException in production. What do you do?
Read the trace, find which reference is null and in which frame, then work back to why it was null — a missing field in a response, an absent configuration, an empty collection. The point is reasoning from evidence rather than guessing and redeploying.
What is an index, and when does it not help?
It is a separate ordered structure letting the database find rows without scanning. It does not help when the query cannot use it — a function wrapped around the column, a leading wildcard, a type mismatch — or when it matches most of the table anyway, where a scan is cheaper.
What gets candidates rejected
- Speaking only in generalities about your own work, which reads as not having understood it
- Bluffing an answer instead of admitting a gap and reasoning aloud
- Listing technologies you have touched once as though you know them
- Skipping input validation and the empty case, then being surprised by the follow-up
- Grinding only DSA while never building a service end to end under time pressure
- Changing code at random when something fails, instead of reading the error
- Apologising for inexperience repeatedly, which invites doubt the interviewer did not start with
What to practise, in order
Seat reservation system
Free and runnable in the browser with no signup. Overlapping reservations and a concurrency case that teaches the single most useful early-career lesson about check-then-write.
URL shortener with custom aliases and quotas
Small enough to finish, with real validation and collision handling. Good first end-to-end rep.
Food delivery order status tracker
A state machine with illegal transitions. Teaches guarded transitions, which is the idea behind half the correctness questions you will be asked.
Wallet transaction and refund system
Balances that must not go wrong, including the repeated-refund case. A gentle introduction to why money code is written defensively.
FAQ
I have no production experience. What do I talk about?
A project, an internship, or open-source work is fine, provided you can go deep. Interviewers at this band care that you understood something thoroughly, not where it ran. What does not work is a list of tutorials completed.
How many DSA problems should I solve?
Fewer than the internet suggests, with more attention each. A hundred problems understood deeply — where you can explain the pattern and complexity without notes — beats four hundred skimmed. And do not let DSA crowd out machine coding, which is where early-career loops are actually decided.
Should I learn a second language?
Not yet. One language you know well, including its collections, concurrency primitives and memory behaviour, is far more valuable than two you know superficially. Interviewers probe depth, and a second shallow language gives them more surface to find gaps in.
Is it bad to ask clarifying questions?
The opposite — it is a positive signal, provided they are substantive. Asking whether ids are unique, whether input is trusted, or what should happen on a duplicate shows you think before coding. Asking questions already answered in the prompt does not.