Backend Engineer — Node.js Interview Prep & Rubrics

Node and TypeScript service loop, where the event loop and type modelling carry most of the technical weight.

The loop, in order

Data Structures & Algorithms44 questions · 16 topicsDSA interview questions organised by tested pattern: arrays, hashing, rotated arrays, dynamic programming, graphs, heaps and sliding windows, so you learn transferable coding-round techniques instead of memorising puzzles.
Node.js & TypeScript15 questions · 5 topicsServer-side JavaScript depth, where nearly every question eventually reduces to understanding the event loop and the type system.
Databases & SQL25 questions · 8 topicsQuery-writing rounds and the storage-engine reasoning behind why a query is slow, for backend, data, and DBA roles alike.
Backend Engineering26 questions · 7 topicsLanguage-agnostic service engineering: the protocols, boundaries, and failure handling that sit between a coding round and a full system design round.
System Design63 questions · 12 topicsOpen-ended design rounds broken into the building blocks they draw on, plus full case studies worked end to end with explicit trade-off reasoning.
Behavioural & Culture Fit21 questions · 8 topicsThe round candidates most often under-prepare, treated as a skill with structure rather than small talk, including the rubric interviewers score against.
HR, Screening & Offer18 questions · 6 topicsThe recruiter and HR rounds that gate the technical loop and decide your compensation, where most candidates improvise and lose money.

Latest for this track

hardScenarioDesignConcept

A customer reports seeing another company's records in your admin console. Walk me through the first hour, and then tell me what you change so this class of bug cannot happen again.

Treat it as a confirmed breach until proven otherwise: preserve logs, scope who saw what, and start the disclosure clock alongside the investigation. The cause is almost always tenant scoping living in application code, where one forgotten filter leaks everything - so move enforcement below the code, to row-level security.

Security And Multitenancy4 minsenior, lead, staff

mediumCodingConcept

Edit distance where insert costs 1, delete costs 2 and replace costs 3. Define the DP state and the recurrence, and tell me what changes from the classic version.

The state is unchanged - the minimum cost to transform the first i characters of one string into the first j of the other - because the subproblem structure does not depend on what operations cost. Only the recurrence changes, adding a per-operation weight instead of a uniform 1, and the base cases become multiples of the insert and delete costs rather than i and j.

Dynamic Programming4 minmid, senior

mediumConceptDesignScenario

Two clients open the same record, both edit it, and the second save silently overwrites the first. How would you use ETags to turn that lost update into something the client can see and handle?

Return a strong ETag on GET, require If-Match on writes, and reject a stale token with 412 Precondition Failed so a lost update becomes a visible error rather than silent data loss. What makes it correct is that the comparison and the write must be one atomic operation - an UPDATE guarded by the version in its WHERE clause - because a SELECT then UPDATE reintroduces the race.

Http And Rest4 minmid, senior, staff

hardConceptScenarioDesign

Engineers added a user_id label to a few metrics and the observability bill went up tenfold. Explain what actually happened, and how you would fix it without losing the ability to debug.

Every distinct combination of label values is a separate time series with its own index entry, so an unbounded label multiplies series count by the number of users rather than adding one dimension. Metrics are the wrong tool for per-entity questions: keep labels bounded, move per-user debugging to exemplar-linked traces, and guard against the next unbounded label.

Observability At Scale5 minmid, senior, staff

hardConceptScenarioDesign

A table has forty million rows, thirty-five million of them soft-deleted, and every query for active rows has got slower. Would a partial index help, and what would you have to be careful about?

A partial index only contains rows matching its predicate, so indexing WHERE deleted_at IS NULL stores five million entries instead of forty million - smaller, shallower, and far likelier to stay cached. The catch is the planner only uses it when it can prove the query predicate implies the index predicate, and it does nothing about dead rows still in the heap.

Indexing5 minmid, senior, staff

hardConceptScenarioDesign

A teammate says a saga can just roll everything back if step four fails. What is wrong with that, and what would you tell them to build instead?

A saga has no rollback. Each step already committed in its own database and was visible to everyone, so you can only run new forward transactions that semantically offset it. Compensations are not atomic, some actions cannot be compensated at all, and compensations themselves fail - so a saga needs idempotent handlers and an ordering rule for irreversible steps.

Microservices5 minmid, senior, staff