Lesson 1 of 5
What Backend Interviews Probe
"The first principle is that you must not fool yourself — and you are the easiest person to fool." — Richard P. Feynman, Cargo Cult Science (Caltech commencement address, 1974)
Seven parts of this volume have been about the work. This one is about being able to demonstrate it in forty-five minutes to someone who has never seen you write code, which is a different skill and is not automatically acquired by having the first one.
The gap is worth naming precisely, because it is the reason strong engineers fail interviews. An interviewer cannot observe your competence; they can only observe your answers, and from those they infer competence. So the thing being optimised is the inference, and the candidates who struggle are usually not the ones who know less — they are the ones who answer the literal question rather than the question behind it. Asked "what is the difference between select_related and prefetch_related", the weak answer is correct and complete and lasts twenty seconds. The strong answer is the same fact plus when you would reach for each, what happens if you get it wrong, and how you would notice — because the probe was never about the two method names.
This chapter maps what the rounds are, what each is really measuring, and how the same question gets scored differently at different levels. It is deliberately unsentimental: the process is imperfect and often unfair, and it is also the process, and it rewards specific behaviours that can be learned.
Two candidates give technically correct answers to every question and only one gets an offer. What was being measured that both of them answered correctly — and why does saying "I don't know" sometimes score higher than a confident answer?
The rounds, and what each is actually for
A backend loop is not one interview repeated. Each round is designed to observe something different, and knowing which is which changes how you should behave in it.
Click Run to execute the code.
The weighting is the point. Algorithmic problem-solving is one round in seven, and the three rounds that dominate — design, debugging, and the practical exercise — are all measuring judgement rather than recall.
That gap between what a round looks like and what it measures explains most avoidable failure. A coding round looks like a test of whether you can produce the algorithm; it is a test of how you behave while producing it, which is why a candidate who narrates a wrong approach, notices, and corrects it often scores above one who silently produces the right answer.
The four signals
Interviewers do not score a single number. They score a small number of axes, and the axes are not weighted equally.
Click Run to execute the code.
Three of the four axes are invisible unless you volunteer them. Correctness shows up in the artefact; judgement, communication and production sense exist only in what you say, so a silent candidate is scored on one axis out of four regardless of how good the answer is.
"Production sense" is the one backend candidates most often leave on the table. Nobody asks how would you monitor this or what breaks at ten times the traffic — you are expected to raise it, and raising it unprompted is one of the clearest senior signals available.
A driving test. The examiner cannot see whether you are a safe driver — they can only see what you do in forty minutes, and they are scoring specific observable behaviours. Checking your mirrors is a good example: a driver who checks them without moving their head has genuinely checked them and scores nothing, because the examiner cannot tell. The advice to move your head visibly sounds like gaming the test, and it is, and it is also correct — the examiner is not being obtuse, they are working with the only evidence available to them. Interviews have the same structure. Your reasoning is invisible; the parts of it you say out loud are the entire record. What makes this analogy fair rather than cynical is that the observable behaviour and the real skill are genuinely correlated: a driver who narrates hazards is usually noticing them, and an engineer who names trade-offs is usually weighing them. The test rewards the behaviour because the behaviour is evidence, not because the behaviour is the point.
The depth ladder
For any topic, an interviewer keeps asking follow-ups until you stop being able to answer. This is not a trap. It is how depth is measured, and misreading it is a common source of unnecessary damage.
Click Run to execute the code.
The ladder has no top by design, so hitting your limit is the expected outcome rather than a failure. What is being calibrated is where you stop, and stopping cleanly at rung five is a perfectly good result for a mid-level role.
Bluffing is the expensive move, because it forces the interviewer to discount everything you said earlier. A confident wrong answer at rung five does not cost you rung five — it costs you rungs one through four, since they can no longer tell which of your confident answers were real.
The modern technical interview is younger than it feels and its lineage is unflattering. Microsoft popularised the puzzle interview in the 1990s — the manhole-cover and piano-tuner questions — which Google adopted and then publicly abandoned: in a 2013 New York Times interview, Laszlo Bock, then head of people operations, said brainteasers were "a complete waste of time" and predicted nothing, and that Google's own analysis found interview scores had almost no correlation with performance. What replaced them was the whiteboard algorithm interview, which had a better justification and its own well-documented problems, and which in turn produced an entire preparation industry — Cracking the Coding Interview (2008), LeetCode (2015) — that arguably made the signal worse by making the questions rehearsable. The reaction against it has been slow and partial. Take-homes, pair-programming exercises and "debug this real service" rounds spread through the 2010s precisely because they observe something a whiteboard cannot, and the current backend loop is a compromise between them. Two things are worth taking from that history. The process is not a meritocratic instrument that has been carefully validated; it is a set of proxies, some better than others, that companies keep revising because they know the proxies are imperfect. And the rounds that have survived scrutiny best are the ones closest to the actual work — which is why a debugging round and a design conversation carry more weight in a backend loop than an algorithm ever did.
The same answer at three levels
The Interview Corner in every chapter of this book is built on one observation: junior, mid and senior answers to the same question differ in structure, not in vocabulary.
Click Run to execute the code.
Every one of those answers is correct. What separates them is structure: whether the answer acknowledges that the question was under-specified, whether it names the alternative that was rejected, whether it names how you would find out you were wrong.
The senior answer opens with a question, and that is not a stylistic preference. Asking what staleness is acceptable demonstrates that you know the answer depends on something you have not been told — which is precisely the judgement the round exists to measure.
Behaviours that move the score, in rough order of return. Clarify before you answer — one or two questions, then state the assumption you are proceeding under; this is the highest-signal thing you can do and it costs thirty seconds. Narrate continuously, including the approach you are rejecting and why; a silent correct answer scores one axis of four. Volunteer production sense unprompted: how you would monitor it, what breaks at ten times the load, what you would do on a bad deploy — nobody will ask, and raising it is the clearest senior signal available. Say "I don't know" with structure: the boundary, your instinct, how you would find out, and your fallback. Never bluff, because a confident wrong answer devalues every correct one that preceded it. Bring one real number to any claim — a query count, a latency, a row count — since specifics separate experience from reading. Prepare four or five stories, not answers: an incident, a disagreement, something you got wrong, something you shipped end to end; behavioural questions are a small number of stories re-cut. Ask questions that reveal how the team works, not questions you could have read on the careers page. And write the answer you gave down afterwards, because the same eight questions recur across a whole job search and the second telling is always better than the first.
The screening round is a different game
An increasing share of first rounds are asynchronous: recorded, timed, sometimes machine-assessed, with no interviewer to read your face. The behaviours that work are not the same.
Click Run to execute the code.
The absence of an interviewer removes every recovery mechanism: no hints when you stall, no redirection when you misread the question, and no credit for reasoning you did not verbalise. Everything has to be explicit.
The time budget is the other half. The phase candidates cut under pressure is the first one, which is precisely the phase that determines whether the remaining forty-one minutes are spent on the right problem.
The most common way a strong backend engineer fails a loop is by being too fast. A question arrives — "how would you handle a slow list endpoint?" — and because they have done this thirty times, they answer immediately and completely: add pagination, check for N+1, add an index, cache if needed. It is a correct answer, it takes forty seconds, and it scores badly, which is genuinely confusing to receive as feedback. What happened is that the speed removed all the evidence. There were no clarifying questions, so the interviewer cannot tell whether the candidate knows the answer depends on data volume and access pattern, or simply pattern-matched. There was no reasoning, so they cannot tell whether the four items were reasoned or recited. There was no mention of how to verify, so they cannot tell whether this person has ever been wrong about a performance diagnosis. The candidate demonstrated that they know the answer; the round was designed to observe how they reach one. The fix is uncomfortable for experienced people because it feels like performing ignorance, and it is not — the honest version is to say what you are doing: "the answer depends on a couple of things, so let me ask, and then I'll walk through how I'd narrow it down." That sentence converts a forty-second answer into an eight-minute conversation with evidence in it.
Common Mistakes
Answering the literal question. "What is the difference between X and Y" is a probe for when you would choose each and what happens when you choose wrong.
Working silently. Three of the four scoring axes exist only in what you say, so a correct answer delivered in silence scores one out of four.
Skipping clarification. The under-specified question is deliberate, and asking what it depends on is the highest-signal thing available to you.
Bluffing at the top of the ladder. A confident wrong answer devalues every correct answer that came before it, because the interviewer can no longer distinguish them.
Treating "I don't know" as a loss. With a boundary, an instinct, a method and a fallback, it demonstrates three of the four axes and costs you only the fact.
Preparing algorithms for a backend loop. One round in seven is algorithmic; design, debugging and the practical exercise carry three times the weight combined.
Never volunteering production sense. Nobody will ask how you would monitor it or what breaks at ten times the load, and raising it unprompted is the clearest senior signal there is.
Answering too fast. Speed removes the evidence. An immediate complete answer demonstrates that you know it, and the round is measuring how you reach it.
Behaving in a recorded screen as if someone is watching. There are no hints, no redirection and no credit for unspoken reasoning; assumptions must be stated aloud and mistakes self-corrected.
Rehearsing answers instead of building stories. Behavioural rounds are a handful of real experiences re-cut for different questions, and a rehearsed answer collapses on the first follow-up.
Interview Corner
select_related, and then added an assertNumQueries test so it could not come back. That answer gives a real project, a specific problem, how I diagnosed it and what I changed afterwards, which is much more useful than saying I know Django. I would also be explicit about what I have not done, because that is going to come out anyway — if I have never run a migration on a large table, saying so early is better than being found out three questions later, and it lets the interviewer spend the time on what I do know.EXPLAIN, a benchmark, the source. And a fallback, so there is a decision even without the knowledge. That answer contains none of the missing information and still demonstrates method and honesty. What I would never do is bluff, because a confident wrong answer is much more expensive than an admitted gap: it does not just lose that question, it makes the interviewer discount everything I got right before it, since they now have no way to tell which of my confident answers were reliable. The other thing I would do is follow up afterwards if I care about the role — finding out and sending a two-line answer is a strong signal and almost nobody does it.Build the scorer. score_answer must weight the features an interviewer actually records, so a correct-but-silent answer scores badly and an unfinished-but-reasoned one scores well. level_of must map a score onto a level. ladder_result must show why bluffing costs more than stopping — a wrong confident answer discounts everything below it. allocate must budget a timed round. The checks that matter are the ones where the intuitive ranking is wrong. The checklist reports each requirement as PASS, FAIL or ERR; run it before writing anything and watch the lines flip.
Click Run to execute the code.
Summary
An interviewer cannot observe competence, only answers. The thing being optimised is the inference, which is why how you reach an answer matters as much as the answer.
A backend loop is one algorithmic round in seven. Design, debugging and the practical exercise together carry three times the weight, and that is the opposite of how most preparation time is allocated.
Three of the four scoring axes are invisible unless you speak. Correctness lives in the artefact; judgement, communication and production sense exist only in what you say aloud.
Volunteer production sense. Nobody asks how you would monitor it or what breaks at ten times the load, and raising it unprompted is the clearest senior signal available.
The depth ladder has no top, so reaching your limit is the expected outcome. The level is set by where you stop, not by whether you stop.
Bluffing costs more than the question. A confident wrong answer forces the interviewer to discount every correct answer that preceded it.
A good "I don't know" has four parts: the boundary, the instinct, the method for finding out, and the fallback — which demonstrates three axes while conceding one fact.
Clarify before answering. The question is under-specified deliberately, and asking what it depends on shows you know the answer is conditional.
Answering too fast destroys the evidence. An immediate complete answer proves you know it; the round is measuring how you get there.
A recorded screen removes every recovery mechanism. State assumptions aloud, structure explicitly, self-correct audibly, and budget the clock out loud.
With the map in place, the next chapter takes the question a Python web candidate is asked more than any other, and the one where reciting marketing copy is most obvious. Django vs FastAPI: Choosing & Defending is about answering it as an engineer: what each framework actually optimises for, which parts of the comparison are real and which are folklore, how to defend a choice you did not make, and what the question is really probing when an interviewer asks which one you prefer.
I have some discomfort writing a chapter that amounts to advice on performing competence, and I want to be honest about it rather than pretend the discomfort is not there. The process being described is a noisy two-hour proxy for a multi-year question, and it systematically favours people who are fluent in a particular idiom of talking about work — which is learnable, but is learned much more easily by people who have already been in rooms where that idiom is spoken. That is a real unfairness and no amount of interview technique fixes it. What makes the advice worth giving anyway is that the specific behaviours the process rewards are, unusually, behaviours that also make you better at the job. Clarifying an under-specified request before building it, naming the option you rejected, saying how you would know you were wrong, admitting the boundary of what you know instead of bluffing past it — these are not interview tricks that happen to correlate with competence. They are the competence, and the interview is one of the few settings that forces you to make them explicit. The most useful reframing I can offer is that preparing for these rounds is not separate from the work in this volume. It is the same material, rehearsed out loud, which is a thing engineers almost never do and which turns out to be how you find the parts you only think you understand.
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.