Ошибка	Последствие
Считать, что slice передаётся «по ссылке»	Не объяснить, почему `append` внутри функции иногда виден снаружи, а иногда нет
Думать, что копия slice независима от оригинала	Баг с alias — запись через одну копию портит элементы другой
Путать `len` и `cap`	Неверное представление о том, когда `append` реаллоцирует backing array
Думать, что `append` расширяет backing array на месте	Не объяснить, почему после реаллокации старые срезы не видят новых элементов
Не присваивать результат `append` обратно	Потеря нового заголовка — обновлённые `len`/`pointer` пропадают
Путать `nil`-срез и пустой срез	Оба `len 0`, но `nil` равен `nil` и маршалится в `null`, а `[]int{}` — в `[]`
Забыть трёхиндексное `s[low:high:max]` при нарезке общего буфера	`append` в подрез тихо перезапишет данные соседнего среза
Считать map деревом или плоским массивом	Не объяснить overflow-бакеты, рандомизацию итерации и поведение при коллизиях
Полагаться на порядок обхода map	Порядок намеренно рандомизирован — для детерминизма соберите и отсортируйте ключи
Брать адрес элемента map через `&m[k]`	Код не компилируется — элемент map не адресуем из-за эвакуации бакетов
Думать, что запись в `nil` map «просто ничего не сделает»	На деле `panic: assignment to entry in nil map` в рантайме
Путать `len(s)` строки с числом символов	Для многобайтовых рун это разные числа — `len` считает байты UTF-8
Считать `string(b)` и `[]byte(s)` бесплатными	Каждая конвертация копирует все байты — это аллокация
Ждать C-подобного переполнения буфера при выходе за границу	Go проверяет границы и паникует `index out of range`, а не портит соседнюю память

intermediate

Slices, Maps & Strings

Go's built-in collections from the basics up — the slice and its three-word header, slice expressions, growth and aliasing, maps with comma-ok and the hmap layout, the nil map, strings as immutable bytes, and memory safety.

go-data-structures

Practice: 25 questions · 9 tasks →

Sections

Contents

Detailed explanation

Slices, Maps & Strings

Go's built-in collections look deceptively simple: you write []int, map[string]int, string and just use them. But each has a concrete layout, and it leaks out exactly where you don't expect it. A slice is not an array or a pointer but a three-word header over a separate backing array. A map is not a tree or a flat array but a bucketed hash table. A string is not text but two immutable words. Until you know this layout, the behaviour stays a set of unexplained surprises.

And those surprises are standard interview questions. A slice is passed "by value," but two copies of the header share one array — a write through one is visible through the other, hence the aliasing bugs. append past cap allocates a new array, and old slices stop seeing what was added. Writing to a nil map does not "do nothing" — it panics, even though reading from that same nil map is safe. &m[k] does not compile, and the reason is the incremental bucket evacuation during growth. And indexing a slice out of bounds does not corrupt neighbouring memory as in C — it panics. We take the topic layer by layer — from what a slice is to map rehashing and memory safety.

Topic map

Arrays vs slices — an array is a fixed-size value copied whole; a slice is a header over a shared backing array, and that difference explains everything else.
The slice header — what a slice is and the three machine words {pointer, len, cap}; why a copy of the header shares elements with the original.
Slice expressions — s[low:high] and the full s[low:high:max], and how they set the new slice's len and cap.
Slice growth — why append past cap allocates a new backing array, what the growth factor is, and how a nil slice differs from an empty one.
Slice aliasing — two slices over one backing array, the classic append trap, and protection via the three-index expression.
Map basics — make(map[K]V), the v, ok := m[k] check, the zero value for a missing key, and the deliberately randomized iteration order.
Map internals — the runtime hmap struct, 8-slot buckets, tophash, overflow buckets, growth, and why &m[k] does not compile.
The nil map — reading a nil map is safe and yields the zero value, while writing panics with assignment to entry in nil map.
Strings — a string is immutable UTF-8 bytes; len counts bytes, range yields runes; the {pointer, len} header is 16 bytes, and converting to []byte copies.
Memory safety — slice indexing is bounds-checked and panics instead of corrupting neighbouring memory; how the three-index expression bounds cap.

Common mistakes and traps

