Go Coding Interview Idioms: The Patterns That Save Time

You chose Go for your interview. Bold move. Go is genuinely good once you know it: minimal syntax, useful stdlib, no Java-style boilerplate tax. But coming from Python or C++, a handful of behaviors will ambush you in ways that feel deeply personal. Learn them once and they stop being traps.

Map Zero-Values Are a Feature, Not a Bug

In Python you'd use defaultdict. In Java you'd call getOrDefault. In Go, you don't need either. Reading a missing key returns the zero value of the value type. No panic. No nil dereference. Just a calm, quiet zero.

This means you can increment a counter without initializing it.

freq := map[string]int{}
for _, word := range words {
    freq[word]++  // safe even if word is new
}

For int the zero value is 0. For bool it is false. For slices it is nil, which appends to cleanly. This covers frequency counts, adjacency lists, and grouping problems.

The same property builds a graph from edges without checking whether the adjacency slice exists:

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

No nil check. No init. You can write this in 10 seconds flat while your interviewer watches.

The Comma-Ok Idiom Shows Up Everywhere

Go uses the comma-ok pattern so often it starts to feel like a personality trait. When you need to know whether a key exists rather than just what value it holds, use the two-value form:

val, ok := myMap[key]
if !ok {
    // key was genuinely absent
}

The same pattern works for type assertions and channel receives, so internalizing it once pays off repeatedly.

// type assertion
n, ok := iface.(int)

// non-blocking channel check
val, ok := <-ch

The interview use: in two-sum, checking for a complement before inserting the current element. Without comma-ok, a value of 0 is indistinguishable from a missing key. That bug is silent and fast-acting.

Append Is Sneaky

Slices in Go are a (pointer, length, capacity) triple. append adds an element and returns a new slice header. If the backing array has room, the new header shares it with the old one. If capacity is full, Go allocates a new array.

The trap: subslices share the backing array, so writing through one can silently corrupt another.

a := []int{1, 2, 3, 4, 5}
b := a[:3]
b = append(b, 99)   // fits in a's capacity
// a is now [1, 2, 3, 99, 5], not [1, 2, 3, 4, 5]

This one bites hardest in backtracking problems. You snapshot the current path before recursing, then wonder why all your results look identical at the end.

// Wrong: all snapshots point to the same underlying slice
results = append(results, path)

// Right: copy into a new slice
results = append(results, append([]int{}, path...))

When a function receives a slice and appends to it, the caller's slice header is unchanged. Mutations to existing elements are visible. Appended elements are not. If the caller needs to see appends, return the slice and reassign.

Sorting Without the Ceremony

For built-in types, sort.Ints, sort.Strings, and sort.Float64s cover the common cases. For custom sorting, sort.Slice takes an inline comparator:

sort.Slice(intervals, func(i, j int) bool {
    return intervals[i][1] < intervals[j][1]  // sort by end time
})

Since Go 1.21, the slices package is the better choice: generic, type-safe, and measurably faster.

import "slices"

slices.Sort(nums)                                  // ascending, any ordered type
slices.SortFunc(items, func(a, b Item) int {
    return a.Priority - b.Priority                 // negative = a before b
})

slices.SortFunc uses a three-way comparator (returns int, not bool). That composes cleanly when you need secondary sort keys.

For binary search, slices.BinarySearch returns the index and a found flag. If found is false, idx is where the target would be inserted. Same semantics as lower_bound in C++ or bisect_left in Python, and exactly what you need for binary search on the answer patterns.

idx, found := slices.BinarySearch(sortedNums, target)

min and max Had an Awkward Past

Before Go 1.21, the language shipped no built-in min or max for integers. You either wrote helpers or used math.Min, which requires float64 and cannot keep a secret about how annoying it is. In Go 1.21+, min and max are built-in and variadic.

smallest := min(a, b, c)
largest  := max(x, y)

LeetCode runs Go 1.21, so the builtins are available there. Older CoderPad setups may not have upgraded. When in doubt, define the helpers at the top. Two lines of boilerplate beats a wrong answer caused by assuming a builtin exists.

One thing min and max do not fix: math.Abs only accepts float64. For integer absolute value, write if n < 0 { n = -n }. One line, no better alternative. Go has opinions.

A Heap Needs Five Methods

