Backend Engineer Interview Questions — Entry Level

Give the shape in two sentences, then narrow hard. "Order processing for a grocery delivery app — a service that took orders, held stock, and talked to a payment provider and a dispatch system. I owned stock reservation and the reconciliation job that fixed it when the two disagreed."

Then volunteer a number that establishes the scale honestly. Requests per second, rows in the biggest table, orders per day, number of services. If the numbers are small, say the small numbers — an engineer who ran something modest and understood it completely interviews better than one who was adjacent to something large.

Close with the part that was hard, and make it a real engineering problem rather than a deadline. The interviewer is deciding, in this answer, which of the next questions to ask you.

Answer with what you have actually operated, not what you have read about. Then say what you have done with it beyond writing queries: migrations on a live table, reading an execution plan, restoring a backup, changing a connection-pool setting because something fell over.

That second half is the whole answer. Everyone has used a database. Far fewer have had to fix one at speed, and this question exists to find out which you are.

One sentence on leaving, then spend the time on what you want — that half is the useful one and almost nobody uses it. Being specific here filters out roles you'd resent, which is worth more than sounding agreeable.

"I want to own a service end to end rather than one endpoint of it" is a real answer. "New challenges" is not one, and it invites an interviewer to fill in the blank themselves.

Give a range and say what market it's anchored on — local, the client's country, or the currency of the contract. For remote work across borders those are three different numbers, and a figure with no stated basis invites the other side to supply one.

Give status, transferability and a realistic start date in a single pass. A transfer and a new visa are different problems on different timelines, and a hedged answer here is read as postponing bad news rather than as discretion.

If the position is complicated, lead with the complication and follow immediately with the date. Employers plan around dates. They cannot plan around ambiguity, and ambiguity is what loses the slot to someone else.

This looks technical and is often commercial, which is why it sits here. For a government client, a bank, or a customer with data-residency obligations of its own, the region a database runs in can be written into the contract — and an engineer who treats it as a latency question has missed what is being asked.

The answer that lands: find out what the customer's contract requires before choosing anything, name the constraint as a constraint rather than a preference, then talk about what it costs. And if you have never worked under one of these requirements, say so and say how you would find out — that is far stronger than improvising a compliance opinion, which is the easiest way to sound unsafe in a regulated-sector interview.

Asked outright for distributed-team roles in offshore delivery markets, and measured silently almost everywhere else. What is being tested is not fluency; it is whether you can disagree with a design decision in English, in writing, in front of people who don't know you.

Describe the usage rather than a level: written daily in reviews and design documents, spoken in a weekly call with a team in another country. "Advanced" describes nothing and gets tested two minutes later.

Read the plan. Say that first, before anything else, because a lot of candidates start guessing at indexes and the plan is the only thing that turns this from opinion into diagnosis.

Then narrate what you'd look for: whether it's scanning a table it should be seeking into, whether the row estimates are wildly off from actual (which points at stale statistics rather than a missing index), and whether an index that exists is simply not being used — a function wrapped around the column, a type mismatch, or a leading wildcard will each defeat one silently.

The addition that separates a working engineer: say what you'd check about the query and not just the schema. A query that was fine at ten thousand rows and dies at ten million usually asks for something it doesn't need — the full row set to count them, an unbounded result the application then truncates, an N+1 the ORM generated where a join would do. And say what you would not do: add an index in production at peak without knowing what it costs on writes.

Confirm it's being used at all — a composite index is only usable from its leading columns, so an index on (a, b) does nothing for a query that filters on b alone. Then check whether the planner chose it and rejected it, which usually means statistics.

And consider that the query may not be the problem. Lock contention, a connection pool at its limit, or a saturated disk all look exactly like a slow query from the application's side, and distinguishing them is the actual skill here.

The single best question in this whole interview, and the answers separate people sharply. The naive version — read the count, decide, write — has a race in it that no amount of application code closes, and saying so out loud is the first mark.

Then give the options and their costs. Let the database decide: a unique constraint or a conditional update whose row count tells you whether you won. Cheapest, most reliable, and it turns a race into an error you can handle. Pessimistic locking: correct, and it serialises everything behind it, which is how a fast endpoint becomes a slow one under exactly the load you built it for. Optimistic concurrency: a version column, retry on conflict, good when conflicts are rare and bad when they are not.

Then the part people forget: what the user sees. Losing this race is a normal outcome, not an error, and an interviewer notices when a candidate designs the failure message as carefully as the lock. If they push further they'll ask what happens when the seat and the payment live in different systems — that is the next section.

Answer at the level of consequences rather than reciting the acronym. Atomicity means the partial state never becomes visible; durability means a committed write survives the process dying. Isolation is the one that matters in practice and the one nobody checks: the default level on most systems permits anomalies people assume are impossible.