Mistake	Consequence
Thinking a slice is passed "by reference"	Can't explain why an `append` inside a function is sometimes visible outside and sometimes not
Thinking a slice copy is independent of the original	The aliasing bug — a write through one copy corrupts the other's elements
Confusing `len` and `cap`	A wrong mental model of when `append` reallocates the backing array
Thinking `append` extends the backing array in place	Can't explain why old slices don't see new elements after a realloc
Not reassigning the result of `append`	The new header is lost — the updated `len`/`pointer` vanish
Confusing a `nil` slice with an empty slice	Both `len 0`, but `nil` equals `nil` and marshals to `null`, while `[]int{}` marshals to `[]`
Forgetting the three-index `s[low:high:max]` when slicing a shared buffer	An `append` into the subslice silently overwrites a neighbouring slice's data
Thinking a map is a tree or a flat array	Can't explain overflow buckets, iteration randomization, or collision behaviour
Relying on map iteration order	The order is deliberately randomized — collect and sort keys for determinism
Taking the address of a map element via `&m[k]`	Does not compile — a map element is not addressable because of bucket evacuation
Thinking writing to a `nil` map "just does nothing"	In fact `panic: assignment to entry in nil map` at runtime
Confusing a string's `len` with its character count	For multibyte runes these differ — `len` counts UTF-8 bytes
Treating `string(b)` and `[]byte(s)` as free	Each conversion copies all the bytes — it's an allocation
Expecting a C-style buffer overflow on an out-of-bounds index	Go bounds-checks and panics `index out of range` rather than corrupting neighbouring memory

Why it matters for interviews

Built-in data structures are a mandatory topic in any Go interview. They don't ask the []T or map[K]V syntax but whether you have a working model of what sits underneath and how the layout leaks into behaviour.

What interviewers usually check:

What a slice is, which three fields make up the header, and how they change on a reslice.
Why an array is copied whole but a slice only by header, and what aliasing bugs that leads to.
How a slice grows on append past cap, why you must reassign the result, and how a nil slice differs from an empty one.
The map layout — buckets, tophash, overflow buckets, growth, why &m[k] does not compile, and why iteration order is randomized.
Why reading from a nil map is safe but writing panics.
What a string header consists of, why len counts bytes but range yields runes, and why converting to []byte copies.
Why indexing a slice out of bounds panics rather than corrupting memory.

The typical wrong answer: "a slice is a reference type, passed by reference." That opens up the discussion that it's the three-word header that is copied by value — which is why an append that reallocated the backing array is not visible outside the function, while an append within cap is visible through the shared array.

Why it matters

Slice, map, and string look simple until you hit their internal layout — and it leaks out in the most unexpected places. A slice is copied by header, and two copies quietly share one backing array — hence the bug where append corrupted a neighbouring slice. Writing to a nil map crashes the program with a panic, and &m[k] doesn't even compile. A string's len counts bytes, not characters. Without knowing that a slice is three words, a map is a bucketed hash table, and a string is two immutable words, you can't explain any of these on an interview.

Ошибка	Последствие
Считать, что slice передаётся «по ссылке»	Не объяснить, почему `append` внутри функции иногда виден снаружи, а иногда нет
Думать, что копия slice независима от оригинала	Баг с alias — запись через одну копию портит элементы другой
Путать `len` и `cap`	Неверное представление о том, когда `append` реаллоцирует backing array
Думать, что `append` расширяет backing array на месте	Не объяснить, почему после реаллокации старые срезы не видят новых элементов
Не присваивать результат `append` обратно	Потеря нового заголовка — обновлённые `len`/`pointer` пропадают
Путать `nil`-срез и пустой срез	Оба `len 0`, но `nil` равен `nil` и маршалится в `null`, а `[]int{}` — в `[]`
Забыть трёхиндексное `s[low:high:max]` при нарезке общего буфера	`append` в подрез тихо перезапишет данные соседнего среза
Считать map деревом или плоским массивом	Не объяснить overflow-бакеты, рандомизацию итерации и поведение при коллизиях
Полагаться на порядок обхода map	Порядок намеренно рандомизирован — для детерминизма соберите и отсортируйте ключи
Брать адрес элемента map через `&m[k]`	Код не компилируется — элемент map не адресуем из-за эвакуации бакетов
Думать, что запись в `nil` map «просто ничего не сделает»	На деле `panic: assignment to entry in nil map` в рантайме
Путать `len(s)` строки с числом символов	Для многобайтовых рун это разные числа — `len` считает байты UTF-8
Считать `string(b)` и `[]byte(s)` бесплатными	Каждая конвертация копирует все байты — это аллокация
Ждать C-подобного переполнения буфера при выходе за границу	Go проверяет границы и паникует `index out of range`, а не портит соседнюю память

