Skip to content
InfraDrill

Concurrency in a Senior interview

Concurrency belongs to two rounds in our practice: the coding round, where correct-looking code loses data, and the deep technical round, where you are asked why. Both test reasoning about interleavings rather than knowledge of the API.

An axis of our Senior backend target.

Check whether this one is a gapTry the free demo

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

Patterns our questions are designed to test 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 one way goroutine leaks start, and our questions test whether cancellation reaches past the function that accepts the context.

  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 behaviours a caller will notice.

  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 others in your target, 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

125 questions on this axis
81 medium, 44 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), TypeScript & Node (13), Design Patterns (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, so you can work through it one round at a time.

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. Few questions on this axis test it alone, which is why the check reports every competency separately rather than averaging them.

One of them, in full

A 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

This axis is one of 8 in our Senior backend target, and being strong here says nothing about the others. 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 we check for the whole Senior backend target