Slices in Go: a window onto somebody else's array, two paths through append, and a growth rule everyone remembers wrong

What is actually being asked

A slices interview almost always walks the same ladder, and it helps to know it in advance — you can see where the conversation is heading:

1. "What is a slice?" — testing whether you know about the header. "A dynamic array" closes this question and opens the next one.
2. "What does append do?" — testing whether you know there are TWO cases and that they differ by whether there is spare capacity.
3. "Why did the neighbouring slice change?" (with code on paper) — testing the first two together. This is the central question of the topic.
4. "What is the complexity of append?" — testing whether you distinguish an amortized bound from the cost of a single call.

All four are the same question from different angles: do you know that a slice does not own its data. The lesson follows that ladder.

Base: a slice is a window onto somebody else's array

Start with what a slice is even for. An array in Go fixes how many elements it holds and lives with that number to the end: [6]int is exactly six numbers and it will never have others. That is inconvenient almost always: data arrives in whatever quantity it arrives in, and sometimes you need the whole set, sometimes a piece of it. A slice is the answer to that — a way to look at part of an array and speak about that part as a whole.

The key word is "look". A slice does not take the elements for itself and does not copy them: it only describes which stretch of somebody else's array is visible through it. Hence the main surprise of the topic: take a piece of a slice, write something into that piece, and the original array changes, and with it every other slice looking at the same cells.

Here is what that looks like. One array, two slices over it — and one write:

arr := [6]int{10, 20, 30, 40, 50, 60}
a := arr[1:4]     // [20 30 40]
b := arr[3:6]     // [40 50 60]
 
a[2] = 99

A run of bench/goslice/internals.go prints what became of it:

array           [10 20 99 40 50 60]   ← was [10 20 30 40 50 60]
a               [20 30 99]
b               [99 50 60]

One write — three changed values, and not one of them is a copy. a[2] and b[0] are the same cell of the array.

That is the whole model everything else is derived from: a slice does not own its data. It describes which stretch of somebody else's array is visible through it — a window, not a box. The specification says so verbatim:

Keep that sentence at hand: it alone answers three different interview questions. Since the storage is shared — appending to one slice may write into somebody else's cells. Since the array may change — appending must return a new window. Since a window pins the whole array — a short slice keeps a long one alive.

That is already enough to answer the basic interview question: a slice is not a container holding its own data, it is a window onto somebody else's array. Everything below is about what that window is made of, what happens when the data stops fitting into it, and what all of that costs.

Mechanism 1: slices, arrays and strings are three different things

Go has three "sequences" and they get conflated constantly. The difference shows up in one number — the size of the value itself:

[]int       24 bytes   — three words: pointer, length, capacity
string      16 bytes   — two words: pointer and length
[5]int      40 bytes   — an ARRAY is a value: five numbers of eight

Read that table again: the size of [5]int depends on the element count, the size of []int does not. That is the whole difference. An array in Go is a value, and func f(a [5]int) gets a copy of all five numbers. A slice is a descriptor, and func f(s []int) gets a copy of three words with somebody else's memory behind them.

Two practical conclusions follow immediately, worth keeping ready:

• "Pass a slice by pointer for speed" is meaningless: you save eight bytes out of twenty-four. But *[1000]int instead of [1000]int does make sense — there you would be copying eight kilobytes.
• A function can change your data while returning nothing: s[0] = 1 inside is visible outside, because the pointer in the copied header is the same.

Now look at the header itself and at how an expression turns into its three fields. Switch expressions — the figure stays the same, the numbers change:

The thing to take from that picture: the red zone is not "free space". Those are cells of the original array that somebody else considers theirs. s[1:3] does not "cut off a piece" — it opens a window with somebody else's data just past its right edge, and append writes exactly there.

The rule from the specification, worth being able to quote: for s[low:high] the capacity is cap(a) - low, and for the three-index form s[low:high:max] it is max - low. The second is the only way to cut the tail off.

Mechanism 2: what append does

append is not a function in the ordinary sense but a built-in operation the compiler expands into two paths.

