Skip to content
InfraDrill

Concurrency in a Senior backend interview

Concurrency appears twice in a backend loop: in the coding round, where correct-looking code loses data, and in the deep technical round, where you are asked why. Both grade reasoning about interleavings rather than knowledge of the API.

Check whether this one is a gapTry real questions first — no signup

The check comes with every pass, covers all 8 competencies of a Senior backend loop, and takes 10–15 minutes. It reports each one as Ready, Borderline or a Gap for this level. It never predicts a pass.

Where this usually breaks down at Senior

These are the distinctions the questions on this axis are written to separate — our judgement from writing them and having them reviewed, not a measurement of candidates. We have run no study, so nothing here is a statistic and none of it is phrased as one.

  1. 1.

    Reaching for a lock before deciding ownership

    The first question is which goroutine owns the data. A mutex around shared state is one answer; arranging for it not to be shared is usually cheaper and always easier to reason about. Locks added without that question tend to multiply.

  2. 2.

    Cancellation that stops at your own function

    A context accepted and not propagated leaves work running after the caller has given up. It is where goroutine leaks come from, it is visible in a code review, and it is frequently what the interviewer is looking straight at.

  3. 3.

    Unbounded concurrency

    One goroutine per item is fine until the item count is controlled by a caller. The bound is a design decision, and the interesting half is what happens at it: block the producer, drop the work, or fail the request — three different products.

  4. 4.

    Data races confused with race conditions

    The race detector finds the first. The second survives every tool: check-then-act, read-modify-write, a lock released between the two halves. Correct under -race and wrong under load is the case worth being able to describe.

What a strong answer sounds like: A strong answer says which goroutine owns which piece of state before it says which primitive guards it.

How the check measures it

3 questions drawn on this axis alone — 2 medium and 1 hard for a Senior target, because the bar is the level. Hard counts for one and a half times a medium, which is what makes the verdict relative:

Medium rightHard rightVerdict
2 of 21 of 1Ready
1 of 21 of 1Ready
2 of 20 of 1Borderline
0 of 21 of 1Borderline
1 of 20 of 1Gap
0 of 20 of 1Gap

Three questions is coarse and the report says so beside every verdict. It is enough to separate this axis from the other 7, which is what the check is for — there is no total, no percentage and no single number anywhere in the report.

What there is to practise

127 questions on this axis
82 medium, 45 hard · 7 runnable Go exercises. Easy is not drawn for a Senior target.

Every answer cites the source it was checked against.

Drawn from Go (42), Databases & SQL (22), Python (21), Design Patterns (10), TypeScript & Node (10).

Practised in the Coding and Technical deep dive rounds
Write and fix code under time: correctness, edge cases, concurrency, tests. Practised with the runnable exercises. How things actually work and why they fail: networking, concurrency, performance, security, and diagnosing a symptom to its mechanism.

Practice is arranged by interview round rather than by topic, because loops are graded that way.

The coding round is practised in Go. A TypeScript runner is planned; it is not here yet.

Questions here most often also test go language & runtime, reliability & failure modes, debugging and incident reasoning and data modelling & storage. Nothing on this axis is asked in isolation, which is why the check reports every competency separately rather than averaging them.

One of them, in full

A real question from the free demo, not written for this page. A demo quiz opens with it; the answer, the explanation and the source come when you submit — no account needed.

Concurrencymedium
func worker(jobs <-chan int, done chan<- bool) {
    for j := range jobs { process(j) }
    done <- true
}

The producer finishes sending but never closes jobs. What happens, and what would the program look like from outside?

Answer it on the demo

One axis is not the loop

A Senior backend loop tests 8 competencies, and being strong here says nothing about the other 7. The check covers all of them in one sitting and reports each separately, so what comes back is a profile rather than a score.

See the passesWhat the whole Senior backend loop tests