Pointers
A pointer in Go is a value that holds the address of another variable in memory. The & operator takes an address (&x has type *T), and the * operator dereferences a pointer (*p is the value it points at). There are no parentheses or arrows (->): you access struct fields through a pointer with the ordinary p.Field, and Go dereferences for you.
Under that simplicity sits the key thing interviews probe at the junior level: Go passes everything by value — arguments and assignments are copied, so a function cannot change the caller's variable until it receives a *T and writes through it. The zero value of a pointer is nil, and dereferencing nil crashes the program with the invalid memory address panic. Go has no pointer arithmetic at all — you cannot move a pointer to the next element as in C. This topic walks pointers layer by layer — from the operators to the nil pointer.
Topic map
- Pointer Basics —
&xtakes an address and yields a*T,*pdereferences; a pointer holds an address in memory; the zero value isnil; Go has no pointer arithmetic. - Value vs Reference — Go passes everything by value (copies); to change the caller's variable you pass a
*Tand write through it; slices/maps/channels behave reference-like — the header is copied but it shares the same backing. - The nil Pointer —
nilis the zero pointer; dereferencingnilcrashes with theinvalid memory addresspanic; guard before dereferencing; a method on anilreceiver is legal until it dereferences it.
Common mistakes and traps
| Mistake | Consequence |
|---|---|
| Expecting a function to change the variable you passed | Go copies the argument; without a *T the function mutates a copy, leaving the original untouched |
| Passing a large struct by value to "change" it | A copy is made — the changes are lost, and the copy also wastes memory |
Moving a pointer with arithmetic, as in C (p + 1) | Does not compile — Go has no pointer arithmetic |
Dereferencing a pointer without checking for nil | An invalid memory address panic at runtime, not a build error |
Assuming a copy of a slice/map is independent of the original | The header is copied, but the backing is shared — mutating elements is visible to both variables |
Writing (*p).Field instead of p.Field | Redundant: Go dereferences a pointer to a struct automatically |
Why it matters for interviews
Pointers are the junior-level filter for "understands Go's memory model" versus "carries C habits over or hides from pointers entirely." The syntax itself is trivial, but the consequences of "everything by value" and of nil are asked almost every time.
What interviewers usually check:
- What
&and*do, and why Go has no pointer arithmetic and no->operator. - Why a function does not change the caller's variable without a
*T(pass-by-value). - Why slices,
maps, and channels look "reference-like" even though Go copies everything. - What a
nilpointer is and why dereferencing it crashes the program. - When a pointer is genuinely needed (mutating across a function boundary, large structs) and when a copy is cheaper and safer.