Backend Engineer Interview Questions: What to Ask and What a Good Answer Contains
Backend interviews go wrong in two ways: a whiteboard puzzle that predicts nothing, or a friendly chat that predicts nothing. These questions sit between the two. Each one asks the candidate to talk about a system they actually built, and the notes say what a strong answer contains, so two interviewers score the same conversation the same way.
- Ask about work the candidate owned, not opinions: every question below asks for a system, a deal, a campaign or a decision that actually happened, with what they did and what came of it.
- Score each answer against the note beside it. The notes describe observable things a strong backend engineer answer contains, so two interviewers write down the same evidence and reach the same score.
- Use the scorecard: system ownership; operational maturity; data modelling, and two more. Five criteria, scored 1 to 4, with a sentence of evidence each.
- Ask five questions well rather than eight in a rush. The first one, about something the candidate owned end to end, sets the tone: specifics, not generalities.
- Watch for the red flags listed below, which are patterns rather than single answers: every story is about the team; nothing the candidate personally decided or shipped, for one.
The questions
1. Walk me through a service you own end to end. What does it do, who calls it, and what breaks when it is down?
What a strong answer contains: Names the callers and the failure blast radius unprompted. Ownership shows up as knowing the dependencies both ways; a candidate who only describes the code, not who relies on it, has maintained it rather than owned it.
2. Tell me about a production incident you were on the hook for. What happened, what did you do in the first ten minutes, and what changed afterwards?
What a strong answer contains: A concrete timeline, a real root cause (not "a bug"), and a follow-up that was structural: a check, an alert, a runbook, a design change. Watch for blame directed elsewhere.
3. How would you design the data model for a system where an order can be partially refunded several times?
What a strong answer contains: Reaches for immutable ledger rows rather than mutating an amount, worries about idempotency of the refund call, and asks what the reporting side needs. The strongest answers talk about the invariant, not the tables.
4. A query that used to take 20 ms now takes 4 seconds. Nothing was deployed. Where do you look?
What a strong answer contains: Data growth, a missing or changed index, plan changes as statistics shift, lock contention, a noisy neighbour. Good candidates ask to see the plan before guessing and mention that "nothing was deployed" usually means data changed.
5. When do you reach for a queue between two services, and when is a synchronous call the better choice?
What a strong answer contains: Talks about what the caller needs to know (was it done, or was it accepted), retries and duplicate delivery, and the operational cost of a queue nobody owns. Someone who says "always use a queue" has not run one.
6. How do you decide what to test, and what not to?
What a strong answer contains: Tests at the seam where the code is most likely to be wrong and most expensive to be wrong; deliberately does not test framework glue. Bonus for describing a test that caught a real regression and one that was deleted because it never would.
7. Tell me about a time you pushed back on a requirement. What was it, and how did it end?
What a strong answer contains: A specific request, a specific cost, a conversation rather than a refusal, and an outcome the candidate can describe honestly, including when they lost.
8. What is the piece of infrastructure or code at your current job that you would rewrite, and why have you not?
What a strong answer contains: Engineering judgement: knows what is wrong, can weigh it against what a rewrite costs, and has made peace with the answer. Someone with no answer has not looked; someone whose answer is "everything" will not last.
Scorecard
Score each 1 to 4 with one line of evidence. A total is less useful than a pattern.
- System ownership: can describe callers, dependencies and failure modes of something they built
- Operational maturity: incidents handled with a timeline and a structural fix
- Data modelling: reasons from invariants and idempotency, not from table shapes
- Debugging method: forms hypotheses from evidence before changing anything
- Judgement about trade-offs: queues, tests, rewrites, all argued from cost
Red flags
- Every story is about the team; nothing the candidate personally decided or shipped
- Root causes stop at "a bug in X" with no mechanism
- Cannot name a single trade-off they got wrong
- Answers design questions with a technology name instead of a reason
How to run the interview
Score each question against the note beside it, not against whether you liked the answer. The notes describe observable things: a named caller, a timeline, an invariant, a plan. Two interviewers who both write down what they observed will agree; two who write down how they felt will not.
Ask the ownership and incident questions first. They are the hardest to bluff and they set the tone: the candidate learns you want specifics, and every later answer gets more concrete. The design questions come after, once you know what level of system the candidate has actually worked at, so you can pitch them at that level rather than at the job description.
Leave the last fifteen minutes for their questions and for the rewrite question. What someone would change about their current codebase, and why they have not, tells you more about how they will behave in yours than any whiteboard exercise does.
Frequently asked questions
Should we include a live coding exercise?
A short one, on a real problem from your codebase, with the candidate's own editor and the internet on. A 45-minute algorithm puzzle predicts algorithm puzzle performance. Reading and fixing a small bug in code like yours predicts the job.
How many of these should we ask in one interview?
Five, well. Eight rushed gives you eight shallow answers and nothing to score. Split the list across two interviewers if you want them all covered, and have each interviewer own their questions.
What if the candidate has only worked on one system?
Then every question is about that system, and that is fine. Depth on one system a candidate genuinely owned beats breadth across five they touched. Adjust the design questions to the scale they have actually seen.
Related guides
Screening backend engineer CVs this week?
Paste the job description into WadeCV, check the rubric it drafts, and upload the CVs. Each one is read against the rubric and scored with an explanation. Ten screenings are free; there is no subscription.
Screen your first CVs free