Name the concrete thing: read-modify-write across two statements is not safe just because both are inside a transaction, unless the isolation level or an explicit lock makes it so. Say which level your systems ran at. Most candidates do not know, and knowing is a strong signal.

Expand, migrate, contract — and say it as three deploys, because the reason this is asked is to see whether you think in deploys or in DDL statements.

Expand: add the new column as nullable with no default that rewrites the table, and deploy code that writes to both and reads from the old. Migrate: backfill in batches with a pause between them, watching replication lag rather than wall-clock time. Contract: flip reads to the new column, deploy, then drop the old one in a separate release once you're certain nothing reads it.

The details that show you have done it: adding a `NOT NULL` column with a default can rewrite the whole table and take a lock on some engines and versions; a long-running backfill can hold a transaction open and bloat the log; and the rollback plan matters more than the forward plan, because the release you cannot undo is the one that turns a bad afternoon into an incident. Say too that you would test the migration against a copy of production data — a hundred seeded rows tells you the syntax is right and nothing else.

When a read path is measured as too slow and the join is the measured cause — in that order, and say the order, because denormalising first is how a schema becomes unmaintainable in service of a problem nobody had.

Then name the cost honestly: you now own the consistency yourself, which means every write path that touches the source of truth must update the copy, including the ones written by someone else next year. Saying that out loud is what separates a decision from a habit.

Cache things that are expensive and tolerate being slightly stale, and be explicit about what "slightly" means for that data — seconds for a product listing, never for an account balance.

The interesting half is invalidation. Say which strategy you'd use and what it fails at: time-to-live is simple and serves stale data for exactly as long as you chose; event-based invalidation is precise and breaks silently when a write path forgets to publish. Then mention the failure everyone meets eventually — when the cache empties and every request goes to the database at once.

Have a real answer rather than a preference — a document store where the shape genuinely varies per record, a search index for full text, a time-series store for metrics, a blob store for files that people keep putting in a database. Then say the default is relational and the burden of proof is on moving off it.

By never making a breaking one in a single step — the same expand-and-contract discipline, applied to a contract rather than a table. Add the new field, tell the consumers, give them a deadline that is a real date, and remove the old one only after checking that nothing reads it rather than after being told nothing does.

The sentence that earns trust: you would find out who the consumers are before you start, and "we'll announce it in the channel" is not finding out.

A better question than the one about a decision you won, and it is asked more often than candidates expect. What's being tested is whether you can be overruled and still do the work well.

Say what you look for in order — does it do what it claims, what happens on the unhappy path, what happens on a retry, and is anything here going to be expensive at ten times the volume. Style comes last and mostly belongs to a linter.

Then the human half: separate the blocking comment from the suggestion, say which is which explicitly, and move to a call at about the fourth reply. Reviewers who mark every comment as blocking are a real cost on a team and interviewers know it.

In time and money and risk, not in nouns. "Two weeks now and it stays fast at ten times the traffic, or three days now and we redo it around March" is the answer; naming the architecture is not.

One endpoint, not the architecture. Candidates reach for the diagram because it feels more impressive, and the diagram is where a junior gets caught, because the follow-up is "and which of those did you write."

Take the request from the top and say each thing out loud as it happens: what comes in and in what shape, what you check before you trust it, what you ask the database for, what you send back, and what status code goes with it. Five sentences. If you cannot do that for any endpoint you have written, that is the thing to fix this week.

Then say what is wrong with it. Every first API has something: no validation on one field, an error handler that swallows the real message, a secret that was in the repository until you noticed. Naming it yourself converts an amateur decision into an observation, and observations are what a junior is hired for.

Open-ended on purpose, and how far you get is the measurement. There is no single required depth, but there is a required honesty: name the stage you are unsure of rather than inventing a smooth sequence.

The spine: the name resolves to an address, a connection opens and — over TLS — is negotiated once and then reused, the request goes to whatever is listening on that port, which may be a proxy or a load balancer rather than your code, and that hands it to your process, where a router matches the path and method and calls your function.

The two additions that read as real: say where the request could die that has nothing to do with you — the proxy timing out, the connection pool being empty — and say that the headers matter, because the content type and the authorisation header are the two things you will spend a junior year debugging.

401 means we do not know who you are — no credential, or one we cannot verify. 403 means we know exactly who you are and you are not allowed this. 422 means we understood the request and the contents are wrong.

Say the practical consequence, which is what separates recall from use: the client does completely different things with each. A 401 sends the user to log in again. A 403 must not, or you have built a login loop that logs a legitimate user out forever. And returning 200 with an error message inside it — a habit worth breaking early — breaks every client that checks the status, including the one written by somebody else next year.

Expected and ordinary — the hard part is the audience, not the SQL. Say the shape before you type it: which table you are starting from, what joins to what and on which column, what you are grouping by, and what you are counting.

