LeetCode in Go Interview Prep: Slices, Maps, and Goroutines for Coding Rounds

LeetCode in Go interview prep is about using a small language with discipline. Go gives you fast compilation, readable control flow, practical slices and maps, and enough concurrency primitives to answer senior follow-ups. It also gives you fewer built-in data structures than Java or Python, so you need to know how to build stacks, queues, heaps, and sets from the basics. The best Go candidates write direct code, explain slice and map behavior clearly, and do not force goroutines into problems that should stay single-threaded.

This guide covers the Go idioms that matter in coding rounds: slices, maps, sorting, heap patterns, strings, recursion, and goroutines for follow-up discussions. The target is not cleverness. The target is correct, readable, testable code under a 35-45 minute interview clock.

Where Go LeetCode skill shows up

Go is common in cloud infrastructure, platform engineering, distributed systems, developer tools, fintech infrastructure, Kubernetes-adjacent teams, and backend services. Interviewers who let you use Go generally value simplicity. They expect explicit error-free code and clear reasoning about memory and concurrency.

| Interview need | Go tool | Watch-out | |---|---|---| | Dynamic arrays | []int, append | Slice aliasing and capacity | | Hashing | map[K]V | Nil map writes, random iteration order | | Sets | map[T]bool or map[T]struct{} | Zero values and presence checks | | Sorting | sort.Ints, sort.Slice | Comparator must define strict order | | Heaps | container/heap | Boilerplate, pointer receiver methods | | Queues | Slice with head index | Avoid repeated front reslicing leaks | | Concurrency | goroutines, channels, sync.WaitGroup | Usually a follow-up, not core algorithm |

Because Go has limited syntactic sugar, strong solutions are often pleasantly boring. That is a feature.

Slices: the most important Go interview concept

A slice is a view over an underlying array: pointer, length, and capacity. That model explains most slice bugs. append may reuse the same underlying array or allocate a new one. A sub-slice can keep a large backing array alive. Mutating through one slice can affect another if they share storage.

Use slices as stacks:

stack := []int{}
stack = append(stack, x)
x = stack[len(stack)-1]
stack = stack[:len(stack)-1]

Use slices as queues with a head index:

q := []int{start}
for head := 0; head < len(q); head++ {
    node := q[head]
    for _, nei := range graph[node] {
        if !seen[nei] {
            seen[nei] = true
            q = append(q, nei)
        }
    }
}

This avoids O(n) front removal. Repeated q = q[1:] is okay for tiny queues but can retain the old array and make memory behavior awkward. A head index is simple and interview-friendly.

When creating 2D slices, allocate each row separately:

dp := make([][]int, rows)
for r := range dp {
    dp[r] = make([]int, cols)
}

Do not reuse the same row slice unless shared mutation is intentional.

Maps: frequency, sets, and graph adjacency

Go maps are reference-like structures. A nil map can be read, but writing to it panics. Always initialize before writes:

freq := make(map[int]int)
for _, x := range nums {
    freq[x]++
}

For sets, either map[int]bool or map[int]struct{} is accepted. struct{} uses no storage for the value, but bool is often clearer. In an interview, clarity wins unless memory is central.

Presence checks should use the two-value form when zero values are ambiguous:

idx, ok := first[prefix]
if ok {
    // prefix was present, even if idx is 0
}

Map iteration order is randomized. Never rely on it for sorted output or deterministic tie-breaking. If order matters, collect keys and sort them.

For graph adjacency:

graph := make(map[int][]int)
for _, e := range edges {
    a, b := e[0], e[1]
    graph[a] = append(graph[a], b)
    graph[b] = append(graph[b], a)
}

For dense node IDs from 0 to n-1, [][]int is usually faster and cleaner.

Sorting and binary search in Go

Use sort.Ints(nums) for integers and sort.Strings(words) for strings. Use sort.Slice for custom objects:

sort.Slice(intervals, func(i, j int) bool {
    if intervals[i][0] == intervals[j][0] {
        return intervals[i][1] < intervals[j][1]
    }
    return intervals[i][0] < intervals[j][0]
})

The comparator must be consistent. Do not return <=; equal elements should not be “less” than each other.

For binary search, sort.Search is useful once you know the pattern:

idx := sort.Search(len(nums), func(i int) bool {
    return nums[i] >= target
})

That returns the first index where the predicate is true. It is excellent for lower bound, answer-space search, and monotonic conditions. If the interviewer seems unfamiliar with it, briefly explain the invariant or write the binary search manually.

Heaps in Go without panic

Go’s heap support is powerful but verbose. You define a type implementing heap.Interface: Len, Less, Swap, Push, and Pop. The common mistake is forgetting that Push and Pop need pointer receivers because they modify the slice.

type IntHeap []int
func (h IntHeap) Len() int { return len(h) }
func (h IntHeap) Less(i, j int) bool { return h[i] < h[j] }
func (h IntHeap) Swap(i, j int) { h[i], h[j] = h[j], h[i] }
func (h *IntHeap) Push(x any) { *h = append(*h, x.(int)) }
func (h *IntHeap) Pop() any {
    old := *h
    x := old[len(old)-1]
    *h = old[:len(old)-1]
    return x
}

For pairs, define a struct:

type Item struct { cost, node int }

Then Less can compare cost. For a max-heap, reverse Less. During the interview, it is fine to say, “Go’s heap requires boilerplate; I’ll define a small type and use cost as the priority.” That keeps the focus on the algorithm.

Strings, bytes, and runes

Go strings are immutable byte sequences. Indexing a string gives a byte, not a Unicode character. For many LeetCode string problems with lowercase English letters, bytes are perfect:

count := [26]int{}
for i := 0; i < len(s); i++ {
    count[s[i]-'a']++
}