The fast path: there is spare capacity. Then nothing interesting happens: the element goes into cell s[len], the length grows by one, the pointer and capacity stay as they were. No allocation, no copying. That is why append in a loop over a pre-allocated slice is nearly free.

The slow path: capacity ran out. growslice in the runtime is called, and it does four things:

1. computes the new capacity — that is nextslicecap, dissected under "Deeper";
2. converts it to bytes and rounds up to an allocator size class;
3. allocates a new array;
4. copies the len elements already laid down and adds the new one.

Hence the answer to the question that usually comes next: why does append return a slice? Because on the slow path the array is a different one, and the pointer in the old header leads elsewhere. append cannot change the caller's header — that was passed by value. Returning the new pointer and length is the only way to report them.

And hence the central question of the topic: on the fast path append writes into an array that already exists, and that array may be shared. Watch what that looks like step by step — and how the same operation behaves once capacity runs out:

The second scenario in that picture matters more than the first. Without it you walk away with the rule "append is dangerous", which is wrong: what is dangerous is precisely the combination "length below capacity" — which is precisely what s[1:3] creates.

Mechanism 3: deletion, insertion and the price of shifting

The canonical deletion idiom looks identical for any index:

s = append(s[:i], s[i+1:]...)

Before looking at the price it is worth understanding what actually happens here — otherwise one identical expression with wildly different costs looks arbitrary. Arrays have no holes: removing an element from the middle means shifting the entire tail one position left.

before:  [A B C D E F]        delete C (i = 2)
         s[:2] = [A B]        s[3:] = [D E F]

step:    append writes D, E, F into the cells after B —
         that is, into the cells that held C, D, E of the same array

after:   [A B D E F | F]      length 5, the sixth cell is not cleared

Three things are visible at once, and all three get asked about. First, append here writes into the same array — that is the fast path from Mechanism 2, the capacity is trivially sufficient. Second, the work is exactly the size of the tail. Third, the last cell stays populated — the lesson comes back to that below.

Hence the price. Measured on a slice of 10,000 elements:

The linearity is visible in the numbers themselves: 1401 to 667 is roughly 9999 to 4999. The cost depends not on the slice length but on the length of the tail that has to be shifted. Deleting from the front is O(n), from the back O(1), and it is the same expression at different i.

The two bottom rows carry no number not because the measurement is missing but because that is where it ends: shifting one element and shifting none cost less than preparing the slice itself, and subtracting the baseline disappears into noise. Substantively that is the same answer — their cost does not grow with the length of the slice.

Worth naming the practical consequence: if element order does not matter, deletion is O(1) by swapping in the last element:

s[i] = s[len(s)-1]
s = s[:len(s)-1]

And a separate trap — the one that makes deletion leak. Shortening a slice reduces the length, but the array is intact and the element past the length is still in it. If that element is a pointer, the object behind it will not be collected:

live := []*Node{a, b, c}
live = live[:2]      // c is no longer visible... but the array holds it

Verified by running it: the third element stays in the array and stays non-nil. slices.Delete solves this itself — the documentation says outright that it zeroes the elements s[len(s)-(j-i):len(s)]. Through append, zeroing the tail is on you.

Mechanism 4: where a slice pins memory

The same mechanism, at a scale that costs money:

func firstThree(path string) []byte {
    data, _ := os.ReadFile(path)   // 50 MB
    return data[:3]                // three bytes handed back
}

Three bytes returned — fifty megabytes still resident. The garbage collector works with whole arrays: while the pointer to the start is alive, so is the entire array. A narrower slice does not remove that reference, it only reduces the length.

A copy does:

return slices.Clone(data[:3])

slices.Clone returns a copy of the slice, and after it nothing pins the original array. The caveat in the documentation matters: the copy is shallow, and if the elements point at something themselves, that something stays shared.

This, incidentally, is the best answer to "when did you last chase a leak in Go": most leaks in Go are not a forgotten goroutine but exactly this kind of pinned array.

Mechanism 5: range copies — a guarantee and an observation

