The six signals an interviewer is actually reading
Every technical question is a proxy. The interviewer has a small number of things they are trying to decide, and the topic is the vehicle. Knowing which signal a question is probing changes the answer you give to it.
The six
| Signal | The question behind the question |
|---|---|
| Explains why it works | do you know the mechanism, or the recipe |
| Sees trade-offs | can you argue the other side |
| Understands one level down | does the abstraction have a floor for you |
| Frameworks | can you reason without a remembered answer |
| Enters a new domain fast | are you useful before you are expert |
| Ships to production | does it survive contact with users |
Explains why it works
The difference between “use select_related for foreign keys” and “select_related
does a JOIN so it works for to-one relationships, prefetch_related runs a
second query and joins in Python so it works for to-many”. Same advice; only
the second survives a follow-up.
The tell is a “why” you cannot answer. Practise by taking any rule you follow and asking why twice — most people stop being able to answer at the second one, and that is exactly where an interviewer goes.
Concrete examples in this corpus: why acks=all is not durable on its own
(Producer configuration and durability),
why gradients vanish
(Backpropagation),
why CORS breaks on 500s
(Middleware).
Sees trade-offs
An answer with no cost in it is not an answer. The shape that works:
“X, because reason. The cost is cost, which is acceptable here because context. I’d switch to Y if condition.”
That last clause does most of the work. Naming what would change your mind proves the choice was reasoned rather than habitual — and it is the thing most candidates omit.
Volunteer the downside of your own recommendation. It reads as confidence, not doubt.
Understands one level down
Not every level — one. Enough that the abstraction is a choice rather than a wall:
| Working at | One level down |
|---|---|
| ORM | the SQL it emits, and the query plan |
async def |
the event loop, and what blocks it |
| Container | namespaces, cgroups, the image layers |
| HTTP client | connections, pooling, TLS handshakes |
| Model API | tokens, context, the KV cache |
The question that finds this is always “and what happens underneath”. A candidate who can go one level has debugged something; a candidate who cannot has only used things.
Frameworks
A framework is what you use when you do not know the answer. It replaces recall with a procedure, and it is why “I have not built that, but here is how I would approach it” is a strong answer rather than an admission.
The ones worth having ready:
- A system design pass — requirements, scale, data model, bottleneck, trade-offs: Design framework
- A debugging order — reproduce, bisect, instrument, hypothesise, verify: Application debugging and introspection
- A “should we use ML” test: When not to use ML
- A build-or-buy pass — what is the hard part, is it our hard part
Enters a new domain fast
Nobody hires for what you already know; the stack changes. What is being tested is whether you are productive in an unfamiliar codebase in week one.
What a good answer describes, concretely:
- Find the seams. Entry points, the data model, the deploy path. The shape of a system is in its boundaries, not its files.
- Read the tests before the source — they say what is meant to be true.
- Ship something tiny on day two. A one-line fix exercises the whole pipeline: environment, review, CI, deploy. That is the thing you need working, and finding it broken later is expensive.
- Write down what confused you. It is the only time you will see the codebase with fresh eyes, and it is free onboarding documentation.
- Ask questions in public channels. Cheaper for everyone than a DM, and it leaves a searchable record.
Ships to production
The signal that separates senior most reliably, because it is the one you can only get by having been on call.
The vocabulary: what happens when the dependency is down, how you roll back, what you alert on, what the failure looks like to a user, what it costs. A design that has none of that is a prototype described in production language.
The question that finds it is “how would you know it broke?” Not “how would you build it”.
- Rollback and kill switch: Incident response for AI systems
- What to alert on: SLO, SLI, SLA, and Error Budgets
- Failure under partial outage: Resilience
Using this corpus against the six
Every note here ends in ## Interview angle, which is the “explains why” and
“trade-offs” signals in question form — and the site’s drill deck is those
questions asked back at you. The > **Gotcha:** callouts are mostly the
one-level-down signal. The system design and resilience folders are the
production one.
The gap this corpus cannot close by being read is the fifth signal. Entering a new domain fast is only demonstrated by a story, so have two ready.
Interview angle 5
- “Why is X the right choice here?” - give the mechanism, not the rule, then the cost, then the condition that would change your mind. An answer with no cost in it reads as inexperience regardless of how correct it is.
- “And what happens underneath that?” - the one-level-down probe. Know the SQL your ORM emits, what blocks your event loop, what a container actually is. One level is enough; not having one is the problem.
- “How would you approach something you have not built?” - name a framework and walk it rather than guessing at an answer. “I have not shipped that; here is how I would decide” is stronger than a confident wrong recall.
- “You join a team with an unfamiliar stack on Monday. What do you do?” - find the seams, read the tests before the source, ship something trivial by day two to exercise the whole deploy path, and write down what confused you while you can still see it.
- “How would you know it broke?” - the production signal. Name the alert, the user-visible symptom, the rollback and the kill switch. A design without those is a prototype described in production language.