Interview: the live coding round

What they score while you type, and the Go-specific things that lose marks.

Topic 97 of 98 · 5 min to read · 50 min to build

After this topic you can

Clarify inputs, edge cases and complexity before writing code.
Write bounded-concurrency code with a semaphore and errgroup from memory.
Fix the Go-specific mistakes that lose marks, such as ignored errors and unclosed resources.

The live round is rarely about the algorithm. They are watching whether you handle errors, whether your concurrency is safe, and whether you write code the rest of the team could maintain.

Before you type a line

Restate the problem in one sentence and get agreement. A good solution to a different question still fails the round.
Ask about scale and input. "Is this thousands or millions?" "Can the input be empty, or unsorted, or duplicated?" These change the answer, and asking them is part of what is scored.
Say your plan out loud before coding. Thinking silently for ninety seconds teaches them nothing about you.

The things that lose marks in Go specifically

What you do	What they write down
`v, _ := doThing()`	ignores errors
`panic(err)` in library code	does not understand panic vs error
one goroutine per item, unbounded	has not run this under load
no `ctx` parameter on anything doing I/O	has not written a production service
mutating a shared map from goroutines	would ship a race
`s := ""` then `+=` in a loop	does not know strings are immutable
`interface{}` everywhere	throws away the type system
no test, and no mention of one	does not test

The problems that come up

Concurrent fetch of N URLs with a concurrency limit — one of the most common Go live questions. errgroup.SetLimit, or a semaphore channel plus a WaitGroup.
Word frequency count, top K — a map, then move it to a slice and slices.SortFunc, because maps have no order.
An LRU cache — a map plus a doubly linked list, with a mutex if they say "thread-safe" (and ask whether they want it thread-safe).
A rate limiter — token bucket. Say time.Ticker plus a buffered channel, or that x/time/rate already does it. Worked solution in the concurrency interview topic, with the worker pool and a concurrency-safe cache.
Parse a log file / stream — bufio.Scanner, not io.ReadAll, and say why: constant memory over a large file.
A worker pool — see the concurrency topic. Marked on Add before go, sender closes, and ctx.Done().

The bounded-concurrency answer, memorised

have this in your fingers

1g, ctx := errgroup.WithContext(ctx)
2g.SetLimit(10)                       // bounded — say this out loud
3
4results := make([]Result, len(urls)) // indexed writes: no lock needed
5for i, u := range urls {
6	i, u := i, u                     // harmless in 1.22+, and it shows you know why
7	g.Go(func() error {
8		r, err := fetch(ctx, u)
9		if err != nil {
10			return fmt.Errorf("fetch %s: %w", u, err)
11		}
12		results[i] = r
13		return nil
14	})
15}
16
17if err := g.Wait(); err != nil {     // first error cancels the rest
18	return nil, err
19}

Writing to distinct indices of a preallocated slice is race-free and needs no mutex. Say that out loud. Reaching for a lock or a channel here is a common over-complication.

While you type

Handle errors as you go. Do not say "I will add error handling later". By then they have already written it down.
Name things properly even under pressure. users, not arr. It costs nothing.
Say the complexity out loud when you finish a function: "this is O(n) with one pass and one map".
Mention the test you would write, even if there is no time to write it. "I would table-test empty input, one element, and duplicates."
If you get stuck, say so out loud. "I am choosing between a map and a sorted slice — the map is O(1) lookup but loses order, and I need order at the end, so I will do both." That is a strong signal, not a weak one.

When you finish early

Offer the edge cases yourself: empty input, one element, duplicates, nil, integer overflow, unicode in strings.
Offer the concurrency version, or the reason you did not: "this is CPU-light and the list is small, so goroutines would cost more than they save."
Offer what you would change for production: a context, a limit, a metric, a test.

Note: A slightly simpler solution you can explain completely beats a clever one you cannot. That is true in the interview for the same reason as in the codebase: someone has to read it at 3am.

The short version

Restate the problem, ask about scale and input, and say the plan before typing.
Errors, ctx, and bounded concurrency are what actually get marked in a Go round.
Have the errgroup.SetLimit fetch pattern memorised. It is one of the most common questions.
Narrate stuck moments. Silence scores worse than an imperfect answer.

Remember: They are not hiring the algorithm. They are hiring the person whose code the team will have to read.

Build this before moving on

Do the concurrent URL fetch with a limit of 5, from a blank file, in under fifteen minutes, with error wrapping, a context, and a table-driven test. Then delete it and do it again tomorrow.

Then try these in your own editor

1Implement top-K word frequency, then state its complexity out loud.
2Write a thread-safe LRU cache and run it under -race with concurrent readers and writers.
3Parse a 1GB file with bufio.Scanner and watch memory stay flat. Then try io.ReadAll and watch it not.
4Set a 15-minute timer and solve one problem end to end, talking through it the whole time as if someone were watching.

Official documentation

Check yourselfTake the Interview preparation test