This section carries two claims of different kinds, and the lesson deliberately keeps them apart: one is always true, the other is true on a particular machine under a particular workload. Mixing them is how superstitions get made.

v is a copy of the element, and writing to it does not change the slice.

for _, v := range items {
    v.done = true        // lost: v is a copy
}
for i := range items {
    items[i].done = true // this way
}

This is not about speed and not about the Go version. It is about range by value assigning the element to the loop variable, and assignment in Go copies. The resulting bug compiles without a warning and passes the tests: the code honestly changes a copy.

But the conclusion "so range by value is slower" is not what the measurement shows.

for _, v := range xs   21,782 ns   — a 64-byte struct is copied
for j := range xs      22,577 ns   — no copy

By value came out faster, a ratio of 0.96. The reason is that the indexed form has a cost of its own: every xs[j] access is bounds-checked, while range by value walks memory in order without checks. The two costs turned out to be of the same order, and which one wins depends on the element size, on what the loop body does, and on whether the compiler managed to eliminate the bounds check.

This number must not be generalised in either direction: on a kilobyte struct the copy will surely win. What carries meaning here is something else — that the difference is not an order of magnitude, which means the loop form should be chosen by semantics, not by speed.

In an interview this is a good move: name the copying as a guarantee and the performance as a measurement, and do not conflate them. That is exactly how it stands.

Mechanism 6: nil and empty slices

var a []int      // nil
b := []int{}     // not nil

Both have length zero, append works with either, for range takes no step. There are exactly two differences, and both surface far from where the slice was created:

The second is a source of real bugs: a client expecting an array gets null and falls over. In the code it looks like "but we returned an empty list".

The rule: do not distinguish them inside your code — test len(s) == 0, not s == nil — and initialize explicitly at the JSON boundary.

Deeper: capacity growth and the price of "amortized O(1)"

From here on the claims change kind, and the difference is worth saying out loud. Everything above described the language contract: it will not change. Everything below about specific growth numbers is how today's implementation works, and it has changed before.

This is where the most commonly memorized rule lives — and it is wrong. Here are the capacities a []int really passes through under one-by-one append:

1 2 4 8 16 32 64 128 256 512 848 1280 1792 2560 3408 5120 7168 9216 12288 16384 21504

Doubling ends not at 1024 but at 512: the next number is 848. Here is the relevant piece of the runtime, in full:

const threshold = 256
if oldCap < threshold {
    return doublecap
}
for {
    // Transition from growing 2x for small slices
    // to growing 1.25x for large slices.
    newcap += (newcap + 3*threshold) >> 2
    if uint(newcap) >= uint(newLen) {
        break
    }
}

Take it apart, because both "known" numbers break right here.

The threshold is 256, not 1024. While the old capacity is below 256, plain doubling is returned. At oldCap == 256 the formula takes over, but it yields 256 + (256 + 768)/4 = 512 — so the doubling "accidentally" continues for one more step. The first number where the divergence shows is 848 after 512.

The factor is not 1.25. The formula adds a quarter of the capacity plus 192 (that is 3*256/4). At capacity 512 that gives 512 + (512 + 768)/4 = 832, a factor of 1.63. The share contributed by the 192 falls as the capacity grows, so the series does converge to 1.25 — but it approaches from above, and slowly:

2.00 … 2.00  1.66  1.51  1.40  1.43  1.33  1.50  1.40  1.29  1.33  1.33  1.31

Notice that the series is not monotonic. That is a third effect — rounding to size classes. The formula asked for 832 elements, that is 6656 bytes; the allocator handed back the nearest class, 6784 bytes — which is 848 elements. The runtime counts in bytes, and dividing back into elements leaves a remainder.

The easiest way to see it is a type whose size is not a power of two. Here is the same append for a 15-byte struct:

1 2 4 8 16 32 68 136 273 546 904 1365 1911 2730

Sixty-eight. Two hundred and seventy-three. Nobody designed those numbers — they fell out of dividing bytes by fifteen.