Two traps live in this exercise whatever shape it takes. An inner join silently drops the rows with nothing on the other side, so "customers and their order counts" quietly loses every customer who has never ordered — say that out loud and reach for a left join if the question wants all of them. And counting a nullable column counts only the non-null values, which is exactly what you want in some cases and a silent bug in others.

If you blank on the syntax, say what you are trying to express in words and write it anyway. An interviewer will take a candidate who describes the correct query and misplaces a keyword over one who writes valid SQL for the wrong question.

To stop a row pointing at something that isn't there — the database refuses the orphan rather than trusting every future piece of code to remember. Say the second half too: it is also a statement about what happens on delete, and choosing between refusing, cascading and setting null is a real decision, not a default.

This is the N+1 question, and it is asked at this level because it is a mistake you write before you know it has a name.

The instinct is to fetch the list, then loop over it and fetch each author. Say that out loud if it is what you would do, then say what is wrong with it: one query becomes one plus however many rows there are, so it is fine on the twelve rows in your development database and it is a hundred queries on the real page.

Then the fixes, in the order they are worth reaching for. Join and get it in one query. Or fetch the authors in a second query with all the ids at once and stitch them together in code — two queries, no matter how many rows, and it can be the more readable of the two. If you use an ORM, say which of its options loads the relation eagerly, because an ORM that has such an option puts the whole class of problem one configuration line away.

The best possible ending: say how you would notice. Logging the query count for a request, in development, is a habit worth having before anyone asks you to have it.

Hashed with a slow algorithm built for passwords, with its own salt, and never anywhere else — not in a log line, not in an error message, not in the request you print while debugging. If you cannot name the algorithm, say you would use whatever the platform's own library recommends today and would not choose one yourself. That is the correct answer at this level, and it does not stop being correct later.

A situation you will meet, and the answer people reach for is a list of guesses. Give a procedure instead.

Read the actual error before anything else. Not the 500 the browser shows — the stack trace in the server's own logs. Debugging at this level goes wrong when somebody reasons out a cause that is written in plain text somewhere they have not looked.

Then the four differences between the two environments, in the order they bite: configuration — an environment variable that exists locally and not there, which is the first thing to check; the database — a migration that ran on your machine and not on the server, so a column the code expects is missing; file paths and case — your laptop's filesystem does not care about capitals and the server's does, which produces an error that looks like nothing; and versions — a different runtime or dependency version than the one you developed against.

Finish with what you would change so it stops happening: the same configuration list checked into the repository as an example file, and a startup check that refuses to boot with a clear message when a required variable is missing. Crashing loudly at start beats a 500 an hour later, and saying that is a genuinely senior instinct arriving early.

Where do the secrets live · what is in your .gitignore · what is the difference between your development and production settings. One question, three doors, and it is diagnostic in a way no amount of preparation covers.

Answer with the truth including the embarrassing part. If you once committed a key and had to rotate it, that story is worth more than any policy you can recite — it is the only version of this answer that proves you understand why it matters. What you do not want to say is that you have never thought about it, and what you must not say is that the credentials are in the repository and it is fine because it is private.

Then the concrete list: secrets come from the environment, never from a checked-in file; the example file in the repository has the variable names and no values; and the difference between environments is configuration rather than code, because an `if` on the environment name scattered through the codebase is how a debugging endpoint ends up live. Say that debug output must be off in production — a stack trace on a public error page tells a stranger your framework, your file layout and sometimes your query.

Answer honestly first. If the truth is that you called it and looked at the response, say so — that is a real answer and pretending otherwise is transparent.

Then go one step further than the honest answer, which is what the question is for. Say which cases you would call it with beyond the one that works — the missing field, the id that does not exist, the same request sent twice — because those three are where the bugs are, and naming them shows you think past the happy path.

If you have written a test, say what it asserts rather than which library you used. If you have not, say so and say which one you would write first: the one for the case that would be most expensive to get wrong.

It sounds dismissive and it is not. They have already decided to interview somebody at your level; they are asking you to make the case in your own words, and it is easy to spend the time apologising instead.

Do not argue with the premise. Create, read, update and delete with rules on top is ordinary backend work rather than a lesser kind of it, and a candidate who says so calmly sounds more experienced than one who insists their project was architecturally interesting.

A yes or no with a story attached, and the story is what is being asked for. Where it runs, how the code gets there, what happens when it falls over, and whether anything restarts it.

A small deployment you did badly and understand completely is a better answer than a managed platform that did everything for you. If a service builds and runs it on a push, say that plainly rather than dressing it up — the room knows what those platforms do, and claiming more is one question away from being found out.

If the answer is genuinely no, say so and say what stopped you. "I've never had anything worth paying to host" is an honest sentence that costs you nothing. "I'd start by getting the thing I built last month running somewhere with a real domain" is a better follow-up than any hedge.