The backend loop: algorithms, data, production — and a deep dive
Sergei Skrylkov, Founder, Trippi · facts checked against the product on 2026-09-30
A backend loop asks one question in many forms: what happens to your system when things go wrong. The coding round checks that you can write correct code; everything after it checks whether you understand data, failure and production — retries, transactions, migrations, the incident at 3 a.m. The strongest signal in most loops is the deep dive on your own past system, because that is the round where rehearsed answers stop working.
The loop, round by round
Recruiter screen — 20–30 minutes
Languages, databases, scale you have worked at, salary. Numbers help: “a service at about two thousand requests a second.”
Coding screen — 45–60 minutes, an engineer
An algorithmic problem or a practical one — parse logs, implement a rate limiter. The mechanics are on the coding interview page.
Practical or debugging round — 60 minutes
Build a small endpoint, or find the bug in an existing service. Talking through what you check first is most of the grade.
System design — 45–60 minutes, a senior or staff engineer
For mid-level and above. The general round is on the system design page; backend loops go deep on storage and consistency.
Project deep dive — 45 minutes, a staff engineer
“Tell me about a system you built.” Then twenty minutes of “why this, not that”, until they find the edge of what you know.
Behavioral — 45 minutes, an engineering manager
Incidents, disagreements about design, on-call. Shapes on the behavioral page.
Ten questions, and what each one tests
| Question | What it tests | What a strong answer does |
|---|---|---|
| “How do you make sure a retried payment request does not charge twice?” | Idempotency | An idempotency key stored with the result, checked before doing the work, and how long it is kept. |
| “When would you choose Postgres over a document store?” | Data modelling | Starts from the access patterns and transactions, not from preference. |
| “When does an index make things slower?” | Indexes beyond the basics | Write cost, low selectivity, and indexes the planner does not use. |
| “What isolation level does your database use, and what can go wrong at it?” | Transactions | Names the level and one anomaly it allows, with an example from real code. |
| “A request is slow only in production. How do you find out why?” | Debugging with observability | Traces and metrics first, then the usual suspects: N+1 queries, lock waits, a cold cache. |
| “How do you add a column to a table with 200 million rows?” | Safe migrations | Expand, backfill in batches, switch, contract — across several releases. |
| “How would you rate-limit a public API?” | Algorithms applied to infrastructure | Token bucket or sliding window, where the counter lives, and what the client sees. |
| “What happens to requests in flight when you deploy?” | Graceful shutdown | Stop taking new work, finish or hand back current work, then exit. |
| “Tell me about the last incident you were part of.” | Ownership in production | Timeline, your part, the fix, and what changed so it does not repeat. |
| “Tell me about a system you built.” — then “why?” | Whether the decisions were yours | Knows the trade-offs of each choice and what they would change now. |
Worked example: a column on a very large table
Interviewers like this question because a short, confident answer — “just run ALTER TABLE” — is the wrong one, and the right answer is a sequence. Here is the kind of structure a card offers for it: points to speak from, in order.
Example of a card’s shape — written for this page, not a screenshot
The line it grew from
“We need a new column on the orders table, around two hundred million rows, no downtime. How would you do it?”
Points to speak from
- 1Expand first: add the column as nullable, so the database does not rewrite the table, and deploy code that writes to both old and new.
- 2Backfill in small batches with a pause between them, and watch replica lag and lock waits while it runs.
- 3Contract later: switch reads to the new column, then remove the old path in a separate release.
The card does not know their database version or whether their migration tool locks the table. Those are good questions to ask back, and they are what the interviewer is listening for.
If English is your second language: production vocabulary
| What you hear | What it means |
|---|---|
| “P-ninety-nine” | The 99th percentile latency: 99% of requests are faster than this. |
| “Throughput” vs “latency” | How many requests per second, and how long one takes. Often confused under pressure. |
| “Ten k R-P-S” | Ten thousand requests per second. |
| “Blast radius” | How much breaks when this part fails. |
| “Back pressure” | Slowing the producer down when the consumer cannot keep up. |
| “Fan-out” | One request that becomes many downstream requests. |
| “Hot partition”, “hot key” | One shard or key getting a large share of the traffic. |
| “Paged”, “on-call”, “postmortem” | Woken up by an alert, the rota for it, and the written review afterwards. |
The deep dive is the round where accents cost most: a staff engineer asks short follow-ups quickly — “and if that node dies?”, “why not just cache it?” — and each one refers to something said a minute earlier. See what a deep dive means.
What Trippi Cue does in a backend loop, and what it cannot
Trippi Cue is a Chrome extension. After one click on its icon in the call’s tab in Google Meet, Zoom on the web or Teams on the web, it listens to that tab’s audio — not the microphone, and nothing joins the call. Each line appears as recognised, translated underneath if you choose. When a question is addressed to you, a short card follows with two or three points; because it reads the last minutes of the call, “and if that node dies?” is answered as a follow-up, not from nothing. A note before the call — your stack, the system you will talk about in the deep dive — makes the points about your work.
Limits, plainly: it does not see the coding editor, the diagram or the shared terminal. It cannot run or check code, and it does not know your systems beyond what you type in the note. It does not hear your own voice. It runs in browser tabs only.
FAQ
Backend engineer, specifically.
What is asked in a backend developer interview?+
Coding, data (SQL, indexes, transactions), APIs, reliability (retries, idempotency, migrations), system design at mid-level and above, and a deep dive on a past project.
How is the deep dive graded?+
On whether you know why each decision was made and what it cost. Saying “I did not decide that, but I would now choose…” is better than defending a choice you did not make.
Do backend interviews still ask algorithms?+
Many do, in the first coding round. Practical rounds — build or debug a small service — are becoming common alongside them.
Can Trippi Cue help with the coding round?+
Only with the spoken part: complexity, trade-offs, the interviewer’s hints. It does not see the editor or the problem statement.
What should I put in the note before a backend interview?+
Your main language and database, the scale you worked at, and the one system you want to talk about in the deep dive.
Read next
The follow-up refers to a minute ago. The minute is on your screen.
Trippi Cue is in the Chrome Web Store. One click on the icon when the call begins, and nothing before that.