If the problem involves Unicode characters, convert to []rune or range over the string:

for _, r := range s {
    // r is a rune
}

Be clear about the assumption. Saying “The prompt says lowercase English letters, so byte indexing is safe” is a strong signal. If the prompt is user-facing text, bytes may be wrong.

Use strings.Builder for repeated string construction. Repeated ans += piece in a loop can become quadratic because strings are immutable.

Goroutines and concurrency essentials

Most coding rounds should not use goroutines. A LeetCode graph traversal does not become better because you parallelized it; it becomes harder to reason about. Still, Go interviewers may ask concurrency follow-ups. Know the essentials.

Goroutines are lightweight concurrent functions started with go f(). They need synchronization if they share state.

Channels communicate values between goroutines. Unbuffered channels synchronize sender and receiver. Buffered channels allow a fixed amount of queued work.

sync.WaitGroup waits for a group of goroutines to finish. Always call Done, often via defer, and avoid calling Add after goroutines may already be waiting.

sync.Mutex protects shared state. A map is not safe for concurrent writes unless guarded or replaced with sync.Map for specific use cases.

context.Context carries cancellation and deadlines in real systems. If designing a crawler or worker pool, mention context cancellation, bounded parallelism, and error propagation.

A good follow-up answer: “The algorithm is single-threaded O(n). If we needed to process many independent files, I would partition by file, use a bounded worker pool, collect results over a channel, and merge with a mutex or single aggregator goroutine.” That shows concurrency judgment without corrupting the core solution.

Common Go traps

1. Nil map writes. var m map[int]int; m[1] = 2 panics. Use make.
2. Slice aliasing. Appending to one slice can affect another if capacity is shared.
3. Loop variable capture. In goroutines, capture a local copy of the loop variable if needed.
4. Map iteration order. It is not deterministic.
5. Using bytes for Unicode. Indexing strings returns bytes.
6. Front-removing slices. Prefer a head index for queues.
7. Forgetting pointer receivers in heaps. Push and Pop must mutate the heap.
8. Integer overflow on int. On LeetCode, int is usually enough, but use int64 for sums/products when bounds demand it.
9. Shadowing variables with :=. Accidentally creating a new variable inside a block can break state updates.
10. Overengineering concurrency. Goroutines are a tool, not a badge.

A focused Go prep checklist

Be able to write these from memory: stack with slice, queue with head index, frequency map, set, adjacency list, DFS recursion, BFS loop, sort.Slice, sort.Search, strings.Builder, and a minimal heap type. Then practice explaining slice semantics in one minute. Many Go bugs become obvious when you can say what length, capacity, and backing array mean.

For a two-week plan, start with arrays and maps, then add graph traversal and sorting, then do heap and interval problems, then dynamic programming, then two mock interviews. Include at least one concurrency design follow-up, but do not let goroutines distract from algorithm fundamentals.

What strong Go interview code feels like

Strong Go code is explicit and calm. It uses slices for ordered state, maps for membership and counts, small structs for named pairs, and helper functions only when they reduce noise. It states assumptions about bytes versus runes. It avoids clever generic abstractions that burn time. And when concurrency comes up, it explains goroutines, channels, and synchronization as design tools rather than forcing them into every answer. That is the sweet spot for LeetCode in Go.

LeetCode in Go interview prep: a final mock-round drill

A good Go drill is to reimplement the same algorithm twice: once with the most direct slices and maps, and once after explaining the memory behavior. For BFS, use a slice queue with a head index. Then explain that the queue grows by appending and that head marks the next unread element. For dynamic programming, allocate a 2D slice row by row. Then explain why each row needs its own backing array. For grouping, use map[string][]int and state that appending to a nil slice is safe, while writing to a nil map is not.

Next, practice one problem that needs sorting and one that needs a heap. Sorting should feel effortless: sort.Ints for numbers, sort.Slice for structs or intervals, and a comparator that never uses <=. Heap practice is mostly about boilerplate. Write the interface once from memory so you are not surprised by Push(x any) and Pop() any during the real round.

End with a concurrency follow-up even if the problem is single-threaded. Say: “I would not use goroutines inside this algorithm because shared visited state would add synchronization overhead. If the work were many independent inputs, I would use a bounded worker pool, a WaitGroup, and a results channel.” That answer shows Go fluency and restraint. In Go interviews, restraint is a signal: simple sequential code first, concurrency only when the problem structure earns it.

One extra rehearsal: explain why append can change the backing array and why that matters when another slice still points at the old storage. If you can describe that clearly, many slice edge cases become straightforward during the interview.

Related guides

• LeetCode in C++ Interview Prep: STL, Iterators, and Bit-Level Idioms — A C++ LeetCode prep guide for using the STL confidently, avoiding iterator and lifetime bugs, and applying bit-level idioms only when they clarify the algorithm.
• LeetCode in Java Interview Prep: Collections, Streams, and Concurrency Essentials — A Java-focused LeetCode guide covering the collections you actually use in coding rounds, when streams help or hurt, and the concurrency concepts worth knowing for senior interviews.
• LeetCode in JavaScript Interview Prep: Map, Set, and Prototype Tricks — A JavaScript LeetCode prep guide for Node-based interviews, with practical Map and Set patterns, array performance notes, prototype awareness, and common language traps.
• LeetCode in Python Interview Prep: Idioms, Collections, and Time-Saving Tricks — A practical Python LeetCode prep guide for using collections, heapq, bisect, memoization, and language idioms without hiding the algorithm. Use it to write faster interview code and explain your tradeoffs clearly.
• Coding Interview Patterns Cheatsheet: 15 Templates That Solve LeetCode — Skip the grind. These 15 reusable patterns cover 90% of LeetCode problems and will get you through any FAANG-level coding interview.