See the model.
Then run the interview.

It may appear to print 0 or 1, but the program has a data race and no result is guaranteed. The go statement is ordered before the new goroutine starts; it does not order that goroutine’s completion before the print. The process can also finish without waiting for detached work.

Use a channel or WaitGroup to establish completion. For example, write n, close done, receive from done, then read n.

Probe: Would time.Sleep make it correct? No. Timing is not synchronization.

Go Memory Model · Data Race Detector

The first send fills the single slot. The second send blocks because the buffer is full and no other goroutine can receive, so the runtime reports a deadlock. Capacity two happens to let this snippet proceed, but it encodes an assumed burst size rather than fixing the producer/consumer design.

An unbuffered send waits for a matching receive. A buffered send waits only when the buffer is full. Buffers decouple timing up to a bound and provide backpressure at that bound.

Probe: When is a capacity-one channel meaningful? Examples include a latest pending signal, a one-token semaphore, or deliberately bounded handoff.

Spec: channel types · Memory model: channel communication

No individual worker can know that all sends are finished. A coordinator waits for every worker, then closes the shared output while the consumer is already able to drain it.

go func() {
    wg.Wait()
    close(results)
}()

for result := range results { use(result) }

Closing expresses “no more values,” not “please stop.” A receive from a closed channel returns remaining buffered values, then the zero value with ok == false. Sending to or closing an already-closed channel panics. A nil channel blocks forever, which can intentionally disable a select case.

Probe: Why not call wg.Wait() before the range in the same goroutine? Workers may block sending while nobody drains results.

Go blog: pipelines and cancellation · Package sync.WaitGroup

The value receiver copies Cache, including its mutex. The copied map field still refers to shared map data, but concurrent calls can lock different mutex copies, so they do not exclude each other. Use a pointer receiver, keep the mutex with the state it guards, and do not copy a mutex after first use.

func (c *Cache) Put(k, v string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.m[k] = v
}

Every access participating in the invariant—including reads—must follow the same locking rule. Verify exercised paths with go test -race ./....

Probe: When would you choose RWMutex? Only after a clear read-heavy need; it adds complexity and is not automatically faster.

Package sync.Mutex · Data Race Detector

After the first receive, no receiver remains. The producer eventually blocks forever on its next send, retaining its stack and anything it references. Give the operation a cancellation path and make the sending goroutine own closure of its output.

func produce(ctx context.Context) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for i := 0; ; i++ {
            v := expensive(i)
            select {
            case out <- v:
            case <-ctx.Done():
                return
            }
        }
    }()
    return out
}

func first() int {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()
    return <-produce(ctx)
}

If expensive can itself block, it also needs to accept and observe cancellation. Cancellation must reach every blocking boundary.

Probe: Is closing out a cancellation mechanism for the producer? No; a receiver should not close a sender-owned data channel, and a later send would panic.

Go blog: pipelines and cancellation · Go blog: context