intermediate

Slices, Maps & Strings

go-data-structures

Practice: 25 questions · 9 tasks →

Sections

Contents

Detailed explanation

Slices, Maps & Strings

Topic map

Arrays vs slices — an array is a fixed-size value copied whole; a slice is a header over a shared backing array, and that difference explains everything else.
The slice header — what a slice is and the three machine words {pointer, len, cap}; why a copy of the header shares elements with the original.
Slice expressions — s[low:high] and the full s[low:high:max], and how they set the new slice's len and cap.
Slice growth — why append past cap allocates a new backing array, what the growth factor is, and how a nil slice differs from an empty one.
Slice aliasing — two slices over one backing array, the classic append trap, and protection via the three-index expression.
Map basics — make(map[K]V), the v, ok := m[k] check, the zero value for a missing key, and the deliberately randomized iteration order.
Map internals — the runtime hmap struct, 8-slot buckets, tophash, overflow buckets, growth, and why &m[k] does not compile.
The nil map — reading a nil map is safe and yields the zero value, while writing panics with assignment to entry in nil map.
Strings — a string is immutable UTF-8 bytes; len counts bytes, range yields runes; the {pointer, len} header is 16 bytes, and converting to []byte copies.
Memory safety — slice indexing is bounds-checked and panics instead of corrupting neighbouring memory; how the three-index expression bounds cap.

Common mistakes and traps

Mistake	Consequence
Thinking a slice is passed "by reference"	Can't explain why an `append` inside a function is sometimes visible outside and sometimes not
Thinking a slice copy is independent of the original	The aliasing bug — a write through one copy corrupts the other's elements
Confusing `len` and `cap`	A wrong mental model of when `append` reallocates the backing array
Thinking `append` extends the backing array in place	Can't explain why old slices don't see new elements after a realloc
Not reassigning the result of `append`	The new header is lost — the updated `len`/`pointer` vanish
Confusing a `nil` slice with an empty slice	Both `len 0`, but `nil` equals `nil` and marshals to `null`, while `[]int{}` marshals to `[]`
Forgetting the three-index `s[low:high:max]` when slicing a shared buffer	An `append` into the subslice silently overwrites a neighbouring slice's data
Thinking a map is a tree or a flat array	Can't explain overflow buckets, iteration randomization, or collision behaviour
Relying on map iteration order	The order is deliberately randomized — collect and sort keys for determinism
Taking the address of a map element via `&m[k]`	Does not compile — a map element is not addressable because of bucket evacuation
Thinking writing to a `nil` map "just does nothing"	In fact `panic: assignment to entry in nil map` at runtime
Confusing a string's `len` with its character count	For multibyte runes these differ — `len` counts UTF-8 bytes
Treating `string(b)` and `[]byte(s)` as free	Each conversion copies all the bytes — it's an allocation
Expecting a C-style buffer overflow on an out-of-bounds index	Go bounds-checks and panics `index out of range` rather than corrupting neighbouring memory

Why it matters for interviews

What interviewers usually check:

What a slice is, which three fields make up the header, and how they change on a reslice.
Why an array is copied whole but a slice only by header, and what aliasing bugs that leads to.
How a slice grows on append past cap, why you must reassign the result, and how a nil slice differs from an empty one.
The map layout — buckets, tophash, overflow buckets, growth, why &m[k] does not compile, and why iteration order is randomized.
Why reading from a nil map is safe but writing panics.
What a string header consists of, why len counts bytes but range yields runes, and why converting to []byte copies.
Why indexing a slice out of bounds panics rather than corrupting memory.

Why it matters

Слайсы, мапы и строки

Слайсы, мапы и строки

Карта темы

Частые ошибки и ловушки

Значение для собеседований

Slices, Maps & Strings

Slices, Maps & Strings

Topic map

Common mistakes and traps

Why it matters for interviews

Слайсы, мапы и строки

Слайсы, мапы и строки

Карта темы

Частые ошибки и ловушки

Значение для собеседований

Slices, Maps & Strings

Slices, Maps & Strings

Topic map

Common mistakes and traps

Why it matters for interviews