What you need from this in an interview. Not the sequence by heart, but three claims: growth is geometric with a decreasing factor; the threshold is 256; specific cap values are not guaranteed, because the arithmetic is done in bytes. The last one is the most useful: code that relies on cap equalling some number will break on a Go upgrade or an element-type change.

Complexity, and what hides behind it

"Amortized O(1)" is the right answer, usually delivered as a password. Behind it stand two different claims, and separating them out loud is valuable.

First: the total work is linear. Reallocations happen ever more rarely, and the copied volumes add up as a geometric series. So building a slice of n elements costs O(n), not O(n²) as it would with growth by one.

Second: an individual call can cost O(n). The append on which the reallocation happens copies the whole array. Irrelevant for the mean; potentially relevant for tail latency.

"Potentially" here is precision, not caution. The spike shows up in p99 only where the reallocation is large and sits on the request's hot path: the slice grows to tens of thousands of elements inside the handler. If the slice is built once at startup, or its length is in the hundreds, or the reallocations happen outside the request, nothing appears in the tail at all. This is checked with a profile, not with arithmetic: "append hurts p99" is a claim about a workload, not about append.

Look at both halves at once. The line is total copying, the vertical ticks are reallocations:

And now the part that usually goes untold. The coefficient on n is not one. Here is the measurement: how many elements the runtime copied in total while the slice grew to n:

The coefficient grows with size — and that is not a defect but a direct consequence of the previous section. A geometric series with ratio r sums to n/(r−1): at doubling that is ≈1·n, at a factor of 1.25 it is already ≈4·n. At a thousand elements the runtime is still doubling, hence 1.87; at a million the slow formula has long been in charge, hence 4.15.

That is the real trade built into nextslicecap: slower growth saves memory (less unused capacity) and pays for it in copying (four times as many elements moved). Neither is "optimization in general" — it is a choice in favour of memory.

And hence the answer to "how do I remove that": make([]T, 0, n) when the final size is known. Not "to make append faster", but so that there are no reallocations at all — in the task at the end of this lesson that came out as a sevenfold difference.

How to answer in an interview

Short answer: a slice does not own its data — it is a window onto somebody else's array, and two windows can look at the same cells. That is why a write through one slice is visible in another, and why append sometimes writes into that same array and sometimes moves to a new one — which is exactly why it returns a slice whose result you assign back.

Start with ownership rather than layout: the three-word header explains why the window is built that way, but on its own it does not answer the question. After that pair half the follow-up questions are already answered, and it shows.

That is enough for a correct answer. What follows is what you add when the interviewer digs.

If the interviewer digs deeper

Keep a one-minute account of append ready. Two paths; on the fast one, a write into an existing array; on the slow one, a new array and a copy; it returns a slice for exactly that reason. This is the core of the topic and it always comes up.

On growth, be honest rather than confident. "It doubles at small sizes and grows more slowly after; the threshold is 256; the factor just above it is noticeably larger than 1.25 and only converges there; specific cap values are not guaranteed because the arithmetic is in bytes" is the answer of someone who has read nextslicecap. "×2 up to 1024, then ×1.25" is an answer from somebody else's retelling, and one follow-up exposes it.

Split the complexity in two. "Amortized O(1) is about the sum. A single call at a reallocation costs O(n), and for p99 that matters." Almost nobody states that split, and it shows there is understanding behind the formula.

Answer "how do you avoid it" with forms, not intentions. Three of them: make([]T, 0, n) to remove reallocations; s[a:b:b] to cut capacity before handing a slice outward; slices.Clone to stop pinning a large array.

Next they ask

Common misconceptions

Practice

Two tasks. Answer first, then check against the real output: in both, the correct answer is taken from a script run rather than assigned.

s := []int{1, 2, 3, 4, 5}
t := s[1:3]
fmt.Println(len(t), cap(t))
t = append(t, 99)
fmt.Println(s)
fmt.Println(t)

2 4
[1 2 3 99 5]
[2 3 99]

2 2
[1 2 3 4 5]
[2 3 99]

2 4
[1 2 3 4 5]
[2 3 99]

2 5
[1 2 3 99 5]
[1 2 3 99]

Knowledge check