Go has no built-in priority queue. You implement heap.Interface from container/heap, which requires exactly five methods. Python needs one import. Go needs five methods, two pointer receivers, and a type cast. This is the interview tax.

import "container/heap"

type MinHeap []int

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

Then use it:

h := &MinHeap{3, 1, 4, 1, 5}
heap.Init(h)
heap.Push(h, 2)
top := heap.Pop(h).(int)

For a max-heap, flip the Less function to h[i] > h[j]. One change inverts the ordering.

Push and Pop use pointer receivers because they change the slice length. Len, Less, and Swap use value receivers. Getting the receiver type wrong compiles fine and produces incorrect heap behavior. No error message. Just silent wrongness.

This is the single most verbose thing Go requires for interview problems. Memorize the five-method shape once and you can write it from memory in about 90 seconds. That time investment returns every time a problem says "k-th largest" or "sliding window maximum."

Strings Are Bytes Until You Range Them

Go strings are immutable sequences of bytes encoded in UTF-8. Indexing s[i] gives a byte (uint8). Ranging over a string gives runes (int32), decoding one UTF-8 code point per step.

s := "café"
fmt.Println(len(s))        // 5 bytes, not 4 characters

for i, r := range s {
    fmt.Println(i, r)      // i is byte offset, r is the rune
}

For ASCII-only inputs, []byte conversion is simpler and avoids the multi-byte complexity entirely. Every LeetCode problem specifies the character set. When it says lowercase English letters, treat the string as bytes.

b := []byte(s)
b[0] = 'C'
result := string(b)

strings.Builder beats repeated concatenation because each s += "x" allocates a new string. Use var sb strings.Builder, write into it in the loop, then sb.String() at the end. The compiler will not save you from the O(n²) version.

The Loop Variable Trap (1.22 Fixed It)

Before Go 1.22, all iterations of a for loop shared one loop variable. Capturing it by reference in a closure meant all closures pointed to the same memory location. You'd write code that looked obviously correct and then watch it print the wrong value five times in a row.

// Go < 1.22: all goroutines print the final value of i
funcs := make([]func(), 5)
for i := 0; i < 5; i++ {
    funcs[i] = func() { fmt.Println(i) }
}

The fix was i := i inside the loop body, shadowing the variable. A two-character patch for a genuinely confusing behavior. Go 1.22 changed the semantics so each iteration gets its own variable. LeetCode is on 1.21 as of mid-2026, so this still matters if your solution spawns closures in a loop. Shadow the variable until you know the platform version.

Sets Are Just Maps

Go has no set type. The language's answer to this is to use a map with throwaway values, which is either elegant minimalism or a quiet acknowledgment that sometimes you just need a Set<T>. The idiomatic choice is map[T]bool or map[T]struct{}.

seen := map[int]struct{}{}
seen[42] = struct{}{}
_, ok := seen[42]  // true
delete(seen, 42)

map[T]struct{} uses no value memory. map[T]bool reads more clearly in interview code. struct{}{} is Go's way of saying "I have no data here" while making sure you know it. For problems with string keys, map[string]bool is what interviewers expect and what you should write.

Go Coding Interview Quick Reference

Task	Idiomatic Go
Counter or frequency map	`m[key]++` (zero value is 0)
Check key exists	`v, ok := m[key]; if !ok {...}`
Copy a slice snapshot	`append([]T{}, slice...)`
Sort ints ascending	`sort.Ints(s)` or `slices.Sort(s)`
Custom sort	`sort.Slice(s, func(i, j int) bool {...})`
Custom sort (1.21+)	`slices.SortFunc(s, func(a, b T) int {...})`
Binary search	`slices.BinarySearch(sorted, target)`
Min / max integers	`min(a, b)`, `max(a, b)` (1.21+)
Absolute value (int)	`if n < 0 { n = -n }`
Priority queue	Implement `heap.Interface` (5 methods)
Set membership	`map[T]bool` or `map[T]struct{}`
Iterate characters	`for _, r := range s` gives runes
Mutable string work	Convert to `[]byte`, mutate, `string(b)`
Fast string concat	`strings.Builder`

If you want to practice these under real interview pressure, SpaceComplexity runs voice-based mock interviews with rubric-based feedback on both your solution and how you communicate through it.

The slice snapshot trap in the append section is the most common source of bugs in backtracking problems. For the binary search idioms in the sorting section, Binary Search Invariant covers the underlying mechanics.